Software Engineer: “I can’t trust the quality of the code that agents produce”
This isn’t a new challenge. Engineering Leadership have had to manage code quality from small armies of messy, non-deterministic code generators (their software engineer employees) for decades now. This is never a truly solved problem, but rather it’s one of the primary through-lines for just about everything Engineering Leadership strives to continuously improve.
Historically, the further up the management/leadership tree you went, the more your role was abstracted away from literally writing code. Your role gradually became largely about managing the flow of information to enable good decisions by those writing code, and implementing meaningful quality gates along the way so you didn’t have to read every line of code yourself (like you did in the early days when it was just you).
This means the 2026 journey towards the “Software Factory” has a lot in common with the challenge we’ve always faced with new hire engineers that are on their first day in our organisation: How do we get them the context they need to succeed, and what are the appropriate quality gates to have in place until we have enough evidence we can trust their work without material oversight from ourselves.
Now we’re just doing that all over again, but for agents as well as people.
Hat Tip to Dave Slutzkin for his line that inspired this post: “Managers recognise the value [of abstracting devs away from writing code] quicker than some devs do - if you’ve never delegated and had to worry about quality and throughput across a complex human system, it’s maybe harder to see the same thing across a complex mixed human/agent system”.