Agentic Engineering - 47 hours of learning to work with a team of agents

A team that is not a team.

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” - Ian Malcolm ¹

A few months ago I wrote that I was too old for this. Now I have spent almost 47 hours building software with a small team of AI agents, and I want to write down what I learned before I forget how wrong I was at the beginning.

The project doesn’t matter here (it’s an Android side project, nothing fancy). What matters is the process: how much time it took, how many tokens I burned, what I tried to fix, and whether the fix actually worked. As usual, this is a blog about processes, not about goals.

Bear with me (again)

Everybody talks about agents, so before going on, let’s clarify what an agent is, at least for me.

A chat LLM answers. You write, it returns text, and you decide what to do with it. You are the one copying the code, running it and pasting the error back.

An agent acts. Simon Willison has the shortest definition I know:

“An LLM agent runs tools in a loop to achieve a goal.” - Simon Willison ²

It reads files, runs commands, checks the result, and decides the next step by itself, again and again until the goal is done (or until it gets lost). Anthropic makes a useful distinction between workflows, where the steps are fixed by code, and agents, where the LLM directs “its own processes and tool usage” ³.

That freedom has a price, and the price is tokens. Anthropic measured that agents use about 4x more tokens than a chat, and multi-agent systems about 15x more ⁴.

From vibe coding to agentic engineering

On 2 February 2025 Andrej Karpathy coined vibe coding: “fully give in to the vibes, embrace exponentials, and forget that the code even exists” ⁵.

It has only been 20 months since then, and the internet is full of supporters and detractors, both sides with “data” and “evidence” for their opinions. There is too much data to cover here (because I don’t have time to verify all the stories), but I really suggest you do a little research.

Meanwhile the tools changed. The conversation moved from “the AI writes code” to “the AI does tasks”. On 4 February 2026 Karpathy himself picked a new name: agentic engineering. “Agentic” because you orchestrate agents instead of writing the code yourself 99% of the time, and “engineering” because there is “an art & science and expertise to it” ⁶.

Just 12 months separate both terms, but this world runs fast and you need to adapt, even if nobody is sure about what we are talking about.

And the job market noticed:

• The “Agentic AI” skill cluster went from 0.06% of US job postings in 2024 to 0.23% in 2025, more than 280% growth (~90,000 postings) ⁷. Still small, but growing fast.
• Indeed reports that US software development postings grew almost 15% since Claude Code launched, while total postings fell 7%, and 71% of that growth came from senior roles ⁸.

My reading: companies don’t want people who use AI anymore, that’s the baseline. They want people who can make agents produce reliable software at a reasonable cost. Which is exactly what I didn’t know how to do.

My “half-life seniority” is worth nothing, and I need to learn or go extinct.

The project

The goal: create an agentic engineering workflow and use it to develop a mobile app from beginning to end (right now it’s not finished, I have just reached the MVP).

I used as a reference the workflow presented by Kun Chen in this video ⁹, because while I was researching what agentic engineering really is and why the world is talking about it, this video was the one that helped me really understand how this should work. It was probably some kind of “confirmation bias”, but I needed a first step to start working on.

The numbers

I promised in my second post that I would measure time properly. This time I did it, or rather, I asked Claude Code to measure it from its own session logs: any activity counts as a continuous block unless there are more than 30 minutes without activity. It includes the time agents work alone while I am in front of the screen, but not the time thinking or planning outside.

Total: 46.9 hours in 14 days (2026-09-20 to 2026-10-18), about 1.2 weeks of full-time work.

About money: once the setup was stable, a merged pull request costs me around $4 in tokens. The most expensive week went up to ~$5.6 per PR (8 PRs, ~$45). I will explain why below.

Learnings

1. I copied a human team, and I got human team problems

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” - Melvin Conway ¹⁰

I did the same (or something similar): I designed a team of agents as a copy of some kind of small human team. My first design had four agents: a Brain that talked to me to analyse the project and plan roadmaps. Once the picture was clear, it would create the tasks and act as orchestrator, creating a “working trio” for each task: a planner to plan the task or make decisions if needed, an executor that executes (obviously), and a reviewer that checks the result without the bias or context of its two teammates. Someone who plans, someone who builds, someone who reviews, all talking to each other. Like a real team.

And the system reproduced the coordination problems of a human team.

• What happened: in the first real task the planner became a second Brain. It sent tasks to the executor, read its work, verified the environment by itself and forwarded information to the reviewer. Brain did the same checks. Most of the time the planner was just forwarding a task list that was already written in a file.
• Cost: ~9.3M cached tokens read by Brain (mostly polling loops) and ~1.3M by the planner, for a single small task.
• Measure: I removed the planner. Brain is now the only hub: it plans with me up front, the plan lives in files, and executor and reviewer never talk to each other. Transitions between them are a bash command and a state file, zero tokens.
• Did it work? Yes. A week later I had several tasks running in parallel. It’s the same hub-and-spoke pattern that Anthropic and Cognition describe ^{4 11}.

