BatteryMountain

Our codebase is about 8 years old, it used to be a .Net 4.8 project, which was upgraded to .Net Core 3, some bits to .Net Core 6. It was a mess. When I joined upgraded the whole stack to .Net 8, then .Net 10. Next upgrade is for .Net 12. I agree the old code was messy (single monolith, one solution, one project, zero clean boundaries) - I have since refactored it into a pseudo domain-driven-design layering which has enabled us to rewrite certain parts with low risk. Also stripped out business logic and third party integrations into their own projects. So we have about ~50 projects in the solution at the moment, not counting our mobile apps and agent framework. We also rebuilt our background services stack and got allll of our services to complete their runs under 60min, so no more "system is slow queries". Since converting it to use .Net 10, we can now also host 99% of the thing on linux servers (we are about halfway with this migration). So our cleanup efforts has been amazing, our server bill has been reduced by about 50% in 2 years, and next year we will half it again as I'm busy rewriting our most expensive system (a shitshow that was built by a consultancy firm, as usual).

The entire industry has shit software to be honest, our company has the best or most modern system of the bunch in our country. Half the industry does everything via clipboard & excel.

Not all 10 are doing bug fixes. Two of them are mobile apps, 5 of them are long-term feature work, 1 is infra/monitoring, the rest is adhoc stuff like bugs.

We've been bitten hard by stale query plans in MSSQL in the past year. Was hard to figure out it was the problem.

It's a defense-in-depth thing, not our only layer of security. So even if they somehow get in, they will find nothing again, every layer deeper becomes harder. Oh and don't count the decoys and honeypots we have floating around to keep the morons occupied.

100% our thinking too.

The problem is, even if I only enforce some rules locally, another developer has a different set of rules. So when we git commit, we ping-pong changes and fix each others stuff over and over again, bloating commits. We used editor config files + analyzer configs in the past (that gets checked into version control too), but there were still too much friction.

Where now, the compiler flags & strict analyzer settings forces claude to do the right things (we explicitly tell claude not try and bypass or lower the barrier). I think it only works because we don't spend 95% of our time in the IDE anymore like a couple of years back, so we as developers no longer feel that friction, as claude tries to satisfy the compiler instead. Its a massive mental load that is just gone, we haven't had any conversations in meeting about this kinda stuff anymore (remember in the past we would have flameouts in meetings or code reviews about linter settings...).

Exactly. And over time a project can drift from its original purpose, so you end up building around a bunch of stuff you aren't using anyway, but you pay cost/risk for having it present.

Differences: Money/decimals, rounding, case-sensitivity, equality comparisons differences, db/table locks mechanisms, memory/worker management, table/column naming conventions, null fields/columns effects on queries.

Mmm what else. I prefer postgres so I'm very excited about this. So many foot-guns will no longer haunt us like on MSSQL and less db/table locks to try solve (pessimistic vs optimistic locks). Oh and we are going to save a gross amount of money per year, as we will also be able to switch off a couple of Windows Server VM's in the process. These puppies are costing us a ton (I think about half of our infra bill are licenses...).

Just create a branch, spin up a test db and try to port a small feature. Its very easy in most cases. Debian + dotnet + postgres = dream team.

Short term there will be pain (hacks/malware) but at the same time, it will force the survivors to build bullet proof systems.

Worse case, we enter the Dark Forest era for technology. Read up on this concept and apply it to the tech industry. I suspect open-source might die and everything becomes private, no more public networks, no more open access, as to assure survival. In a sense we are halfway there already as it seems the internet is starting to close down, people not posting their art and music as much anymore, not posting their knowledge for free anymore, as it might be used against them by AI (the other party in the dark forest..). Thus private authentic experiences will become more valuable.

They will learn certain lessons the hard way for sure. As much as I want to spin up 100 agents in a loop on our codebase and let them loose, I also know its not feasible as they can easily go down the wrong rabbit holes or over-engineer the wrong solution. They are amazing but cannot be left 100% autonomous just yet.

Literally half of the work we did the last 12 months was this. Refactor and fix, performance improvements, security hole fillings etc. We have one or two devs doing visible feature work, the rest of us is making the system rock solid.

Same approach here.

And since we now have coding assistants, maintaining in-house costs near nothing now. Nobody else can break us, only ourselves.

I understand, but I would argue its better to have an in-house 1K lines of code that only does what we need and nothing else, it well tested and under our control, than to depend on some 50K lines of code (of which we might only use 10% of functionality and the others just getting in the way) that random's on the internet can modify, sometimes pulling in transient dependencies that we would really not have in a server environment, telemetry and other gremlins. It goes without saying that opensource packages will become even more juicy targets for malware/hackers to get into your systems like we've seen in the past month (and it will only become worse - you will be forced to pay technical debt or die).

