Since 2000 I have watched frameworks and technologies come and go, each promising to make development more productive and almost never really delivering. With coding agents something is changing, despite many weak points. I use them, Claude and Codex in particular, not as a chat to ask questions, but on a spec-driven method and a knowledge base built project by project.
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 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.
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.
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.
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, which is especially useful when adherence to them is checked. 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 analysis in real time 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.
A harness that everyone can edit degrades and loses precision. In a team it would need to be managed like code, with an owner and a review and release process. That is why today it is my own working tool, kept outside the project repository and treated with the same confidentiality as the client's code.
An agent makes a junior a better junior and a senior a better senior: it raises everyone's productivity, but it doesn't close the gap.
It also changes how junior developers are trained. The risk is someone who doesn't grow and just keeps prompting the AI until something works. That is why I ask the juniors I mentor to build their own direct understanding of the product, and I always discuss their assigned items with them. It is the same principle I follow as a team lead.
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.
It is a different subject from AI as a development tool, and it deserves the same concreteness.
Someone who, like me, builds and maintains enterprise applications comes across AI inside applications far less often than the current hype suggests. Apart from truly innovative services, which probably need specialist staff, the most common request is still "chat with your data". And even there a sharp distinction is needed.
A RAG system that queries a set of documents and answers while staying faithful to the texts is relatively simple. A tool that performs precise analysis and gives correct answers is a different job: deterministic code has to work together with a language model that by nature is not deterministic, and the effort grows far faster than the precision you gain.
Coding agents know these subjects very well; it is their home ground. But here too, to get far you have to get into the problem domain.
The project, architecture and costs in detail: Applications with built-in AI