I've been noticing what look like AI-generated restaurant menus everywhere. Everything is polished, the food is suspiciously photogenic, and occasionally the picture stops making much sense.
I understand the appeal. Getting something presentable has become much easier. But somebody still needs to know what the restaurant actually serves, what its customers like, and whether the result is any good.
I think software development is going through a similar change, with more expensive consequences when the mistakes are hidden.
In The Emergence of Generic Software, I wrote about what happens when the cost of creating software falls. Coming back to the subject in October 2026, I'm increasingly interested in the practical question: what does good engineering look like when everyone has access to capable coding agents?
Agents have changed the development loop
The useful change is how much of the work an AI system can participate in. A coding agent can inspect a repository, make changes across files, run commands, read test failures and try again. That loop is a substantial step beyond asking a chatbot for a function and copying the answer into an editor. Anthropic's explanation of how agents work describes this cycle of planning, acting, observing and adjusting.
The infrastructure around it is becoming a product in its own right. OpenAI's Agents API manages sessions, orchestration and context compaction, with execution environments where agents can run code and work with files.
For an engineer, that creates a different set of decisions. What should the agent know about the project? Which tools should it have? What can it change? How will we establish that the work is finished?
The model matters enormously. So does the system we build around it.
Give us both the same model
The conversation about AI replacing developers keeps coming back. Sometimes it is an interesting discussion. Sometimes it sounds suspiciously like an argument for reducing the hourly rate.
My reaction is fairly simple: fine, give us both access to the same models and compare what we ship.
A business owner who understands a problem can now get much further without waiting for a development team. I think that is a good thing. Domain knowledge counts, and developers do not have a monopoly on it.
Where I expect engineering experience to make a difference is in recognising what the first working version leaves unresolved.
Take an order import. Fetch the orders, map the fields, save them. The initial implementation may be straightforward. Then the questions start:
- What happens when the supplier send the same order twice?
- What happens when a request times out after the write has already succeeded?
- How do amendments interact with orders that have already been processed?
- Can one customer access another customer's records?
- How do we reconcile a batch that only half completed?
An agent can help reason through and implement all of this. The value of experience is knowing that these questions belong in the task, and recognising when the proposed answer is insufficient.
I've already written about a version of this problem in my encrypted-media work on Quldra. Keeping encrypted attachments in Postgres was initially convenient. Larger uploads exposed problems with memory, connections and the operational cost of storing media that way. I moved the media into object storage while keeping its metadata in the database.
That experience is why I care about what sits behind an endpoint that appears to work.
Passing tests still leaves engineering work
In a March 2026 research note, METR had four maintainers across three repositories review 296 AI-generated pull requests. They found that roughly half of the patches that passed SWE-bench Verified's automated tests would still not be merged, after adjusting for inconsistency in human review.
The study used agents from 2024-2025, and they did not get a chance to revise their work in response to maintainer feedback. It therefore tells us something about the gap between benchmark success and an acceptable change, rather than establishing a failure rate for today's applications.
For me, the practical lesson is to make that feedback part of the workflow. Tests need to represent the actual requirements. Review needs to look at behaviour and assumptions as well as whether the code is tidy. A model writing both the implementation and its tests can carry the same misunderstanding in both.
This also puts a limit on the idea that we can keep adding agents and get proportionally more useful output. In Anthropic's October 2026 report on its own workplace, human attention becomes a bottleneck as agent output increases. That is one unusually AI-intensive company's experience, but it points to a practical constraint: somebody has to decide what deserves attention and how to evaluate it.
More output is useful when the review and integration process can keep up.
Why the tools seem to understand me better
I've been developing with models from OpenAI and Anthropic for years now. Increasingly, it feels as though they understand how I work. They can help with complicated problems and produce solutions that I find much more acceptable than they used to.
I suspect several improvements are happening together: the models are better, I am better at working with them, and the tools have better ways to carry useful project knowledge forward.
That last part needs a distinction. An assistant remembering project decisions does not necessarily mean I have personally trained a specialised model through years of conversation. For example, Claude Code's documentation describes instructions and memory notes being loaded into a fresh session as context.
For a coding agent, useful context can include the business rules, existing architecture, build commands, test fixtures and reasons a previous approach was rejected. The instruction "use our normal authentication flow" is much more useful when the agent can find that flow and understand the boundary it protects.
This is where I think a lot of the compounding benefit comes from. Decisions should become accessible project knowledge, rather than disappear into an old conversation. That helps the next agent session and the next human developer.
I would therefore qualify my own instinct that AI is as smart as the work done with it. The underlying model sets real limits. But the quality of the context, tools and feedback can make a large difference to what we get from the same model.
The workflow I want around an agent
These are the habits I think make agentic development useful over the life of a project:
- Define the result before requesting the implementation. Agree what the user needs, which constraints matter and what evidence would show that the change works. For that order import, preventing duplicates is part of the requirement.
- Give the agent a working environment. It needs relevant code, understandable instructions and a way to run meaningful checks. If it cannot run the checks, its completion report needs to say so.
- Keep changes small enough to assess. Parallel agents can help with separable work. Shared interfaces and overlapping edits still need coordination, and a huge generated diff still has to be understood.
- Verify the behaviour that matters. Test against real requirements and representative failure cases. A second agent can challenge an approach, but agreement between models is not independent proof of correctness.
- Match access to the task. An agent investigating an issue may need logs and source code. Permission to change production data is a separate decision. Credentials and deployment controls belong in the environment, not just in a request to "be careful".
- Keep responsibility attached to the result. Someone owns the deployment, monitoring, recovery plan and future maintenance. Generating the change is one part of delivering it.
None of that becomes unnecessary because the code arrived quickly. The speed makes it more valuable to have these decisions clear before work starts.
Cheaper development changes what is worth building
I am optimistic about what this makes possible. For a well-scoped internal tool or an early product version, getting something useful together in days is increasingly plausible. Larger systems still have integration, validation and operational work that cannot be estimated from the speed of the first demo.
The part that interests me commercially is the number of problems that become worth solving. A reporting workflow, a legacy integration or an awkward manual process might have been too expensive to tackle before. If implementation takes less effort, the calculation changes.
That also changes how I think about pricing. A higher hourly rate can stll produce a lower project cost when fewer hours are required. But the honest comparison includes review, rework, infrastructure and ongoing maintenance. A cheaper first build that creates expensive problems later is not much of a saving.
I don't see this as a promise that every existing development role or business model will survive unchanged. I do see a strong reason to get better at turning business problems into dependable systems. That is the part of software engineering I want to keep doing.
Where I think this goes next
I expect more specialisation: agents that understand a particular codebase, business process or technical domain and have the tools to work within it.
Some of that may involve specialised models. Much of it can start with a general model, carefully maintained knowledge, appropriate tools and a way to evaluate the work. There is no need to wait for a completely new model before building a much better development process.
The question I keep coming back to is how much work I can delegate while still understanding and taking responsibility for the result. As the tools improve, I expect that boundary to keep moving.
Putting this into practice with KRATT
That is also the thinking behind KRATT, the technology consultancy I recently started in New Zealand. I work on custom software and integrations, legacy systems, applied AI and computer vision, and problems that need technical investigation before there is a sensible implementation plan. (RDTI application pending)
One area I call AI Archaeology fits this especially well: using AI to understand existing software before rebuilding it around how the business works now. An awkward branch in old code might contain a business rule nobody remembered to put in the replacement brief.
I'm still building my own projects, and cryptography remains one of the rabbit holes. If you have a system that needs untangling, a product to build, or an interest in backing one of my projects, let's talk.
And for the developers reading this: where is your bottleneck now - implementation, reviewing the output, or deciding what to build in the first place?
Top comments (0)