I started writing this article in May when I was regularly using an agentic engineering process, with the agent responsible for most of the implementation. At the time, I was pleased with the result and was using a SDD (Spec-Driven Development) tool called OpenSpec on Claude Code Opus 4.7. It was a foray into the world of Harness Engineering and I have evolved my process since then. However, despite my efforts I've noticed a degradation of the output in recent months and have made pivots to return to my desired quality. As such, I've decided to rewrite my old post. I'll outline briefly where I was before introducing any form of agentic process, where I was in April and where I stand today.
Before SDD
I used agents, Claude my chosen flavour, as an accelerator and rubber duck. This was with Sonnet and I delegated simple tasks - boilerplating APIs in a codebase with lots of examples. I found it useful for debugging but I had no system to prevent the same mistakes from happening time and again. I had tools and techniques such as linters, self and peer reviews to ensure the output met the quality bar, but I found I was spending more time reviewing than I would than if I or another wrote the code. Lastly, I wasn't enjoying the experience. I felt like I was demanding an agent to do something rather than solving a problem collaboratively.
My first agentic engineering process
The goal was to use agents to fully write the code end to end, not just the simple tasks nor as Stack Overflow in my terminal. This was my first exploration into SDD and harness engineering. I tried and researched a few different tools (SpecKit, Kiro, Tessl) before settling on OpenSpec. It is advertised as spec-anchored - the specs are kept as a source of truth and are updated over time as the code evolves.
I introduced my first harnesses - contract testing, mutation testing and detailing principles the agents should follow when designing and writing the code (KISS, DRY, TDD). This was backed by hooks to enforce to ensure the agent ran within the harnesses and skills to make components consistent (writing a consumer or provider test in a particular fashion). The culminating project using this process was building out a API that orchestrated a checkout process and integrated with a third-party payment provider.
My agentic-engineering process was inspired from reading these articles and I'd encourage you to check them out:
- Mitchell Hashimoto's AI adoption journey, particularly around "Harness Engineering"
- Birgitta Böckeler's analysis of several SDD tools
- Kief Morris' on Human's in the loop
The key takeaway for me was having a structure where if the agent did something wrong, something was put in place to ensure it didn't do it again. A SDD tool could provide me the structure I was missing to walk the fine line of the "right amount of context" and provide a more enjoyable development experience using Claude.
My problems and where I stand now
The problems I've experienced lately are:
- Similar stories take longer to deliver than before.
- The output of a similar story is larger and not necessarily useful (design overly complex and riddled with large doc-strings).
- The output lacks the quality as before (code unreadable or not easily debuggable).
- Prompt responses from the agent are convoluted and hard to understand. I've seen this described as "Narration Tax". This article described a lot of my feelings on this.
As a result, I'm intervening into the implementation process more and cycle time grows, as I try to provide more harnesses.
My issues started happening as Opus moved to versions 5.3 and 5.4 and whilst I've begun to read promising signs that Opus 5.5 is beginning to curb its narration, I've decided to lean more into my harnesses and make changes to my process.
The lesson for me is that an agentic engineering process cannot depend on one model behaving exactly as it did last month. If a model update can materially reduce my output quality, then I do not yet have enough process, feedback, or harnessing around it.
In the spirit of this, one of the biggest wins I've had is switching back to Sonnet. If I can trust my harnesses then why spend extra tokens on Opus when Sonnet can do it quicker and provide a snappier prompting experience.
I have also been experimenting with other tools outside of SDD and started using SPDD (Structured-Prompt-Driven-Development) which you can read more about on Martin Fowler's blog. I prefer the idea of "saving the prompt" as the primary artefact, versus generating a spec from the prompt. SPDD is perscriptive on when to use it and I believe provides a smoother, less command heavy, spec-anchored process.
Going forward
The more I use these tools, the more I think the valuable skill is not prompting alone. It is designing the environment the agent works inside. The tests, specs, prompts, hooks and review habits matter because they give the process memory. They are what stop the same mistake becoming part of tomorrow’s work as well. I am still experimenting, and I expect this process to keep changing.