Agentic Engineering — Addy Osmani (#Books)
On the flight to the Maldives, I read Agentic Engineering by Addy Osmani. The book is still in early access: my version has five of the eighteen planned chapters. And much of it already feels familiar. Osmani does a good job of bringing together things you gradually discover while working with agents: code arrives faster and faster, while questions about your own work keep multiplying.
The chapter on specifications particularly resonated. As writing code becomes cheap, understanding exactly what needs to be done matters more. With Spec Kit, this regularly happened to me during clarification itself: you start with a seemingly clear request, the agent asks questions, and you discover that the problem is more complicated and the desired outcome slightly different. In the process of expressing the requirements, you reconsider your original idea. That is how specs became a thinking tool for me.
Take “add PDF attachments to the website” for annotated whitepaper discussions. Sounds like a download button. Then come the questions: do we store a copy or a link? How do we confirm it is the right document? What happens when we import it again? Can we call the transfer complete if the page opens but the file is unavailable? Gradually, behind the button, you uncover an entire process for transferring a publication without losing anything. There will be a button too :)
Of course, an agent can write a polished spec, the plan, the code, and a report saying everything is done all by itself. For me, the value of this work lies in the moments when I have to say, “I hadn't considered that” or “I'm not willing to accept that much complexity.” If clarification leads us to drop half the work, that is a useful outcome too.
You just wish you did not have to explain everything you have already worked out at the start of every new run. This is where Osmani's discussion of the harness — the agent's working environment, with its tools, context, and checks — resonates with me. I see it as a place where a team's experience can accumulate. Why an architectural decision was made, how to carry out a recurring task, which mistake a test now catches: all of that remains available to the next agent.
Still, I would push back on the formula “every mistake becomes a rule.” You could end up with an impressive collection of prohibitions that nobody can make sense of. Sometimes it is more useful to fix the tool or remove an outdated instruction. I like the idea of turning experience into the conditions agents work under, but that environment will need looking after too.
With multiple agents, the cost of those agreements becomes even more noticeable (especially when the agents come from different camps, such as Claude, Codex, Cursor, and Open Code running Chinese models). While there is just one agent, you can keep a lot in your head and correct things along the way. If one builds the importer and another handles document display, they need to agree in advance on what they will pass between them. Otherwise, both will finish their work, and you will be left reconciling two different understandings of the task.
I agree with Osmani here: an agent's autonomy and the ability to coordinate several agents are different things. You can give one agent considerable independence or supervise several closely. The number of open windows alone tells you little: it is easy to accumulate a queue of changes you no longer have time to understand. The code is being written while you handle questions, switch between tasks, and review other agents' decisions. Less hands-on work, more decisions per unit of time.
I am particularly looking forward to the chapters on the orchestration tax and three kinds of debt: technical, cognitive, and intent debt. Judging by the opening chapters, the book captures a familiar feeling: we can do more, yet somehow things have not become simpler. I am curious to see where Osmani takes the discussion next.
#Books #AI4SDLC #Agents #Engineering #Management