Many organizations introduced coding agents without changing how they plan, architect, document, govern or test. Faster code generation simply exposes the weaknesses already in the engineering system.
When a team adopts coding agents but leaves planning, architecture, documentation, governance and testing untouched, the bottleneck just moves. You ship more code, faster, on top of the same weak foundations.
Accelerating execution inside a system built for slow feedback doesn't improve the system. It amplifies the inconsistencies already in it.
Buy licenses, roll out a coding agent, then put KPIs on AI usage. From the inside it feels like the natural place to start. But execution is only one layer of the system, and the easiest one to change.
One engineer, working in isolation on an unconstrained side project, reports gains that look almost unbelievable. The demo convinces everyone, and that number gets read as the team's future. It rarely translates.
Adoption gets tracked as productivity gains. The teams that actually make progress optimise for something harder to see: a system that improves itself every cycle, with AI as one accelerator inside it.
Seeing this in your own engineering org? Let's find the smallest place to start.
Book an introductory call
The operating model I work from is Cycle-Driven Engineering, built on a seven-layer Engineering Loop. Every cycle of work passes through all seven layers in order, and the output of the last feeds back into the first.
Four phases. Each one ends with something you can use, not just a document. Scope and sequence flex to your situation.
I look at how your teams actually plan, build, review and ship with AI in the loop, and where the system leaks.
We redesign the practices and guardrails around the agents: planning, context, review, testing, governance.
A sequenced, prioritized plan tied to business outcomes, not a tooling wishlist.
Hands-on enablement so the change sticks after the engagement ends.
Most work starts with the Diagnosis. The rest are deeper engagements that follow from what it finds.
A two-week assessment of your engineering practices, architecture, governance, documentation and AI workflows. It identifies where AI is creating measurable value, and where it is quietly introducing risk.
You leave with A clear maturity assessment and a practical roadmap for the next 90 days.
AI doesn't simply change how code is written. It changes planning, ownership, architecture, documentation, testing, governance and review. Together we'll redesign your engineering system so humans and AI agents can work together predictably, safely and at scale.
You leave with A modern engineering operating model, practical engineering standards and a transformation roadmap your teams can confidently execute.
Changing engineering practices requires more than documentation. Through workshops, architecture sessions and leadership coaching, I help engineering leaders and teams build the habits needed to make AI-assisted engineering sustainable.
You leave with Engineering leaders and teams who understand the new system, apply it consistently and can evolve it without external support.
Some engineering organizations need ongoing guidance rather than a one-off engagement. As a trusted advisor, I work alongside engineering leadership to review architectural decisions, challenge assumptions and help the organization continuously improve its engineering system.
You leave with Continuous access to experienced engineering leadership while your organization evolves its AI-assisted engineering practices.
Not sure which engagement fits? Most start with a single conversation.
Book an introductory callI am the co-founder and CTO of Atherio, where I run a production platform day to day. Cycle-Driven Engineering, the model behind this work, was developed across a 5,000-engineer organization, my own company, and consulting teams. Fifteen-plus years in architecture and engineering leadership, and 200+ talks and workshops, sit behind every recommendation.
Read how I think ↗
Those tools make individual engineers faster. They do not change how you plan work, review it, document it or keep architecture coherent. That gap is exactly what this work addresses: the system around the tools, not the tools themselves.
Both, depending on what moves the needle. The goal is a working engineering system, so I will go as deep into the code, the architecture and the practices as the engagement needs.
It depends on scope, from a focused diagnosis measured in weeks to a longer transformation. The first conversation is about finding the smallest piece of work that creates real change.
Teams that already ship software and have started using AI, and now feel the seams: inconsistent output, review bottlenecks, architecture drift. Both scaleups and established engineering orgs.
Cycle-Driven Engineering, the operating model behind this work, was developed across a 5,000-engineer organization, my own company, and consulting teams. I run a production platform as a CTO today, so the advice is shaped by shipping, not just slides.
Bring the problem you are seeing since adopting AI. The first conversation is about finding the smallest piece of work that creates real change.