Agentic Coding in Practice: What I Have Learned Working Solo and With a Team (Part 1)
Four lessons from working with coding agents across solo projects and team environments — on when to go solo, what not to delegate, which documents to maintain, and why modularity is no longer optional.
These are notes from actual work, not theory. I have used coding agents on projects ranging from solo builds over a few weekends to team environments with multiple developers working in parallel. Part 1 covers four lessons that have held up across both contexts.
1. Go solo if you have the option
If you have a genuine choice, working alone with an agent is faster than working in a team with agents. Not marginally faster — significantly faster.
The reason is coordination overhead. The moment you have more than one developer, you have pull requests, branch conflicts, review queues, and the cognitive cost of understanding each other’s agent-generated code. A solo developer with an agent sidesteps all of that.
This is not always feasible. Large projects, enterprise environments, and work that requires specialised knowledge across multiple domains will still require teams. But if you are scoping a project and solo is a viable option, take it. The productivity difference is real.
2. Never outsource requirements, system design, or database design
This is the rule I hold most firmly, and the one I see violated most often.
Coding agents are capable of doing a plausible version of all three. That capability is exactly what makes it dangerous to hand them over entirely.
Requirements. Use the agent’s grill-me capability — there are well-documented prompts for this across Claude Code, Copilot, and other tools — to build a thorough requirements document through interrogation. But read that document in full before you proceed. Every word of it. The agent is extracting your requirements, not inventing them. If the document does not match what you intended, the problem is yours to fix before any code is written.
System design. You should own the low-level design. Ask the agent to contribute, challenge your decisions, and surface options you have not considered. But the decisions should be yours. If you understand your system design less well than your agent does, you will not be able to evaluate what it builds, catch what it gets wrong, or explain it to a client or a colleague. That is a problem at every stage of delivery.
Database design. The same principle applies with one practical exception: agents are often better than humans at index optimisation and normalisation mechanics. Use that. But you should know your schema, your relationships, and your access patterns better than the agent does. The agent can optimise the plumbing. You need to own the structure.
The thumb rule is simple: you should know your requirements, your design, and your database better than your agent does. If that is not true at any point in the project, stop and fix it before continuing.
3. Generate the five documents and keep them current
This is the part of agentic development that most teams skip because it feels like overhead. It is not. It is what makes the entire approach sustainable across sessions and across team members — human or agent.
requirements.md — the output of the grill-me session. Written in user story form. This is the base from which modules, tasks, and subtasks are derived. Everything downstream traces back to it.
readme.md — the standard repository readme. Its primary audience is whoever comes to the repository next, human or agent, with no prior context. If a new agent session cannot orient itself from the readme alone, the readme is not doing its job.
plan.md — modules, tasks, subtasks, and the logical sequence connecting them. This document also carries a remarks section for human-readable notes, and a status field for every task. It is both a planning document and a live view of where the project stands.
progress.md — append-only. Every task entry records a start timestamp, an end timestamp, the commit hash, and remarks if needed. Over time this becomes a productivity record, a debugging aid, and a reference that future sessions — human or agent — can use to understand what happened and when. Do not edit existing entries. Only append.
claude.md (or the equivalent for your agent) — the rulebook. This captures your coding preferences, folder structure conventions, commit message format, access rules, and any hard constraints like no emoji in code or mandatory unit test coverage. Write this yourself. Never delegate it to an agent. It can live at the system level, the project level, or the module level — or all three.
One rule to add to every claude.md: with every commit, update requirements.md, readme.md, plan.md, and progress.md. This keeps the document layer current without requiring a separate maintenance pass. The agent does it as part of the commit, not as an afterthought.
4. Modularity is not optional anymore
Modularity and the single responsibility principle have always been good practice. In agentic coding they are non-negotiable.
The reason is context. A coding agent works best when it can focus on one well-bounded problem without needing to hold the entire codebase in mind. Tightly coupled modules create dependencies that span that boundary. The agent has to understand more to do less, and the risk of it getting something wrong increases proportionally.
There is a practical test for whether your modules are modular enough: can your agent start a fresh session with only the documentation — requirements.md, readme.md, plan.md, claude.md — and pick up the work correctly, without needing memory of previous sessions?
If yes, you are in a good position.
If the agent needs memory of previous sessions to function correctly, your modules are too tightly coupled, your documentation is not capturing the right things, or both. Either way, that is a risk that compounds over time. An agent dependent on accumulated context will eventually produce code that drifts from what the documents say — and at that point, the documents are no longer the source of truth.
Keep the modules independent. Keep the documents current. Let every session start clean.
Part 2 will cover branching strategy under high PR volume, testing team readiness, and what happens when agentic development runs into compliance constraints.
If you are working through any of these challenges on a current project, the Idea Lab is a good place to think it through before committing to an approach. For a direct conversation, the contact section is there.