Alec’s blog

Does the code matter?

February 2026

I've lately been thinking a lot about writing code using AI agents. I published a brief overview of my current AI software engineering workflow. Reviewing and refining the generated code is an important part of that workflow.

Writing code effectively with AI agents requires feedback. It's important to have tools in place to validate generated code. For example, if the code doesn't build, then that's a strong signal that changes are needed. Unit tests, integration tests and end-to-end tests provide feedback on whether the code or system works as it should. A linter checks the code for potential errors. A code formatter makes sure the code follows the project's code style. Static analysis tools like Dependency Cruiser can check code structure and validate against rules to enforce an intended design. And so on. AI agents can even be used to review code written by another agent.

This is to say that an agent that receives feedback about how it's doing can iterate on its work. An agent with feedback is likely to outperform a one-shot code generation without a feedback loop. If we've got a good feedback loop, then we'll probably have better output.

So here's a question: if we can put a feedback loop in place that gives us confidence that our AI-generated code is well-formed and meets its functional requirements, does the code matter?

Can we treat the implementation as a black box, as long as we can verify the behaviour is correct? Do we need to consider software engineering principles and code quality when the code isn't being written by humans?

I acknowledge my biases as a software professional. But I don't think AI changes whether the code matters or not. Sometimes it matters and sometimes it doesn't.

Software Engineering at Google describes software engineering as "programming integrated over time". I think the "time" factor is significant here.

Consider the kind of software that's written, used, and then thrown away. For a quick prototype, proof of concept, or throwaway script, the code doesn't matter a lot. The code won't need to be easy to understand or change later because there will be no later.

Software engineering principles are about building robust, operable and long-lived software. Consider the single responsibility principle, the dependency inversion principle, and the common design patterns we use to implement these principles. These ideas make software more maintainable regardless of how the code is authored.

An example of this is the Don't Repeat Yourself principle. This states that if the same concept is expressed more than once in the code, it's better to combine those into a single thing. Does this still matter if people aren't doing the typing? I think it does.

DRY is not about typing less - it's about conceptual integrity. That is, the reason to avoid repetition isn't to save typing, but because implementing the same concept in more than one place can result in inconsistent behaviour and bugs. So DRY still matters even if we're not typing the code.

Additionally, the code for any production software needs to be understood by its engineering team. It's a significant risk if the team doesn't have a good understanding of how their software works. It's therefore really important that, however the code is generated, it's reviewed by human engineers. I think in this context, the code absolutely matters.

So while it seems likely that over time we'll be writing less code by hand, in my view, pragmatic programming is alive and well.