Engineering Governance in the Era of Agentic AI: The Foundational Engineer
A written version of my talk at DevOpsDays Cairo 2026, delivered on 26 September 2026 and adapted here for swac.blog. A recording of an English off-stage run of the same talk can be watched on the SWAC YouTube channel. Key slides are included below as figures.
I recently gave a talk at DevOpsDays Cairo 2026 called “The Foundational Engineer: Engineering Governance and Anti-Burnout in the Era of Agentic AI Co-Workers”. It was aimed at software engineers and DevOps engineers at every level, from seniors to tech leads and staff engineers. The core idea is simple: when powerful AI agents write much of the code, engineering governance is what keeps teams in control, and it is also what keeps the people on those teams from burning out. As I did with my earlier recap on spec-driven development with Kiro, I am turning the live session into something you can read at your own pace.
I. A story from 1969
I opened with a photo from 1969. A young woman stands next to a pile of printed pages, almost as tall as she is. That is Margaret Hamilton, who led the software team behind the Apollo guidance computer, and the pile is the printed assembly code that helped take two astronauts to the Moon and back. She is also credited with popularizing the term “software engineering” (see the MIT News story behind the photo).
Figure 1: Margaret Hamilton and the printed Apollo guidance code (1969). Photo: Draper Laboratory / MIT Museum, public domain.
Then I asked the room a question: does anyone still write assembly by hand? Almost nobody does, except in very specific domains. We work several abstraction layers above it and think nothing of it. That question leads to what is happening today. The picture has changed. A very powerful team, a team of agentic AI engineers, now sits in the engine room waiting for our directions, doing the coding, debugging, testing and refactoring. We, the foundational engineers, are the captains, taking care of the roadmap, the vision, the product goals and the user values.
II. Is this new? Yes and no
It is not new, because we have built abstraction layers before. Compilers let us write C instead of assembly. CSS frameworks such as Bootstrap and Tailwind turned raw CSS into reusable design systems. React, Vue and Angular structured raw JavaScript, and Node.js, Laravel, Symfony and Spring did the same on the backend. Every time, we worked at a higher level and trusted the layer below to handle the details.
It is new in one important way: the layer below us is no longer deterministic. Give it the same input twice and you may not get the same output. Without the right guardrails, we lose control and end up in a garbage-in, garbage-out situation, which leads straight to frustration and burnout.
III. Engineering governance has a human outcome
Robert C. Martin (Uncle Bob) puts it well: govern your work, or have it governed for you. If we do not define our own disciplines, standards and ethics, they will be “forced upon us by those who don’t know us.” The theme runs through his book Clean Craftsmanship: Disciplines, Standards, and Ethics.
Good engineering practices protect the codebase, but they also protect the people building it. Without governance, teams spend their days on rework from unclear requirements, avoidable defects, merge conflicts, production firefighting, and constant context switching. That is not only an efficiency problem. Sustained over time, it is a burnout problem.
IV. Four pillars of engineering governance, one goal
The talk covers four pillars of engineering governance. Three are old, tool-agnostic engineering foundations, and only the last one is specific to the AI era:
- Test-Driven Development (TDD): prove it works, against agreed coverage gates. The anti-burnout effect: stop losing sleep over whether it works.
- Spec-Driven Development (SDD): know what you are building, and why, before you build it. The anti-burnout effect: stop rebuilding the same thing several times.
- Trunk-Based Development (TBD): pass Jez Humble’s continuous integration test. The anti-burnout effect: no more end-of-sprint merge dread.
- Modern workflows in the AI era: no model is the sole judge of its own output. The anti-burnout effect: govern the agents, do not babysit them.
Figure 2: The four pillars, each with a governance goal and an anti-burnout effect.
V. Pillar 1: Test-Driven Development
TDD is not new. It is one of the 12 original practices of Extreme Programming (XP), and the cycle is familiar: write a failing test (red), make it pass (green), then refactor without changing behavior. XP also includes a “40-hour week” among its 12 practices, which is a nice reminder that sustainable pace was a core engineering idea long before anyone said “AI burnout”.
Figure 3: TDD and the red-green-refactor cycle.
Here is my honest confession: I usually do not practice strict TDD. TDD means test-first, and I usually write tests after the implementation, because test-first is counterintuitive for many teams. What I never skip is automated coverage and quality gates on everything that ships. The engineering governance goal is not ceremony. It is confidence that AI-generated changes are actually being verified, and a safety net that lets us change code whenever we want.
Coverage tools help a lot here. Terminal reports show which branches are not covered, and web tools such as Codecov give every team member the same view. Git Truck is a nice companion: it visualizes your repository as a bubble chart, tree map or partition by file size, commits, line changes, top contributors and last change, so humans keep a clear picture of the codebase.
Figure 4: Git Truck, a test coverage companion for understanding your codebase.
VI. Pillar 2: Spec-Driven Development
With spec-driven development, a specification is authored and agreed upon before implementation begins, and it becomes the single source of truth for what to build (IBM’s definition says the same). In practice it is a simple chain: requirements, design, tasks, sometimes called PRD, SPEC, PLAN. All of this exists before any AI agent touches the code.
Figure 5: Requirements, design, tasks: the spec-driven development chain.
The important point is that SDD is an engineering governance discipline, not a product. If you understand that, you become tool-agnostic. Among the open source tools are GitHub’s Spec Kit, OpenSpec and the BMAD method, which covers the whole Agile cycle. Kiro from AWS is a closed source option. I am not pushing any of them, and you can practice SDD without any tool at all.
VII. Pillar 3: Trunk-Based Development
Teams often favor long-lived branches and integrate at the very end: every developer works on their own branch and merges into main at the end of the sprint. Trunk-based development does the opposite and integrates in small portions, continuously. The history runs from Git flow, to GitHub flow, to TBD. Martin Fowler, in his continuous integration certification post, says it is only continuous integration if it runs on “a shared mainline that people commit to every day.”
Why does this matter for engineering governance? Because feature branches lead to the Big Bang. The diagrams below come from Fowler’s article. Two developers, Scarlett and Violet, work on their own branches. A hotfix lands on the mainline and both pull it in. Scarlett finishes and merges. Only then does Violet meet Scarlett’s changes for the first time: that is the Big Bang. With two developers it is manageable. With a team of four to six, I have seen it take days to resolve the conflicts. Notice that in low-frequency integration the arrows only leave the mainline, and none come back in.
Figure 6: Low frequency integration leads to the Big Bang. Source: Martin Fowler.
With high-frequency integration, every developer keeps pulling from and pushing to the mainline. The big yellow Big Bang splits into many small ones, with arrows going both ways. Conflicts are resolved early while the code is still fresh in your head, and you face fewer problems sooner.
Figure 7: High frequency integration. Source: Martin Fowler.
Does this come without cost? No. Committing several times a day means committing code you are not ready to release. The answer is feature toggles: a toggle point in the code and a toggle router decide whether the old or the new code runs. The simplest form is a condition that returns the old or the enhanced function. Real systems are more careful than that, but the idea holds, and it is a cornerstone of engineering governance for trunk-based teams. Flagsmith is one open source tool for this.
Figure 8: Feature toggles let you commit unfinished work to the trunk safely.
This is not theory. I worked with a startup that had hundreds of long-lived branches. By adopting branch protection and pre-commit hooks, committing directly to the trunk daily and treating broken builds as the top priority, we cut the number of branches to a handful within three sprints, and merge-conflict time dropped close to zero.
There is one uncomfortable part. The DORA 2023 State of DevOps report found a surprising association between trunk-based development and higher reported burnout. That does not mean TBD causes burnout; it means the practice does not exist in isolation. My own experience was the opposite: long-lived branches and big-bang merges created the real stress. The lesson is that a practice only reduces friction when the surrounding system, meaning tooling, culture and review discipline, is mature enough to support it.
VIII. Pillar 4: Modern workflows in the AI era
This is where AI comes in, and it gets less time than the other three combined. For more than a year I played with agents, harnesses, open-weight and closed models, and I concluded that using a single model is not in the project’s interest. So I started using two in parallel: a coder and a reviewer. The coder ran in Cursor on Claude Opus and the reviewer in OpenCode on GPT Codex, deliberately two tools from two providers. They talked to each other through files, with me as the human in the loop. Later I added a third role, an auditor, to verify independently. The principle of engineering governance here is that no model should be the sole judge of its own output.
Figure 9: A coder and a reviewer from different providers, with a human governing the loop.
That setup works, but it does not scale. My screen was full of terminals, and I was copying context between them by hand. AI coding tools tend to work alone, while engineering teams do not. The result is context switching, inconsistent practices, duplicated effort and poor traceability of the decisions the models made, which hurts both governance and quality.
So I started three proofs of concept: an MCP client and server, an agent on top of that client, and several agents talking through the A2A protocol, built with Google’s ADK. Blending them led to OrchestrAI, a terminal-native orchestrator that coordinates a team of purpose-built agents (for example planning, development, code review, testing, documentation, DevOps and security agents) across the software lifecycle. It has a terminal UI with human-in-the-loop approval checkpoints, and it is designed to work with multiple LLM providers. We built it at the DevOpsDays Cairo 2026 Hackathon, presented it to the judges, and advanced to the next round. It is live on npm. I presented it as a governance case study, not a product pitch: one illustration of the pattern.
Figure 10: OrchestrAI, a terminal-native orchestrator for a team of specialized agents.
The key takeaway of this pillar is that the lesson outlives the tool. Cursor, OpenCode and the models behind them will probably be replaced within a year or less. The pattern, meaning separation of roles, independent review and human oversight, is what generalizes, whether the reviewer is another LLM or a human colleague. The pattern is old. Only the reviewer changed.
IX. Four pillars, one sustainable outcome
Put together, the four pillars produce engineering governance, governance removes avoidable friction (less rework, less firefighting, less cognitive overload), and less friction makes teams more sustainable. Sustainable engineering is ultimately about sustainable engineers.
Figure 11: From four pillars to engineering governance to more sustainable teams.
One honest caveat: good engineering governance does not automatically reduce burnout. It creates the conditions in which AI-accelerated work can be sustainable, if the surrounding culture is mature enough.
X. Key takeaways
- Define practical engineering governance boundaries for your team’s AI co-workers, whether the teammates are human or agentic.
- Balance cost, speed and quality with multi-model workflows, and do not let one model judge its own output. More models can raise quality, but they also raise cost.
- Apply SDD and TDD to catch AI-generated defects before they ship, and TBD with feature toggles to avoid the Big Bang.
- Do not try to apply everything at once: set priorities and adopt the practices in phases.
- Redefine roles for AI-enabled teams: judgment and review go up in value, not down.
AI amplifies engineering excellence, but it does not eliminate the need for it. If you have problems, AI will amplify those too. Invest in engineering excellence and engineering governance first, and AI can then boost your productivity and your team’s.
If you want to read more, start with IBM on spec-driven development, Robert C. Martin’s Clean Craftsmanship, Martin Fowler on continuous integration, Kent Beck’s Extreme Programming, the DORA State of DevOps reports and the MIT News story on Margaret Hamilton, all linked above where they come up. I share more ideas about software, cloud and architecture on this blog.
Related reading: my earlier recaps on spec-driven development with Kiro and on building a serverless web app on AWS.
