Most of my working day used to be typing. Today most of it is writing tasks for coding agents, reading what they produce and deciding what gets merged. I am a Senior AI Engineer at Mokka Studios, I am CTO of IGEA, and I spent the first half of 2026 as tech lead on Estyl's AI backend. Across all three, the code still has to be right, and I am still the one who answers for it. What moved is where my hours go.
This post describes that shift as I live it, with the setup I actually use, so a developer can decide whether to work this way and a CTO can decide what to ask of the team.
What is an AI-directed engineer?
An AI-directed engineer is a developer who delegates most of the typing to coding agents and keeps the engineering: deciding what to build, splitting it into tasks an agent can finish, setting the rules the agents must follow, and reviewing every diff before it ships. The agent writes the first draft of the code. The engineer owns the design, the tests and the merge.
The tooling is now normal for most developers. In the Stack Overflow Developer Survey 2025, 84% of respondents said they use or plan to use AI tools in their development process, and 46% said they distrust the accuracy of those tools (Stack Overflow Developer Survey, July 2025). Both numbers matter for this job. Engineers use the tools a lot and trust them little, which is why the work moves toward specification and review.
What does a working day look like for an AI-directed engineer?
A typical day for me has four kinds of work, and none of them is long stretches of typing.
- Writing tasks: a short brief per change with the goal, the files involved, the acceptance criteria and what must not change.
- Running agents in parallel, each in its own git worktree, so two agents never edit the same checkout.
- Reviewing: reading diffs, running the tests, sending work back with a precise note.
- Deciding: what gets merged, what gets cut, and which task comes next.
The parallel part runs on two open source tools. herdr is a terminal multiplexer built for coding agents: each workspace holds an agent, and I can see which ones are working, blocked or done. treehouse keeps a pool of reusable git worktrees and leases one to each agent, so an agent gets a clean checkout and returns it when finished. My global instructions say it plainly: if a change touches a repo, open a worktree first. The parent session stays the orchestrator and does not edit code; each child session gets one branch and one task and reports back when it is done or waiting for an answer.
That split is the job. I route tasks, answer the questions the workers raise and review the results.
| Activity | Traditional developer | AI-directed engineer |
|---|---|---|
| Main output | Code typed by hand | Task briefs, rules, reviewed diffs |
| Unit of work | One branch at a time | Several branches in parallel worktrees |
| Tests | Often written after the code | Written first; the failing test is the spec |
| Coding standards | Kept in people's heads and in review comments | Written down in files the agents read on every task |
| Review | A colleague's PR, a few times a week | Every diff from every agent, every day |
| Main bottleneck | Typing and debugging time | Clarity of the task and review speed |
| Responsibility | Owns the code | Owns the code, including code an agent wrote |
Which guardrails keep coding agents on track?
Agents follow the rules they can read. Rules that live only in my head get broken on every task, so the guardrails have to be files in the repo. On this portfolio site, which runs on Next.js and Sanity, the setup is small and works:
- A CLAUDE.md at the root with the non-negotiable rules: test-driven development (a failing test before the code), pnpm only, never open a pull request, add every new translation key in both English and Italian.
- A CODING_STANDARDS.md that every diff is reviewed against.
- Skills: short instruction files for recurring jobs. There is one for TDD, one for testing, and one for blog posts that sets the structure, the SEO limits and the evidence rules this article follows.
- A ship workflow that runs review agents in parallel on the diff (one checks only test quality), then lint, typecheck and tests, and merges only when all of it passes.
- Git hooks that reinstall dependencies after a checkout or rebase when the lockfile changed, so an agent does not "fix" a failure caused by stale packages.
Tests first is the guardrail that does the most work. A failing test is the most precise task description I can give an agent: it says what done means, and the agent cannot argue with it. Without tests, I end up reviewing intentions instead of behavior.
Which skills matter most for an AI-directed engineer?
Five skills decide whether this way of working pays off.
Decomposition comes first. A task an agent can finish well touches a few files, has one clear goal and can be verified by a test. "Refactor the backend" fails. "Move the cost logging into the shared client and add a test that every call writes a cost row" works.
Writing clear tasks is the second. A good brief names the files, the expected behavior, the constraints and what is out of scope. Agents fill gaps with plausible guesses, and every guess is something I have to catch in review.
Reading diffs fast is the third, and it is the skill I see underestimated most. When several agents deliver in a day, review speed sets the team's throughput. I read the tests first, then the interfaces, then the implementation.
Testing is the fourth. An engineer who cannot write a good test cannot give a coding agent a good specification.
Saying no to over-engineering is the fifth. Agents add abstractions, config options and helper layers nobody asked for. Most of my review notes are deletions. When I rewrote the AI pipelines of a consumer finance platform, the AI cost savings of about 80% came from removing redundant model calls and trimming context. That work is cutting things, and it is the same instinct I use on agent output.
What doesn't change when agents write the code?
Responsibility does not move. If an agent writes a bug and I merge it, it is my bug. In regulated work this matters more: at Sprint Reply I built an LLM agent that routes more than a million bank help desk tickets a year, and nobody at the bank would accept "the model wrote it" as an explanation for a misrouted complaint. The same holds for the IGEA voice agent that answers patient calls at a clinic.
Understanding the system does not move either. To review a diff I need to know how the system works: where data comes from, what the failure modes are, which parts are fragile. An engineer who stops understanding the system becomes a rubber stamp, and agents produce plausible code faster than a rubber stamp can spot the wrong parts.
The craft of design stays with the engineer too. Agents are good at filling in a structure. Choosing the structure, deciding which module owns what and where the seams go, is still a human decision, and the agents follow it better when it is written down.
How should a CTO introduce AI-directed engineering in a team?
Start with the rules, before buying more seats. A team that writes its coding standards, testing rules and repo conventions into files gets consistent output from agents. A team that skips this gets a different style in every pull request.
Then pick one repo and set up the basics: a root instruction file, tests that run fast, a lint and typecheck gate, and a review step every change must pass. Measure what reaches production and what gets reverted. Lines of code produced are not a useful metric here, since agents produce plenty.
Finally, change what you ask of seniors. Their value moves toward writing specifications, reviewing and saying no. If they are still judged on how much code they type, the incentives point the wrong way.
What are the common mistakes when moving to AI-directed work?
- Letting agents work in the same checkout. Two agents editing one working directory produce conflicts and mixed diffs. One worktree per agent fixes it.
- Skipping tests because the agent is fast. Speed without a test only produces unverified code sooner.
- Rubber-stamping long diffs. If a diff is too long to review, the task was too big. Split it and redo it.
- Writing rules in chat instead of in files. A correction typed into one session is lost in the next. Put it in CLAUDE.md or a skill.
- Accepting extra abstractions because they look professional. Every layer an agent adds is code someone has to maintain.
- Running more agents than you can review. Throughput is capped by review, so adding agents beyond that only grows the queue.
Want to set up AI-directed engineering in your team?
I help teams put the guardrails in place: instruction files, test-first workflow, parallel agents and a review gate that holds.
Let's talkIf you build AI products as well as using AI to build them, see how I approach AI agent development for regulated companies.