The only "third-party" packages that we want to ideally allow/support would be provided from LTS versions of our runtime (in this case, packages provided by the dotnet team and audited by microsoft). So we will always try to build around what the framework provides. Second choice is our own code, third choice is open-source packages, fouth choice is a separate application/appliance (lets say ZenDesk for ticketing). Over time, we will reduce this footprint to only have dotnet team code and our own.

Remember most CVE's can be hidden on servers that are not publicly routable and don't have a real exploitation paths. The bits that are public (lets say a linux edge server with a web server on it, some firewalls, a couple of open ports) - these should be hardened to the max and not allow full access to all the services running behind it. We don't even give our internal services public IP addresses to make near impossible to route traffic to them.

Our git repo's are also not on public infrastructure (serious, think carefully about hosting on public services and if you really need it), never mind making the repo public.

We also have a dedicated secrets/certs manager, so no credentials are in codebases or pipelines. Very strict in this regard.

When you change a single setting in the IDE to make something more strict and you have 1M+ lines of code, you will get 30K items to fix, via red/yellow/blue squiggles in the IDE. Most of those can be simple refactorings, but the performance & UI of the IDE makes it incredibly unwieldy and it will sometimes fight you back, sometime crash internal processes which leave refactorings half baked and so. Now imagine you change 50 such settings, to make the compiler force you to write better code. Changing 200K+ lines of code yourself is a nightmare (and to prove it still does the same thing afterwards). Instead, claude systematically approaches whole classes of errors and convert them to cleaner variants (either using our custom skills or it writing new scripts to do it). I consider myself an advanced user of IDE's, know how to do bulk refactoring and renames and so on (esp with JetBrains tools), and I would say it would be a near impossible task to do as a human. Then there are other developers - so you flip a setting and now 5 other people's IDE's are forcing them to work a specific way which will make you unpopular very quickly and revert the changes. So, since most of us no longer use IDE's as our main tool to build/diagnose, we can more easily flip compiler settings without destroying someone else's week. Hope that makes sense.

Oh it also helps to split refactoring work into three buckets: business logic changes, performance changes (same output as before but faster) and cosmetic changes (rename files/folders/classes, breaking large files up, add logging/comments, domain layering etc). We tend to focus on performance and cosmetic changes for bulk refactors and leave logic changes to more dedicated sessions as to avoid changing what the system do (our domain is fairly complex and we cannot afford breakages). We also managed to port ALL of our code to dotnet 10 lts and have clean boundaries between projects (we have a mono-repo with about 50 projects in it), so we can wholesale upgrade dependencies without a sweat.

We haven't fired a single person yet due to AI. We just save everyone time, make input more accurate, make our accountants better, manage our technicians and jobcards better and so on. We also made our system bullet proof to the point that we only had one weekend failure in the last 24 months, and it wasn't our fault (a third party dependency did a large deployment on a friday night). Our system is now deeply "boring" and its awesome.

Our legacy system runs mvc view with bootstrap 3 and some jquery. It's not a SPA, so no framework to replace. But we still have to mess around with npm sometimes.

Utilities - Electricity/Water/Gas. 98% of our systems are internal facing or third party integrations. Our surface for end-consumers is tiny.

Yeah a memory system per domain, or per module or even per file works amazing, we have it too. Took a ton of time to improve the code and list down all the tribal knowledge, but now that it's done, it works super well.

Myself specifically, I have a /code folder without about 10 copies of our codebase, each running their own claude sessions & git branch. Then, I have 10 terminal branches. I spend a ton of time planning out & specing the problem with claude, to be as specific as possible and be as constrained as possible so it cannot go on side-quests. I use Opus 5.5 on High effort. That's just on my laptop with what I can mentally cope with day to day. Then we have some other automatic ai goodies running within our custom agent framework that runs within our platform that also helps. Then for apps, I basically plug in multiple phones into my laptop with usb (and emulators if I really need to), and claude can fully drive the ui and testing on the phones via adb as an example. Even on linux/fedora/kde it can drive UI apps a and take screenshots and fix things properly etc. It can ingest all logs & debug chains, so it absolutely flies through its task.

Before we started this journey (about a year ago), we spent a ton of time cleaning up our codebase, splitting large files (10K+ lines) into files that are no more than 2K lines, things like that. Then we let claude scan our important files and summarize them, add comments for future claude sessions. So we've let it built up tribal knowledge per file and the reasons for things to exist. We tell it all about our operating environment, the country and legal framework etc, so every little piece helps it stay honest and on track.

