Comment by kypro

6 hours ago

I first brought this up late last year – that there used to exist a kind of selection pressure against both developers and against features which would prevent certain functionality from ever being shipped, specifically:

- Functionality which exceed the technical ability or knowledge of the developer which built it; and

- Functionality which would require an excessive number of changes that time/cost became a constraint (likely because it wasn't an incremental change but a significant rework, or just a bad fit with the existing product).

Sometimes I had the displeasure of joining a company where you could see developers hit these blockers and tried to fight through them (likely under pressure from management) rather than avoid them. And in the process they created a mess of buggy, half-functional spaghetti code which someone else later had to resolve.

Today however, people can use agents to smash through these blockers and ship an incomprehensible amount of crap. And what's worse is they're celebrated by management who don't know any better and see this all as a productivity win with no downside.

I suppose there are two ways to look at this – some would argue that engineers don't need to understand what they're building in detail anymore so non of this matters. Instead they can always use agents to explain what's going on and prompt them to fix any issues that come up.

Then there's another camp which might argue that agents will fundamentally have all the same limitations as humans, and that at some point a codebase will grow too complex that it exceeds even the limits of an agent's knowledge retention or intelligence. Or a codebase may just grow so large that it costs 1 million tokens to make even a simple change.

Unless agents start saying, "there's no way I'm shipping that" like humans used to I don't really see how we avoid the latter scenario... Complexity simply must have limits even if agents allow the bounds of those limits to grow.

At some point models will have to take control or we risk hitting these limits in irrecoverable ways since complexity far exceed that of what a human can reason about well.

If this wasn't true then "build me all the software" would be a reasonable prompt. Because why wouldn't we just get an agent to build everything we could ever possibly need? It's obvious that in the limit there will be limits in knowledge, intelligence and cost.

Whether it's humans or agents, someone needs to manage complexity. That is the most important thing a good SWE used to do. It's why technology selection mattered, it's why good architecture mattered, it's why clean code mattered.

In my personal project I've found having a hard lines of code limit has been a good limit on complexity. Makes me really ask if I need things.

One theory I have floating around in my head is that if a whole code base was microservices and micro front ends that were all less than 5,000 loc then you could fit the whole thing into a 100k token AI context window when working on it. And being few lines of code would force them to be somewhat simple

  • Yeah, I think microservices are going to see a new wave of enthusiasm for this reason in the coming years.

    I've had a lot success at the company I work for shipping small contained microservices for less technical teams to maintain with agents.

    Personally I think this most of what SWEs should be doing these days... Code is easy to produce now. We should be handing over the creation and shipping of code to the relevant teams.

    Maybe there will be more complexity overall, but it will be constrained via well designed microservices and distributed across the organisation.

There is a limit, after a few 10,000's of LOC ai projects start disintegrating and becoming unmanageable.

  • 10,000 LOC, hell my LLM can do that in a day!

    Current project has over 60,000 LOC, I find using an antagonistic agent code and architecture reviews are really handy for keeping things grounded.