I can give a coding agent a repository and a feature request and receive a patch that follows the project’s conventions. After more than 30 years writing software, that makes me wonder what is different between the agent writing routine code and me doing it.
The usual description of a language model is a probabilistic next-token predictor. When I write familiar code, I also draw on patterns I have learned and anticipate what should come next. That resemblance does not explain all of human thought, but it makes the agent’s output feel less mysterious.
The language of connections and weights invites a comparison with neurons. It is still a leap from that analogy to claiming the two systems think alike: the transformer architecture was engineered around attention mechanisms, not built as a simulation of a human brain.
By “not special”, I mean that AI’s abilities have an engineering explanation: training, algorithms, computing power and feedback. The interesting question is what those ingredients let it do, and what they cost.
A computer used to be a person
The Computer History Museum describes human “computers” who carried out calculations before electronic machines took over the work. The name is a useful reminder that calculating and following learned procedures were human jobs first.
Coding models also inherit a great deal of human work. The original Codex research, for example, describes a model fine-tuned on publicly available GitHub code. Learning from existing code does not rule out a useful new combination of ideas, but it helps explain why an agent can pick up conventions so quickly.
The human brain uses roughly 20 watts while doing far more than writing code. An AI model has no biological requirement to work within that power budget. It can be trained using large computing systems, then spend more compute on a difficult response or try several candidates. Research on inference-time compute shows that this can improve results on some problems, although the benefit depends on the task and how the compute is used.
This is not a direct brain-versus-GPU benchmark. The brain’s 20 watts is a continuous metabolic rate; model training, one response, and the data centre around the hardware are different measurements. More electricity alone does not guarantee a better answer. Model design, training data and verification matter too.
Nor is AI’s energy supply infinite. The International Energy Agency reports rapid improvements in electricity used per AI task alongside growing demand from reasoning and agentic work. My expectation is that useful reasoning per watt will matter more as we ask agents to work longer and on harder problems. That is a prediction about engineering incentives, not a claim that energy efficiency automatically creates intelligence.
Give the agent the problem, and room to question the design
A coding agent can follow a codebase’s naming, framework and formatting conventions at speed. It does not get tired or rush to finish before going home. It can also confidently repeat a poor pattern or satisfy the stated request while missing the customer’s actual need.
The valuable part of a developer’s job is often deciding whether the requested implementation solves the right problem. I want an agent to understand the business goal, then propose a different approach when it can explain why that approach better meets the goal. It should be allowed to question an architectural rule with evidence, while keeping the existing rule until the team accepts a change.
That requires a better feature brief. I would give the agent the customer outcome, constraints and success criteria, then ask it to propose an implementation. “Add this button” is an implementation instruction. A useful requirement says what the customer must be able to accomplish and how we will know it works.
The “nonlinear orthography” in Arrival gives me an analogy for this work: conceive the whole shape before making the first mark. With a detailed brief, I would ask subagents to shape a solution simultaneously from both ends. One works backwards from the customer outcome into acceptance checks and unresolved questions. Another works forwards from the existing architecture and code into an implementation plan.
They then compare their plans. A third agent can identify where the acceptance checks and the proposed design disagree, leaving the developer to settle the requirement or approve a change to the architecture. This uses more inference compute, but it may avoid writing a feature that solves the wrong problem.
Build the quality harness before the feature
Today I put codebase conventions in skills and Markdown documents for the agent. Before delegating a feature, I want the repository’s CI pipeline to enforce the rules that can be checked mechanically: tests, static type checking, formatting, limits on cyclomatic complexity and the preferred order of CSS classes. I also ask the agent to look for existing shared code and refactor genuine duplication before calling the change finished.
Those checks are the safety harness. Written guidance gives the agent a direction; a failed check stops a change from passing even when the generated code looks plausible. Tests must cover the customer’s success criteria and important failure cases, not merely execute the new lines. A human still has to judge whether the requirement is right and whether a proposed architectural change is worth accepting.
I have covered the mechanics of reviewing agent-written code through executable evidence elsewhere. The point here is that the harness changes what I can responsibly delegate. I can let the agent write most production code because the team has made quality expectations explicit and checkable.
Learn to code, even if you write less of it
I think experienced developers should spend less of their day typing production code. Their attention belongs on customer requirements, architecture, the quality system and the results it produces. They still need enough hands-on practice to recognise when an agent’s solution is awkward, wasteful or wrong.
Someone learning the craft should write code every day. Senior developers should still write it occasionally. Implementing an algorithm or a convention yourself teaches why it exists; that knowledge remains useful when you later direct an agent to do the work.
So far, I see coding models drawing heavily on human knowledge. I have not seen enough to claim that this prevents original ideas. If an agent proposes a genuinely novel solution, I would welcome it and test it as I would a colleague’s idea. Better training and carefully evaluated synthetic data may help models improve, but recursive training is not a free route to progress: research on synthetic data finds that replacing real data with generated data can degrade a model.
There is a less comfortable question behind my interest in AI coding. If a machine can predict its way to code that resembles mine, how much of my own coding is prediction? I do not know, and I dislike how deterministic that thought feels. It does not change the next practical step: describe the customer’s goal clearly, let the agent propose the code, and require evidence that the result meets the goal.