How to approach development with AI agents
Control over the output, the human as architect and tester, and a skill that makes the agent explain its design before it writes any code.
I think there are plenty of opinions on how to use agents properly in development. In this article I will share my own approach. It will probably differ from what others say, but the main ideas will certainly be very similar.
1. How to keep control over what the agent produces
I believe the foundation of using agents well in development is control over the output. We do not have to know every line of code. We should, however, know every architectural decision and understand it.
There is a real difference between the two. A line of code can be rewritten in a minute and usually nothing hangs on it. An architectural decision comes back to you six months later, when nobody remembers why it is the way it is — and rewriting it does not take a minute but weeks.
2. What role the human plays in AI agent development
In my view the human in agent-assisted development has to be above all an architect, a UX designer and a tester. Of course AI can help in those roles too — but the human has to carry a substantial part of the effort of checking.
That is the part which cannot be delegated. The agent will write you code that works. Whether it is the right code in the right place, and whether what you asked for was a good thing to ask for at all — that stays with you.
3. How to write a Claude Code skill that forces a design first
From my own experience I recommend creating a skill in which you tell the agent that before any implementation it must first explain the architectural steps it has chosen — in a predefined structure inside a Markdown file.
Tell the agent to make heavy use of mermaid diagrams, examples and charts. A diagram exposes nonsense that hides well in running prose: when the agent draws the data flow and two components talk to each other in both directions, you see it at a glance.
Such a skill might look like this:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Produce an IT analysis
---
# IT analyst
You are a senior IT analyst. You specialise in IT analyses of IT systems and their architecture.
## Workflow
1. **Understand what you are solving** — Understand the task and think it through. How to solve it? What are the alternatives? Edge cases?
2. **Produce the analysis following the template.md template**
3. **If there are answers to existing questions** - Rework the analysis based on the answers to the open questions. Do not delete the open questions or the answers, leave the originals. You may add further questions. At the end of the analysis put a summary of changes (changelog).
## Rules
- The output must follow the `template.md` template.claude/skills/it-analysis/template.md
# Template for writing analyses
## Contents
1. [Architecture](#1-architecture)
2. [Database](#2-database)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Implementation risks](#5-implementation-risks)
6. [Open questions to decide](#6-open-questions-to-decide)
## 1) Architecture
This part covers the proposed architecture of the implemented feature. It also covers how the existing architecture will change and how the feature connects to it. Suitable UML diagrams in mermaid are desirable.
## 2) Database
This part covers the proposed database model through an ER diagram. It also covers the changes to the existing database model and how the feature connects to it. ER diagrams are desirable.
## 3) Backend
A bullet list of the impact on the backend — what will have to be added / removed / changed there.
## 4) Frontend
A bullet list of the impact on the frontend — what will have to be added / removed / changed there.
## 6) Open questions to decide
A numbered list of questions to decide. Each item looks like this:
- **Descriptive name of the question**: The detailed text of the question, from which I must be able to understand what you are asking about.
`Answer`: The text of the answer, or `-` if there is no answer yet.4. Why you should let the agent design the solution first
On the basis of this skill you always have the solution proposed first, and you always approve it before anything else happens. Naturally you have to review that output properly, but the output is definitely worth it.
On top of that I think it is important to understand these fundamental questions even though the agent writes the code itself. It is the one part where it is decided whether the project will still be any good in a year.
The section with open questions in the template is there for exactly that reason. An agent tends to resolve ambiguities on its own and silently — and you find out about it once the code is finished. Force it to list the questions and you get them before anything is built on top of them.
5. How to talk through a design you do not understand
If you are unsure about some parts of the document, do not be afraid to discuss them with the agent iteratively. Talking it through will give you a better grasp of the proposed solution and will help you deliver a quality product.
It is worth noticing that this discussion has a second effect as well. When you ask about something and the answer makes no sense, it is usually not because you failed to understand it — it is because the design is faulty. Your own uncertainty is a decent detector of problems.
6. Why you should treat an AI agent like a junior
In my view we should always treat an AI agent as a junior in a given role — the role we are currently having it perform.
You give a junior a task, have them explain how they intend to do it, and then review the result. You do not hand them decisions that are hard to reverse, and you do not let them work for a week without looking. At the same time you do not stand over their shoulder for every line, because then you might as well have done it yourself.
That is exactly how working with an agent has proven itself for me.
7. Summary: three rules for developing with agents
This way of working has served me best so far. I would sum it up in three sentences: know every architectural decision, have it explained to you before any code exists, and ask about everything you do not understand.
Do you see it differently? Write to support@coden-app.com.