So to start, do something simple like: Scan the files in this folder for database code and check for queries that loads the entire result set into memory and/or queries that loads all columns. Suggest which queries we can filter better or reduce columns being transferred. Once done, also check real db row counts, compare them with the queries in these files and check if they might benefit from an index or partitioning/sharding. Also check for queries that loads data but their results are not used. Don't make changes yet, just do a deep investigation and report back. Feel free to spin up muliple agents to batch the scans.

edit: it goes without saying you need a language with strict typing and a good compiler (we use dotnet). Doing this on python/javascript would be a nightmare.

Actually, I have started with it already but is paused, but the approach is to rebuild it from scratch in parallel to our current legacy system and move our staff over to the new completed screens in batches (we have close to 1000 views in our system, 150 background jobs, with about 15 main categories (think organisational sub-divisions)). So as long as we go slow and steady (even with AI) it will work out fine, I expect it will be done in less than 6 months. One month if we rush but we don't want to rush it, as we are moving some things over from MSSQL to Postgres, so slow and steady is the way.

We are multiple developers, each having 10+ main claude agents running different sessions/terminal tabs. I have 10 copies of our codebase on my laptop, each with their own purpose and claude session and history. The other devs have different approaches but we all get similar output. And then we also built an agent framework that runs within our system that has access to our code (at most 60min behind master branch), our infra and our databases, so it can diagnose issues with excellent precision and prove it to us where to find code/data issues.

This is a good thing. Repaying technical debt is always a great thing.

On our own 1.5M loc system, we've found and fixed thousands of bugs, security holes and circular dependencies in the last year. Code quality has increased, test coverage increased. We've also recently set our compiler to treat warnings as errors, and to be as strict as possible. It is absolutely amazing to see the gaps being filled, it would've been an impossible task for human devs and IDE's would've made it very uncomfortable. We've also ironed out all the bugs and failure modes in our infrastructure automation / monitoring. Our next project is to eliminate all 3rd party dependencies, and after that to rebuild our frontends completely using zero frameworks, not touching npm ever again after that.

So when I read this about postgres, I was very happy that they found and pursued this side quest. They can make the codebase bullet proof.

Seems like a high-school project or a counterfeit item? If not, Lenovo messed up badly.

This week I hit walls twice with Fable and Opus 5.5, where I was blocked for safety/cybersecurity risks... doing stuff on my own LAN/proxmox server under my desk and writing custom firmware to my own devices plugged into USB. Only Opus 4.8 was able to complete the task. If they keep this up, I will re-evaluate my day-to-day AI assistant.

Just in time for elections. Now none of the bots/operatives can get paid...oops.

The bloodhounds will not let go of power that easily. Their nature will not go away simply because there is a new system - they will adapt to the new system to exploit (or eliminate it) to keep the power.

I've thought about this a couple of times, what happens if we truly succeed and we as a species solves all of our major problems? Like energy, food, health (incl stopping aging). Do we even need economic systems then or will the "market" become obsolete too? So lets say we solve ALL of our problems and we somehow manage to briefly unite humanity to want to dominate each other, meaning we all need to become one race, one language, one cultural blob to reduce all friction (best case scenario - won't happen in reality). How long will it take for human nature to get bored and split into groups and start controlling each other? Who decides who gets to make babies? How many babies are optimal? Who is in charge of this kind of society? What if we all get a non-invasive implant that lets us share thoughts & emotions? What does privacy look like in this world?

I think people will briefly chill out and enjoy it, but after a while, we will be back to business meaning we will create systems and hierarchy to control social order, and so the blood sport continues. Then we might realize the our problem was never energy/food/health etc to begin with, it was an addiction to power and the blood sport it invites. And round and round we go.

I also think, the moment AI becomes an actual threat (threat meaning a better/smarter consciousness) - the human brain will immediately try to eliminate it to keep its dominance. If not, we will go the same way as neanderthals.

edit: The movie Jupiter Ascending also has an interesting take what might happen once we solve our problems - then we try harvest Time.

Same story here as many others: I now do my personal and business taxes myself using an application I had claude cook up for me, doing it 100% correct, for South Africa's tax system. Previously I paid thousands to a small accounting firm to do it for me as it can be slightly nerve wrecking, but I had claude explain to me exactly the mechanisms on how everything works, including the tax portal that the government provides to do submissions. Absolutely amazing. Oh and the filing took me 5 minutes to do myself and cost me near zero once it all clicked into place.

I always joked that when a company grows past 20 people it goes from being a table top game or crpg and it morphs into an MMO, but with DoTA/LoL mentality internally.