The lesson: agents are agents, not people. Talking is cheap for humans and expensive for agents, every message costs tokens and every hop loses context. An agent doesn’t need a middle manager, it needs a closed plan and a clean context. And an idle agent costs nothing, so you don’t need to “keep it busy”: create one per task and throw it away when done.

2. Measure before optimizing

• What happened: one day the executor cost $10.5, more than Brain. It was doing real UI work with lots of screenshots, so the obvious conclusion was “images are expensive”. I even asked for a deep research on how to reduce image costs.
• Measure: before applying anything, I measured the transcripts.
• Result: images were only ~10% of that cost ($1.1 of $10.5). After 7 more tasks, they were between 1% and 9% (18% in one task with 26 screenshots). The real cost was text context growing inside long sessions: 55-70% of the executor’s cost was in its first round, with the context going from ~20k to 150-226k tokens.
• Did it work? The optimization was never applied, and that was the success. The research served to discard an “obvious” improvement that wasn’t one. Coming from the guy who wrote that visual checks burned all his tokens in 10 minutes ¹², I find this funny.

The lesson: measure a lot, measure everything. If there is a task the AI is good at, it is measuring. All my sessions were analysed by a separate Claude Code session: not an agent, not even in the same project. The agents only know about the app they are building, but I have another session as an external observer, taking metrics and talking with me about the process.

3. Fewer steps, fewer tokens

• What happened: I was using the OpenSpec skill, to learn it and to organize the work. I decided that archiving each finished task would be a separate PR, because I wanted to check it myself. I was the “human in the loop”, and I didn’t want to consider a task closed until I, “the mighty human”, validated it (as if I could: I have never used Kotlin in my life, so my validation is not… the best one). This required its own PR, with its own agent, review and gate run, just to move files. It cost time and tokens.
• Measure: archiving is now the last step of the task, inside the same PR.
• Did it work? Yes, one full cycle less per task.

The lesson: what works for humans doesn’t work for agents. In a previous post I talked about documentation that is going to be read by AIs, and it seems that processes follow the same rule. Design the process for AIs, don’t copy human processes.

4. Locate the new bottlenecks

• What happened: the first time I ran two tasks really in parallel, both fought for the only Android emulator (blocked twice, one live validation never done) and for the only gate slot.
• Measure: not done yet. This is interesting because the bottlenecks in a human team are quite different from the ones in an agent team. At the beginning I was the bottleneck: I was unable to review the work and answer Brain faster than the workflows generated changes. Once I found my pace, I discovered that the limited resources (in this case the emulator) were making my agents wait. It’s not a big issue, as an idle agent has no cost, but it’s one of the things I want to learn to solve. To really exploit the power of having multiple workflows working in parallel, I must find a way to solve this.

5. Big changes eat review rounds

• What happened: one PR passed the 400-line limit (a measure I chose to help me with my manual code reviews) and I accepted it as an exception. It needed 4 review rounds and 5 gate runs in two days. Every round found a different concurrency bug in the same class, so my rule “the same finding twice gets escalated” never triggered.
• Cost: this PR is why that week went from ~$4 to ~$5.6 per PR.
• Lesson: the size warning was right. I should have listened.

6. Small things that worked

• Bug policy without asking: every time a bug was found, everything stopped, waiting for my approval. The human in the loop should have its limits. We cannot allow the agent to go all the way until it reaches its goal, but if the agent is so limited that it needs your validation for everything, you will collapse as soon as you launch 7 parallel workflows. So bugs introduced by the PR are always fixed automatically. Existing bugs are fixed in the same PR if they are small and in code the PR touches; if not, a new issue. Fewer questions to me, fewer interruptions.
• Context cleaning: Brain’s context grows without control. He needs to talk with me, send inputs and read the outputs of all the other agents, and that proved to be an issue. So when the context reaches a key size, he writes a checkpoint file, I clear the context, Brain starts fresh, and we save a lot of tokens without losing quality.

Conclusion

Forty-seven hours later, my main learning is not technical. With agents, I design the communication structure, nothing is given. What my seniority can provide is designing the process, not the code. But I cannot copy a human team: the costs, the tools, the ways of working… all must be designed based on how agents work.

And I didn’t talk about skills and models (each agent has a different set of them, based on the task it needs to do). Fine-tuning the setup is an everlasting task that only the human can do, and I still need to learn how to do it (I am on my way).

And remember: intuition is cheap, measuring is cheaper. Twice I was sure about where the tokens went, and twice I was wrong. My curated intuition needs to be recalibrated; meanwhile, measure like a crazy developer.

Hope you enjoyed this.

Thanks for reading.