In nearly thirty years of development I have watched frameworks and technologies come and go, each promising to make the work more productive and almost never really delivering. With coding agents, the artificial intelligence tools that write and modify code at the developer's direction, something is changing, despite many weak points. I use them, Claude Code and Codex in particular, not as a chat to ask questions, but with a method that starts from written specifications (spec-driven) and on a knowledge base built project by project.
For those who entrust a project to me, the relationship does not change: specifications, checks and responsibility stay the same. What changes, where the context allows it, is the speed of getting from specification to code.
Requirements, constraints and acceptance criteria, written before the code, starting from the client's documentation or description.
How to build it: parts involved, sequence, risks. Specification and plan are reviewed before any code is written.
I alternate Claude Code and Codex across the different phases, following the approved plan.
Automated first, then interactive. When needed, the problem or feature becomes a repeatable test.
I check that the code matches the specification and update the documentation: work done, roadmap, decisions, pitfalls.
In this cycle the agent does three different jobs: it carries out the tasks I assign, discusses the specification and plan with me as in pair programming, and looks up information during development. The last two are the most useful and the most delicate: I describe them under the limits.
By harness I mean the set of instructions, domain knowledge and procedures the agent consults on every request. For each project I build it up gradually, in documents called constitutions: domain rules, management procedures, information vital to quality.
It reverses what I have seen in recent years, with projects that often had not a single line of documentation. With an agent, tracking decisions, user requests and pitfalls becomes essential: it is how you reconstruct the reason behind every choice.
It has a cost. The information grows, and the agent must keep finding the right pieces: the harness has to be maintained and optimised like code. And it has to be tailored, because beyond a basic structure every project has its own needs.
It pays off most on complex projects, where a process runs across web apps, web APIs and external services such as a CRM, often over several repositories. Without explicit domain knowledge, the agent in the IDE sees one piece at a time and tries to rebuild the whole flow on every question; with the harness it can follow the flow across every environment.
An effective harness must also make errors visible: action limits and independent checks help stop an incorrect change before it reaches the product.
I define the technology stack and the guidelines, set up the harness and build features with the spec-driven cycle, starting from the client's documentation or description. When useful, I organise the work into several parallel streams.
Keeping the harness aligned as the project grows.
I start from the existing material, often the code itself, and set out a step-by-step migration roadmap, choosing the best sequence. I alternate the tests run by the agent with hands-on checks of the work in progress.
In systems where every check requires the full application, a shared database or manual configuration, I first prepare an environment and repeatable checks. The work needed to make changes verifiable is part of adopting the agent.
Having something runnable and testable as early as possible, however minimal. The risk is working heads-down for weeks and, at the first launch, not understanding why it doesn't work: better to start small, check that it runs and add functions a little at a time.
I analyse the code and the patterns in use: this is especially useful when compliance with them is checked in review. I transfer into the harness the domain knowledge gathered from stakeholders and product experts. It helps me a great deal to get into the project and become self-sufficient quickly.
Always keeping a critical eye: what the agent proposes must be weighed against what is known about the project.
On projects spanning several repositories or products, I analyse the procedures that pass from one system to another. It helps when debugging distributed faults and, for new features, when assessing the impact of changes. It usually goes hand in hand with maintenance: you join projects like these when the system is already live and established.
Making explicit the flows between systems, which no single repository shows in full.
With direct access to the data, the agent enables in-depth, interactive analysis and can suggest tools and algorithms. The harness records previous analyses and results, decisions and reasons, so the data flow and the reasons behind each choice can be reconstructed.
Working on test environments or anonymised data, not on production data.
In my experience, simply accepting what the agent proposes doesn't get you far. You have to get into the subject and the problem domain.
The agent reasons on the average knowledge gathered during training: it is very effective on widespread stacks and current methods, less reliable on legacy or non-standard contexts. One more reason to prefer current solutions whenever possible.
At first it seems to open new fronts quickly. Further on, though, you have to learn its vocabulary, enter its world and learn its methods: we adapt to it more than it adapts to us. On subjects far from our own experience it reasons like an expert, and gradually draws us into technical judgements that require studying the subject.
The agent gives technical terms the meaning it draws from the texts it was trained on, and that does not always match the client's, the company's rules or my own experience. Asking it to be more precise is not always enough. Where I can, I clarify the terms in the harness and check whether we are aligned afterwards; more often it is a mix: I partly align it and meanwhile learn the subject, not least because I am accountable for what gets done.
When I use it to look things up, I ask it not to stop at what the model knows: it has to check external sources and give me the links, so that I can verify the content and where it comes from.
A harness that everyone can edit degrades and loses precision. In a team it would need to be managed like code, in the repository, with an owner and a review and release process: that is a much more complex step, which I have not yet tackled on a project. For now I keep it as my own working tool, outside the project repository, with the same confidentiality as the client's code.
I can train individual developers to use coding agents methodically, each on their own work, and support them during the project.
On most projects I hand over the source code at the end of the work. With coding agents, it is worth clarifying beforehand what state it will be in.
Higher productivity is welcome to whoever commissions the work. But code that works perfectly and meets the specifications can still be hard for a person to read, while remaining easy for an agent to handle.
So I take nothing for granted about the final state of the source code: it meets what was asked for and verified, while whatever was not asked for is left to the model's choices.
If the product will also need to be taken over in the traditional way, by hand, the evaluation and validation criteria must be clarified at the start, in every form: readability, your team's conventions, documentation, tests. Like the specifications, I agree them with you. Otherwise you risk a product that works and meets the specifications but is very hard to take over.
I use coding agents only where the client's rules allow it, and with professional accounts. If the client doesn't allow AI tools, I work without them.
For data analysis I work on test environments or anonymised data, not on production data.
AI inside applications is a different subject: Artificial intelligence for SMEs
These studies measure different tasks and settings; they do not establish a productivity gain that applies to every project.