The latter is something I’m dealing with and it’s given me some existential angst. An example is a company’s monolith with millions LoC and hacked together. With proper engineering strategies, it could be closer to 100k. Without proper AI tooling, my verdict was let it be. When you have so many developers, PMs, stakeholders who tie their value to the pile of slop and making “engineering” decisions with it, it becomes very unpopular to suggest any refactoring - especially when that refactoring relies on principles that require an understanding of software engineering.

An example: the UI applications suffer from massive amounts of repetitive code. People on hacker news will probably instantly jump to some kind of componentization strategy. More wise individuals probably understand you need to draw a winning strategy before that’s possible. Identify common workflows, from that, identify common components, figure out a parameterization and so on. The footguns are the slop having unintended consequences which fixing might actually cause production bugs by being “features”.

Hypothetical now: a current alternative solution which may exist is two simple detail views (of which there may be 30+ in the application) are 1000+ LoC template files, hand-coded, copy-paste, with all the errors you could imagine. You can get a lot of work from that so people are/could be content just fixing slop with slop and calling it engineering while piling on more features. Maybe it works but it doesn’t allow for much engineering room.

With AI tooling, popular support becomes less necessary - correctness matters more. Instead of galvanizing people to realize this is wrong (and it’s not just a want thing, with offshoring and the general difficulty of software engineering, many people don’t understand these concepts. They are great people but struggle understanding for loops intuitively; I don’t know what to say). Now I can provide my strategy to the tooling and do the decomposition and componentization myself. On top of this, my strategy can be more intelligent and robust because I’m not doing it by hand like concurrently using the API layer as a source of truth to give my agents more context on what the UI was trying to do. The code itself is confused so part of the work is learning the intent behind each module and also capturing bugs that are “features” to prevent regressions. Basically, a clean room rewrite (but we have access to the source code so I know that’s not the exact correct term).

The engineering moat is still there. If I say, “Claude make my UI codebase smaller” it will burn tokens and fail. One day it will succeed but right now it will fail. Likewise if I say “Claude suggest ways to make my codebase smaller”, it may suggest my strategy but it may not capture all the critical wrinkles. LLMs are not good at simplifying so to simplify (which is always a good goal in software engineering as long as the abstractions still hold), requires human strategies when complexity is high enough. Especially in my case where the behavior of the code is almost more emergent rather than engineered.

Then carrying on, hypothetically, I started to devise a system for not only rewriting the UI but the rest of the application (API and DB layer) as well as the corporate processes around the application. This may sound rude but these corporate processes can be disempowering and wasteful. The trick is inversion. First build a conceptual interface around the layer. The model will understand the purpose without understanding or rewriting the internals. This saves context and allows it to do more powerful reasoning by having perspective instead of being in a vacuum. Then when you have bandwidth, use that interface along with all the context you developed working on other modules, to take control. An example, you have a team which is responsible for building and deploying. To build and deploy, you may need to fill out forms, contact layers of people, all to achieve the end of goal of “building and deploying”. Through inversion, you communicate with an agent endpoint that handles communications to that team. Escalating, writing forms, and doing whatever is needed to get the code built and deployed. For all intents and purposes, you are now in control of that process. What used to be, for example, “I want my code built and deployed to QA” -> “message A” -> “message B” -> “write form A” -> “monitor for responses” -> “build triggered” can now be “I want my code built and deployed” -> “activate agent process” -> “build triggered”. This is an application of inversion in a nutshell. AI allows to apply engineering principles not only to our code but corporate processes where applicable.

So in this case, there could be 100+ individuals supporting this application and process. The one or two or three engineers that used to own the development process (more or less) were drowned out yet still responsible for the overall process and integrity of the software. It was an impossible task but now it seems more possible. The existential angst part comes from the all processes that were sprung up to support a reality where this all wasn’t possible.

Last, I definitely do not think the solution is one hundred engineers. If you know the show “Breaking Bad”, I actually find the reality of software engineering to be more like this now. The difference between 60, 90, 95, and even 98 percent purity is staggering. And the chemist who takes the input (money and tokens) and produces the highest quality output (codebase and processes), dominates. Just as in Breaking Bad when Walter White inherently has power, despite all other chemists and structures of authority, because his process had the highest purity output. It’s just business sense and adding more chemists does not increase purity. Output quantity is no longer gated by number of bodies so that argument goes out the window. Mentorship will be key (as in Breaking Bad) and large teams of all-high-quality producers should be put together into super high-thoroughput teams. But for regular operations, prioritize the highest quality output where the input is guided by the highest quality producer because adding more cooks will seriously degrade the output, at an exponential rate.