From Copilot to Co-Workers: How an Agent-First Playbook is Redefining Engineering at Fenergo
"Motivation, you don't need to give him. Ambition, you don't need to give him. Technique, you don't need to give him. You give some tactical adjustments and let the guy be happy." — José Mourinho, on coaching Cristiano Ronaldo at Real Madrid
The same was true of Drogba at Chelsea. You don't teach a natural striker how to score. You build the system around him that makes him unstoppable.
That is the exact philosophy behind what we have been building at Fenergo.
Our engineers are exceptional. They always have been. What we asked ourselves was a different question entirely: what if we stopped thinking about AI as a tool that helps individuals write code faster, and started thinking about it as a system that makes the whole team capable of winning championships?
That question led us to build the Agent-First Engineering Playbook — and what has happened since has genuinely surprised us.
The Shift from Copilot to Agent-First
Most engineering organisations using AI today are still in the copilot phase. A developer opens their IDE, starts typing, and accepts or rejects inline suggestions. It helps. The productivity gains are real. But the mental model is still the same: one developer, one task, one stream of work.
The acceptance rate tells the story clearly. Across the engineering team, inline Copilot suggestions were being accepted at a rate of 32%. Not bad — but it reflects a mode of working where AI is an assistant you consult occasionally, not a collaborator you trust with real work.
When we shifted to an agent-first model, that acceptance rate moved to 86%.
The difference is not the model. The difference is the system around it — the context, the instructions, the defined roles, the skills. When an agent knows exactly who it is, what it is responsible for, and how to approach its work, the output earns trust. And when engineers trust the output, they act on it.
Meet the Swarm
The playbook deploys a fleet of specialised agents, each with a defined role, personality, and area of responsibility covering the full product development lifecycle.
The Technical Architect turns designs and requirements into detailed implementation plans before a line of code is written. The Partner Engineer implements features in C#, TypeScript, and React. The Code Reviewer scrutinises pull requests for quality, consistency, and correctness. The Test Engineer writes and reviews tests across all layers. The Security Engineer hunts vulnerabilities. The Deployment Engineer manages infrastructure as code. The Site Reliability Engineer monitors production. The Tech Writer maintains documentation. And the Product Owner writes functional specifications and keeps the backlog sharp.
Each agent is not just a prompt. It is a role, with a personality, a defined scope, and a library of Skills — step-by-step workflow documents encoding real lessons learned from production delivery. Skills for semantic C# navigation using LSP instead of grep. Skills for E2E API test authoring. Skills for Playwright browser testing. Skills for React component coverage. The institutional knowledge of the engineering team, captured and made executable.
This is not AI assistance. This is an AI engineering team, working in parallel with your human one.
TDD: The Broccoli Problem
TDD is the broccoli of software engineering. Every engineer knows it is good for them. Most engineers will tell you they do it. Almost none of them actually do it consistently. We were no different — until we gave the job to an agent that does not cut corners, does not get lazy at 4pm on a Friday, and has never once said "I'll add the tests later."
The TDD Workflow Manager agent orchestrates the red-green-refactor cycle with a discipline no human team sustains reliably under delivery pressure. Tests are now almost exclusively authored by our Test Engineer agent, with coverage climbing steadily across both code and logic. When the fleet of agents works in tandem with TDD as the operating standard, the output quality is categorically different. We are already moving toward enforcing it as the default — not because we are mandating behaviour, but because the results make the case themselves.
The Moment Everything Changed
Theory is one thing. What happened in practice deserves to be told properly.
Our CTO, Keith Redmond, was the first to lean in — not from a distance, but hands-on, leading by example in a way that set the tone for everyone who followed. He pointed the Code Reviewer agent at our entire codebase — over 100 repositories in Azure DevOps — and let it run, unattended, for four days.
It returned a storyboard of technical debt and posture improvements spanning the entire estate. Every item tagged, categorised, and ready to be acted on. The sweep has continued to grow as the agent works through areas of the codebase that had not seen structured review in years.
Engineers were encouraged to point their agent fleets at the storyboard and pick up work items. Meanwhile, the leadership team sat down to discuss market strategy and roadmap priorities.
While we were in that room, pull requests started arriving in inboxes.
The storyboard is not a retrospective. It is live and still moving. Agents are actively working through items in progress and analysing others in the pipeline — autonomously, in parallel, while engineers focus on product delivery.
The headline is this: a substantial share of the storyboard is already deployed to production, with more resolved, ready for production, or in their final stages. All of it delivered on top of the team's normal workload — not instead of it. Without a single sprint ceremony, without a single refinement session, without touching the roadmap. The engineers were heads-down on their committed features. The agents were clearing technical debt that had been accumulating. Both happening simultaneously. That is the compounding effect that no individual productivity metric fully captures.
What stands out beyond the velocity is the quality signal embedded in the outcomes. A small number of items were rejected — not by a human reviewer catching an agent mistake, but by the Product Designer agent, which applied its deeper domain context and scope awareness to determine they were irrelevant or out of place for their specific area. A handful more were flagged as requiring more information before proceeding — the swarm knowing the limits of what it knows.
Agent-to-agent quality control. The system self-governing.
An exceptionally high relevance rate across an autonomously generated body of work spanning the whole estate. That is not a pilot. That is an engineering operating model.
The Honest Part
None of this happened smoothly from day one, and it would not be honest to suggest otherwise.
The first friction we encountered was uneven adoption — and when we looked closely, it was not laziness or indifference. It was fear. A quiet, understandable, almost subconscious concern that an agent doing your work means you are no longer needed to do it.
Getting past that required two things. First, leadership being explicit and consistent: this is a force multiplier, not a replacement. The engineer who works with a fleet of agents does not get replaced by the fleet — they become capable of delivering at a scale no individual engineer ever could. Second, the benefits had to materialise visibly and quickly enough for people to feel it themselves. Once they did, adoption accelerated fast.
The second friction was more technical: context is king. Not every engineer arrives with the same instinct for how to frame work for an agent, how to write a work item that gives the agent what it needs, how to calibrate instructions for the right level of autonomy. That is a skill being built in parallel with the playbook itself — and on every iteration, the agents and the guidance improve together.
The third is trust and accuracy calibration — an ongoing process. We are still maturing. The playbook is a living document precisely because real delivery surfaces things that theory never anticipates. Every edge case, every surprising rejection, every agent output that made an engineer pause and think — all of it feeds back into the system and makes it sharper.
We are not at the end of this journey. We are at the beginning of knowing what the journey looks like.
What the Signals Say
We are still early. The adoption curve is still climbing, and we are deliberately honest about that. But the signals are clear enough to share.
Velocity on functional deliverables has increased 2 to 3x. Technical debt reduction is running at 4 to 5x. These are not percentage improvements — they represent days and weeks recovered on epics and features that would otherwise have stretched across quarters. The gains in product and design, while at an earlier adoption stage, are already measurable and growing.
What the signals describe, in the end, is a shift in what the team is able to attempt. Work that used to be deferred indefinitely is now being picked up and closed out in parallel with the roadmap. That is the outcome that matters.
What This Actually Means
Mourinho did not win championships by teaching Ronaldo to shoot or Drogba to score. He won them by building a system where world-class players could operate at their absolute peak — with clarity of role, tactical support, and the freedom to focus on what they do best.
That is what the Agent-First Engineering Playbook is for our engineering teams.
Our engineers are not being replaced by agents. They are being freed from the work that was always below their capability — the boilerplate, the repetitive test authoring, the documentation that never got written, the technical debt that never got prioritised. Freed to do the work that actually requires a human: judgment, architecture, domain expertise, creative problem-solving, the decisions that matter.
The agents handle the backlog. The engineers handle the game.
The championships are ahead of us.
A genuine thank you to Keith Redmond for leading by example — for being the first through the door, for the storyboard that started all of this, and for making it impossible for the rest of us to stay comfortable with the old way of working. And to every engineer who leaned in despite the uncertainty — your curiosity and courage are what make this team worth building.
The playbook is open. It is yours to shape. Contribute, refine, improve — that is how it gets better.
Warm regards,
Evangelos Liatsas
Director of Engineering
Fenergo Ltd