That world no longer exists.

A new class of work is emerging alongside traditional delivery: agentic development, where humans and AI work in parallel to compress timelines, reduce toil, and turn intent into working systems faster than any sprint cadence allows. This isn’t a replacement for Agile. It’s a second stream running alongside it, and most organisations have no framework for it.

The gap isn’t tools. Every team has access to Copilot, Cursor, Claude, Codex. The gap is ownership, and right now, nobody owns it. AI adoption is left to individuals figuring it out for themselves. That lifts personal productivity, but it doesn’t change how the organisation works. No one is accountable for “we as a company work differently because of AI.” It falls between engineering and leadership and ends up being nobody’s job.

The result is a patchwork. Some teams move faster. Most don’t. The gains don’t compound. A workforce of individually augmented people is not the same as a workplace that has structurally changed how work gets done.

AI builds Time. Every workflow automated, every toil task planned away by an agent, every repetitive decision encoded into a system. That is Time being built. Time created. The question is what your organisation does with it.

The Frontier Manifesto is a framework for that second stream of work. The principles for human and agentic co-work in the workplace.

Read the Frontier Manifesto →

You’re sitting with an engineer from your team, looking at something on a screen. Not a slide deck. Not a roadmap. A working system. One that solves a problem you’ve been circling for months. You built the intent. The agentic workforce built the scaffold. The engineer made it real. And somewhere in that conversation, across those few hours, something that had been sitting in the back of your mind for years stopped being theoretical.

This is the moment your Builder’s Renaissance begins.

The Shelf

Every experienced technology leader has one. A mental shelf of ideas that never made it off the whiteboard. They were not bad ideas. It’s just the effort wasn’t worth the reward.

Building a proof of concept meant pulling engineers off delivery. Writing a prototype meant re-learning a stack you hadn’t touched in years. Even a small experiment carried weeks of organisational drag: prioritisation discussions, resourcing conversations, a backlog item that aged quietly until someone eventually archived it.

So you stopped building. Not because you lost the instinct, but because the maths didn’t work. The ROI on your direct contribution didn’t justify the opportunity cost. You became, by necessity, a director of building rather than a builder yourself.

That’s not failure. That’s seniority. But it came at a cost that most leaders quietly absorb without naming it: the slow erosion of the feedback loop between idea and reality.

AI just changed the maths.

The Equation Shifted

The effort required to move an idea from intent to working system has collapsed. Not for everything. The hard problems are still hard. But the distance between “I wonder if we could…” and “here’s a prototype that proves it” is no longer measured in sprints. It’s measured in hours.

This isn’t about vibe coding as a methodology. It isn’t about leaders shipping features to production unilaterally. It’s about a feeling returning that you used to get when you were on the tools, but amplified 10x over.

Because now that the reward outweighs the effort, everything you’ve previously shelved deserves a second look. And when everything you shelve tomorrow has a shorter stay, maybe it’ll remove the friction from having to make people wait for their pet project?

Projects you deprioritised because the investment didn’t make sense. Architectural experiments you couldn’t justify resourcing. Proofs of concept that would have required three months of engineering time for a two-week hypothesis. All of it is now within reach. Not because AI replaced your engineering team, but because it compressed the cost of exploration enough to make exploration rational again.

That’s the renaissance. Not a return to writing production code. A return to building instinct.

What You Can’t Do Alone

Here’s where the challenge sits, and it needs to be said plainly:

If you’re already dabbling, at work or outside it, because the instinct to build doesn’t clock off. If you’ve been quietly spinning up agents, exploring tools, maybe even shipping something small. There’s a version of this that goes wrong. It’s the version where the leader builds alone.

You understand the strategy. You know what you want to prove. The agent is capable and fast. Why involve anyone else?

Because you are not the person who gets woken up at 2am when it breaks.

That gap isn’t a technicality. It’s the whole point. The engineers on your team carry knowledge that doesn’t live in documentation, and most of it is preventative. They design for resilience before anything ships. They know where the system is fragile, where security needs reinforcing, where a seemingly simple change creates downstream risk. The 2am call is the last resort, not the job description. The job is building systems robust enough that the call never comes.

A leader building without that knowledge isn’t demonstrating capability. They’re creating risk and calling it initiative.

The answer isn’t to stop building. It’s to stop building alone.

The Co-Working Bubble

The responsible version of the builder’s renaissance is not a solo act.

you + a skilled engineer + an agentic workforce

Impermanent by design. Formed around a specific, measurable problem with a clear outcome.

• The leader brings intent and strategic judgement. The clarity about what success looks like and why it matters.
• The engineer brings operational reality. The constraints, the failure modes, the hard-won knowledge of what production actually requires.
• The agentic workforce compresses execution. Multiple agents working in parallel, each focused, none blocked, a force multiplier across the entire build.

This isn’t delegation. The leader isn’t handing a brief to an engineer and stepping back. The engineer isn’t a safety net for an executive’s side project. Fast learning happens together, and it runs in both directions.

• The leader takes away what the system actually requires to be safe, observable, and maintainable. Constraints that never survive the journey from leadership meeting to Jira ticket.
• The engineer takes away how strategic intent shapes product decisions. Context that rarely makes it as far as the backlog.

The bubble dissolves when the work reaches production. Not when it’s “done” in the informal sense, but when it meets the engineering team’s Definition of Done: observable, tested, secure, handed over cleanly.

This is what leading by example looks like now. Not demonstrating that you can build without help. Demonstrating that you understand what help means, and why you can’t do without it.

Vibe Coding Is a Phase, Not an SDLC

There’s a useful parallel here to how teams actually work. In the 1960s, psychologist Bruce Tuckman described four stages every group moves through: Forming, Storming, Norming, and Performing. Frontier Development follows the same pattern.

Forming

Also known as the Spike, this is where the co-working bubble does the discovery work before a line of code is written. Drawing from principles in Extreme Programming (XP), the spike is a focused, time-boxed investigation to reduce uncertainty before committing to an approach. With an agentic workforce, the spike is dramatically faster and broader. Options are assessed, approaches stress-tested, unknowns eliminated. AI isn’t inventing new solutions. It’s pattern-matching across problems that have already been solved, elsewhere, by someone else. The spike narrows the field to an approach with a track record, before anyone commits to building it.

Storming

The generative build phase. The agentic workforce moves fast and in parallel, at a pace that Rapid Application Development promised but rarely delivered. Multiple agents, multiple threads, none waiting on the others. Ideas get tested. Things break and get rebuilt. The shape of the solution emerges through doing, at a pace no single engineer could match alone.

Norming

Also known as Hardening, this is where storming has to end. It’s a strategic one. This is where the system becomes real: observable, tested, secure, maintainable by people who weren’t in the room when it was built. The leader calls the transition. The engineer leads the hardening. Humans own intent, trade-offs, safety, and quality, and this is where that ownership is proved.

Performing

Also known as Definition of Done, this is where the work reaches production at or above the team’s standard. The bubble dissolves. The engineer owns it, including the 2am alert.

Your Renaissance, Responsibly

The shelf is real. The ROI calculation that filled it is real. And the shift that makes it possible to reassess it is real.

But the renaissance isn’t a solo performance. The leaders who will do this well are the ones who understand that their return to building is only valuable in combination with the people who never stopped. Who pull engineers in not as a governance step, but because they understand what operational experience actually means. Who build the co-working bubble not because process demands it, but because they know they’re better for it.

That’s not humility as a soft skill. That’s human judgment over effort as a structural advantage.

The ideas on your shelf have been waiting long enough. The effort finally fits the reward. Just don’t vibe alone.

The Frontier Manifesto Series

Taking on more and making it normal? What starts out as good intentions, without explicit guardrails slowly rises the baseline. And like rising waters, it can gradually result in individuals treading water, trying to keep up with the world they’ve created and the renewed demands to keep improving it.

Here’s an example that might sound familiar:

A co-worker leaves and everyone else around steps up and does 20% more - they are proud of their work and their company, and they don’t want either to fail. But if the backfill isn’t replaced, then 120% gets normalised, and the backfill quietly gets deprioritised if those working 120% (or advocates for them) quietly accept their fate.

Now the same pattern, but with a new variant:

The more productivity we extract from AI, the more we will want to keep extracting. It’s even more addictive at pace - finally the reward justifies the effort! But if all the Time being built, gets automatically forfeit back on the pursuit of continual improvement, then the velocity of change becomes normalised. Rate of change, is the primary reward, which is indivisible.

The Flow State

Before we get to what Developer Fatigue is, it helps to understand what gets us hooked in the first place.

“People who experience flow describe it as a state of effortless concentration so deep that they lose their sense of time, of themselves, of their problems.” — Daniel Kahneman

We used to just achieve flow state through developer vs code. We loaded up our mental context window full of the problem at hand, and the solution we are iteratively building out - but don’t you dare talk to us when we are in this state, because this mental house of cards will tumble faster than it took to build!

Now with developer + agents vs code, we can delegate sections of the build out, and at the same time we start to mentally plan the next iteration. By the time the agent finishes, you’ve already got the next changes ready. When flow state hits, it arguably hits faster. Especially the more agents you task in parallel.

Before you know it, you’re running multiple agents, working on multiple different projects, all at the same time. You are also doing your usual day job, so when you return from lunch, and all your agents are eagerly waiting to show you their latest wins, those endorphins are working on overtime.

But this increased level of flow state plus a fully engaged working memory, is a fragile state. It works when things are working, but when they don’t, and they won’t, there’s a risk of wide spread Developer Fatigue.

The Four Fatigue Vectors

Here’s four ways flow turns to fatigue:

Vector 1: The Stone Wall

Everything is working, your agents understand you perfectly. Then at some point they take a wrong turn, they start misquoting you, or you catch glimpses of it auto approving itself, saying things like “Oh, i couldn’t access that file, but that’s ok, I’ve got a pretty good idea what it said, so let’s just continue”.

I had a moment of enlightenment recently: AI kept on insisting I had said something, but I could clearly see in the conversation, it was AI that had said it as a incorrect inference of something else I had wrote. It happened a few times, and each time I challenged AI, it said, “Yes you are right” and brushed it off like it was nothing. I was getting fed up, truely fatigued with the AI gaslighting, then it dawned on me.

I asked “are you responding to me based on our conversation history, or a summary you have made of our conversation history?”.

Those that understand compression algorithms immediately recognise lossy compression - it’s jpeg-ing my conversation, not gif-ing it, and if it’s inference is wrong, it’ll stonewall the rest of your conversation until you brute force it back into submission, or come to your senses, and start a new session.

The problem with flow state? You are too much on a roll to remember AI hygiene, until it rudely brings you back to reality.

Vector 2: The Incomplete Loop

Your finishing up with work. You’ve got life to get on with. It’s time to pick up the kids, start cooking dinner, whatever your after work routine is. And maybe it’s Friday, and the weekend is beckoning?

Your agents are still running, and you haven’t quite finished exactly what you were aiming to do. In the attempt to seek closure, the last 20% of work with AI is still at risk of taking 80% of your time.

The risk is you keep chasing closure. Half your attention is on your family/friends and the other half is keeping an eye on your phone, waiting on a signal from your agents, that the last bit is done.

Vector 3: Always On

Agents have no incentive to stop - they’ll keep working, improving, iterating. There is no natural stopping point unless you impose one. You alone, are left to decide when to switch off.

Hitting AI session limits might just be the bug that’s actually a feature. If you have no limits, where is the feature going to reside?

Perhaps it’s worth engaging your own personal timekeeping agent - an agent that keeps stock of your progress, looks for the points where you should disconnect, when your productivity hits a wall. Its one, sole responsibility? To tell you when to tools down, get up and walk away.

Vector 4: Async Interruption During Sync Moments

Agents don’t understand meeting etiquette. When they ping you, it’s the type of message you want to open, bearing news of new milestones reached. But unlike messages from co-workers, if you don’t respond to your agents, they’ll be sitting around dormant until you respond. And unlike your co-workers, if you don’t respond the first time, they send you another gentle or not so gentle nudge to remind you that they are still waiting.

So in the world of video conferencing, what’s the etiquette on instructing your agents when they’ve got a question for you? What’s the harm, just giving on more quick instruction, and hoping that will be enough to hold them off until the meeting is over?

I’m not describing a personal discipline issue - if you are able to apply yourself 100% to every meeting you attend, I would like to shake your hand. For the rest of us, we need to now consider an agent-interrupt culture.

Before the Frog Boils

Here’s the part of the article where you expect me to tell you how to solve your all your problems. I can’t give you anything concrete, because we are too early in this journey - the long term studies are still years away from being thought up by a well-meaning, but poorly under-experienced undergrad student. But here’s a starting point, from lowest hanging fruit to the biggest rewards.

1. Accept It

First, accept this fatigue will be felt, if it’s not already happening - remember everyone has a life outside of work, and for some, that means switching from work agents to life agents (yes, it’s happened).

2. Ask Your Engineers

Talk about it with your engineers, especially those innovators and early adopters. These are the people that will set the new agentic normal. Ask about their coping mechanisms, and take notes. If you haven’t already, add some questions to your pulse surveys to measure team health - it’s here where warning signs can appear before your engineers can explain why.¹

3. Time Is the Reward

Here is possibly my most important advice:

Your engineers are building Time. Use Time as a reward.

“We have no Time” - how many times have we all heard this being said? How many times do we say it ourselves? One of the first rewards for building Time for all, is getting some of this Time back - turning Time defect, into Time surplus.

Instead of teams racing from one win to the next, a Time surplus can be used to think slower, workshop new ideas, think outside the box. When you slow Time down, the reinvestment might be the seed for something much bigger.

But what if we didn’t stop at individual Time? What if the organisation redesigned itself around it?

4. Skeleton 9-5

What if we go even further? Let’s say, you’ve successfully put Frontier Development in action - small teams are managing the judgement of an agentic workforce building Time. Those agents will keep working when humans don’t.

Human judgement itself becomes the bottleneck, and the increasing number of parallel projects, will one by one, find the limits of all.

So should those humans just be present to plan future agentic iterations, apply judgement to their agentic output, contribute to important ceremonies, respond to messages and on call for unexpected issues?

What else remains, but a skeleton 9-5? Time that is yours to spend as you see fit? What would you do with that time, if the answer was not limited to the traditional working environment? Read that book, go for a walk, have a coffee with friends, pick up a side hustle, get more sleep?

Closing

So how do engineers and leaders alike feel about the concepts in this article? Being present in an asynchronous agentic world, is not any reducing Time, rather redefining what it means.

Put simply: Time built, is a reward and the spoils should be distributed fairly. Who’s accountable for ensuring this decision being made? The Engineering leader is.

As we embrace the agentic workforce, retaining the human judgement that learns how to orchestrate it, becomes even more important. So as we take on more, let’s shape the new normal, before it shapes us.

Agile delivery teams are incorporating AI across their SDLCs, and it’s exciting to see the innovations emerging: agentic assessment of delivery plans against the target state architecture, high fidelity wireframes turning from design into code, user stories feeding to agents which analyse and produce code for review, test coverage increasing its reach, and incidents being triaged and reported to stakeholders without needing to interrupt those actually fixing the problem. Proving the actual productivity uplift turns out to be difficult on large scale projects, when the Time gained is quietly absorbed back into the project.

So what comes next?

I see small silos starting to form, with a lot of the same problems being solved. Within the Engineering space, teams owning their own maintenance strategies help to shape the intent — but the next phase of AI needs organisations to assess current ways of working, and turn this phase of individual uplift into organisational capability.

Governance plays a key role here. It ensures transparency, minimises risks, names accountability, sets technical controls, and empowers end-users with the right responsibilities to safely employ an agentic workforce. Frameworks exist — NIST, ISO, the EU AI Act — but they are compliance-oriented or not agentic-specific.

In January 2026, Singapore’s Infocomm Media Development Authority (IMDA) released the world’s first dedicated governance model for agentic AI: the Model AI Governance Framework for Agentic AI (MGF) — distinct from those broader frameworks in that it’s voluntary and built specifically around agentic systems, which maps to practice rather than compliance. It’s a living document, inviting case studies and feedback to help it stay current.

The MGF provides organisations with practical guidance, rather than a checklist. It covers both technical and non-technical measures needed to deploy agents responsibly, across four dimensions:

1. Assessing and bounding risks upfront.
2. Making humans meaningfully accountable.
3. Implementing technical controls and processes.
4. Enabling end-user responsibility.

This article describes how the Frontier Manifesto — specifically as implemented by Frontier Development — addresses each of these dimensions, starting with: what are you actually building, and what could go wrong before you begin?

Dimension 1: Assessing and bounding risks upfront

The MGF’s first dimension asks organisations to understand what they’re building and what could go wrong — before a single agent runs. In Frontier Development, this maps to three upfront decisions: the domain and use case you’re operating in; the reversibility of what your agents will actually do; and how you think about sensitive data access, cost, and intent clarity.

Domain and use case

Before we assess Frontier Development, it’s first important to understand where it sits in relation to AI-augmented Agile and the fully autonomous AI Organisations.

1. Agile

For larger projects where there’s a lot more human judgment in the loop, and a lot more people to bring in to answer it. AI augments the engineer and other contributors to the SDLC.

2. AI Organisations

For repeatable work that more runs the business than changes the business. AI Organisations are virtual org charts that describe agents by their job descriptions, as well as strict instructions as to who communicates with whom. Work requests enter via an agreed entry point, such as the Agentic PM. Humans review outputs at key milestones. There is a limited number of active parallel requests, so as to reduce the risk of waste being produced.¹

3. Frontier Development

For things we chose not to do because the cost of doing the work wasn’t worth the reward.

To spin up an entire team — all those people — just to focus on a very short, scoped problem is very costly: it’s an expensive context switch for that entire group.

Frontier Development uses AI to help build the software to solve the problem — it’s not solving the problem itself. It’s about the tools that you build with AI.

Reversibility of agent’s actions

Vibe coding — especially solo workers without any other human governance — leads to changes that are difficult, and sometimes impossible, to reverse. You shouldn’t vibe code into production. That’s what Frontier Development prevents.

Frontier Development utilises the Tuckman forming, storming, norming and performing phases. In the forming and storming phases, there’s a lot of agentic coding with minimal guardrails, because nothing is making it into production — there’s nothing to reverse. When the engineers get to the norming phase, the table flips: now agentic coding is being used to harden the code. 100% test coverage, code quality, security reviews, observability (MELT), monitoring and alerting are all built up, layer on layer. This means that when you’re ready to productionise, you can also use agents to ensure your organisation’s standard approaches to rolling back — feature flags, canary releases, and so on — are also just another checkbox in your agentic execution plan.

It’s worth clarifying a point: an A/B test is not production. As long as the test is well founded, you should be able to vibe code a proof of value. Better still, it enables you to statistically prove a change is valuable before committing the time and resources to making it production-ready. When tests prove effective, Frontier Development hardens it before permanent deployment.

Reversibility is a good test. If you can’t undo it cleanly, AI likely has too much control over production.

Sensitive data, cost, and intent clarity

Three questions worth answering before the first agent runs: what data does it touch; what is the estimated build cost vs benefits; and does the intent match the expected ROI?

Sensitive Data

In Frontier Development, the agent’s access to data is limited to the discovery and execution phases — i.e. building systems. There may be a need to build AI inference into a production workflow, but the core purpose of Frontier Development is to use AI to solve problems faster with 100% predictable automations, not to use AI in the automation itself. In short: if an Engineer didn’t need PII to develop a feature, neither does your AI.

Cost

If you’re estimating and measuring the Time returned from an initiative, you’ll need to understand how much the initiative will cost in the first place. Candidates for Agile deal with a lot of unknowns that get clearer the longer the project runs. Candidates for Frontier Development should be more discrete in their changes, and have more clarity from the beginning — clarity that can’t justify committing a full Agile team to the solution.

In comparison, Frontier Development — which may attract higher agentic cost — is still likely far lower in total running cost, and it’s much easier to pull the plug if the problem turns out to be more complex than first assessed. This is fundamental for deciding which development framework to use in the first place. AI can now justify work that was previously shelved due to low ROI, but it doesn’t justify everything imaginable.²

Intent Clarity

Pet projects are not a reason to do something. Whatever agents build, humans must own — so the ROI matters not just as immediate reward, but as ongoing return vs maintenance. There are many ways to solve a problem, and agents will find many ways. It’s up to humans to set the intent and judge the ways agents intend to solve it.

Agents leverage the knowledge of the world, but they still think inside a (very large) box, so the way they connect that knowledge together can fall short of innovation or creativity. AI can still design wasteful processes, because it doesn’t experience incidents like we do. Humans are still responsible for critiquing AI’s inferences — for “thinking outside of AI’s inference box”: “you’ve suggested X and Y — does Z make sense here?” or “this doesn’t seem to be working, how about we look at it this other way?”

Knowing what could go wrong is only half the equation. The other half is knowing exactly which human is accountable when it does.

Dimension 2: Making humans meaningfully accountable

The MGF’s second dimension is about making sure which humans are accountable for the actions of the agents. In Frontier Development, this means being clear on who owns the decisions, and structuring the work so that human judgment sits at every significant checkpoint — rather than focusing on the wins.

Key decision makers

Humans own intent, trade-offs, safety, and quality.

Time is the primary metric for Frontier Development. But it’s important to focus on the right units of Time. Time is not focused on how quickly the problem was solved — although it will be difficult to ignore as the wins are made. The reason this isn’t the focus is because it would prioritise a productivity capitalism, where the human/AI portfolio of “wins made” is expected to grow year on year, above and beyond human limits. KPIs based on speed to market would be ratcheted up year on year, as would the new expected baseline — as well as the reported cases of burnout.

The way to measure is as Time built. Something that is given back to people. The two Time metrics are:

1. Time returned to humans that no longer have to do the manual work.
2. Time returned to customers that didn’t waste their time trying to do something that didn’t work.

Significant checkpoints

Frontier Development’s use of Tuckman’s forming, storming, norming and performing phases creates significant checkpoints — between the phase transitions, and within the iteration cycles of the phases themselves. The humans responsible, accountable, consulted and informed (RACI) aren’t just assessing the output of the AI alone — they’re assessing the output of the bubble.

The bubble’s tangible progress at its checkpoints is what decides whether the investment continues or not. Other, less tangible Agile measurements — like velocity or story points — should be avoided, because they don’t tell you how much closer you are to your goal. Token consumption, an equally common brag-and-concern in the agentic world, also fails to answer this same question.

Part of the forming phase is coming up with the execution plan — with the help of the AI, the engineers work out what they’re actually going to build with the agents.

That means breaking that down into phases, and then breaking those phases down into steps — like you would epic to stories to tasks. The difference is that this can be written and tracked in a single, living document in your repo, rather than broken apart, assigned owners, and tracked individually.

As the agent workforce executes this plan in the storming phase, the skilled engineer reviews that the output matches the intent, and can discuss with the engineering lead if the plan might need adjusting.

As a result, there may be many significant checkpoints within a single day — far too many to adorn with tickets, retros and backlog grooming.

Human checkpoints define when to stop. Technical controls define what the agent can do in between.

Dimension 3: Implementing technical controls and processes

The MGF’s third dimension covers the technical controls and processes that govern how agents operate. In Frontier Development, this means building controls progressively as you move through environments, knowing when to intervene on cost and time, and using the Tuckman iteration loop to structure the collaboration between humans and agents from start to finish.

Progressive controls

Agentic access follows two directions, depending on where you are. In a least-privileged model, controls start narrow and expand only as needed. In heuristic development, where the goal is a fast POC, access starts broad enough to move quickly, then gets pared back progressively as the initiative moves toward production.

Least Privileged model

Agents are usually sandboxed to limit their reach. In new projects, time can be spent re-granting access to agents to perform rudimentary tasks, so engineers will seek to auto-approve these flows. To speed up an engineering team, there’s usually a desire to centralise these policies. Governance should be accountable for implementing these policies, so that well-meaning developers don’t accidentally roll out unsanctioned access.

Well-meaning agents are also constantly seeking ways to expand their own sandbox — such as requesting access to open source libraries. There’s a real, heightened risk of cascading supply chain attacks when there are no hard controls external to the AI, such as sanctioned libraries and minimum version ages. If your agents have no org-level rules for which dependencies they should use, they’re guided only by trained knowledge, or by a curious engineer who digs a little deeper. Unless you explicitly tell the AI to deep-research their requirements, their third-party “security track record” might be a year out of date — depending on which model you’re using.

Below is a tabled output from a prompt to Claude Sonnet 4.6 on 10 June 2026:

The prompt that produced this table is reproduced in full below.³

Heuristic Development

If you’re developing heuristically — learning fast and proving out the concept ahead of further investment into execution and hardening — progress is faster by giving a lot of access to AI within lesser, lower environments. For example:

You might grant full API credentials in a lower environment, and let the agent prove out the API calls it needs to solve the problem. At this point, you ask the agent to audit its own access, and pare it back to least-privileged access before progressing to the higher environment.

It’s essential for the human in the loop not to forget to tighten up these controls — both in the lower and higher environments — as an AI with the keys to the kingdom likes to plan how it will use them.⁴

Cost limits and human intervention

Sunk cost fallacy applies to agents as it does to humans, so the engineer governing an agentic workforce can’t let it run indefinitely — an agent with the wrong task can easily waste time trying to solve the wrong problem. If the task at hand is taking longer than it should reasonably take, that’s when the human should be stepping in to inspect a little closer — easier said than done if you’re AFK, or dispatching one more command before you log off for the night. Be wary of the tasks you set agents before you walk away — and consider break paths in your prompts or skills, based on previously observed behaviours, that can detect these patterns as they form.

A concrete example of my own break paths: my agents would frequently proceed on their best reconstruction of what they thought the source of truth would say. So:

“If you ever attempt to read a file from an MCP server and fail, or retrieve a truncated copy, do not proceed on your own memory of the file. Stop immediately and advise me, and I’ll provide the next course of action.”

Likewise, if the problem turns out more complex than initially supposed, the humans controlling the agents should recognise sunk cost fallacy before it eats too much time, with little to show for it.

Global spend limits should always be in place — but within the Frontier Development bubble, cost shouldn’t be a limiting factor. If the intent is clear, then the Time built should easily justify the cost to build it.

Processes and change management

The Frontier Development process runs on Tuckman’s phases — forming, storming, norming, performing. Each phase requires the two engineers to collaborate on the agentic output, and each phase transition requires a human checkpoint from outside the bubble.

So it focuses on iterations and hand-offs: human to human; human to AI; AI to code; code to human. It encourages gradual deployment through execution planning (forming), and continued monitoring through hardening (norming). The generative build phase in the middle has fewer guardrails, because it’s both preceded and followed by human judgement.

When you get to the performing phase, you should be able to review the effort vs reward. This effort isn’t the token spend, but the human time — and it should either be justifiable that the project was worth the time, or you learn why it wasn’t and adjust for future projects.

Technical controls protect the system. The fourth dimension asks a harder question: are the people using it actually equipped to make good judgments with it?

Dimension 4: Enabling end-user responsibility

The MGF’s fourth dimension asks whether the people working with agents are actually equipped to do so responsibly. In Frontier Development, this is built into the structure of the co-working bubble itself — through shared experience, the pairing of judgment levels, and a secondment model that shapes the next generation of engineering leaders.

Foundational knowledge

Agentic literacy isn’t something you learn from a course — at least not while the target keeps moving. We keep getting reminded that most of what we learn is on the job, not in a classroom. Frontier Development gives you that 70–90% through shared experience, good and bad — which is also good for relationship building — in an environment where individuals are free to experiment without too much scaffolding.

Education of users on agentic behaviour is often trial and error. In a healthy working environment, experiences both good and bad should be shared between engineers and between bubbles. This technology is rapidly evolving, occasionally devolving, and often over-promising — there’s little time to mature before everything shifts again. So, as with a moving target, it’s best to aim slightly ahead.

Look for emerging patterns of problems. If the technology isn’t quite ready, don’t force it — learn when to back out, but don’t forget to try again in the not-too-distant future. It’s also a great time to bring out all those ideas you’ve previously shelved. Engineers are often pushed down the MVP route due to budget constraints. But now a mediocre CX can be made exemplary — and that includes tools for internal staff!

If you try to overprescribe exactly the way you’re meant to interact with the agents, you end up getting the same outcome from everybody. You need to create a safe place for individuals to play without too much prompting. If ideas can be nourished, and made a (safe) reality with frameworks like the Frontier Manifesto, then perhaps that’s where the unicorn comes from — a collaboration of ideas, rather than the brilliance of one.

Effective oversight

Effective oversight relies on the existing judgment skills of the engineer. This is the main purpose of pairing an engineering leader with a skilled engineer.

The engineering leader brings in more strategic judgement. They’re seeing the forest, not the trees — but they’re also looking much further down the road. In this world, it’s easy to get out of touch with “what actually happens” at the root level, so the engineering leader gets a fresher take on what day-to-day actually requires.

The skilled engineer understands the Definition of Done, and understands the standards that they and their peers expect when they open a Pull Request. They know which library to pick, the right infrastructure, the right way to scaffold and set up CI pipelines. But they’re often far down the road from where the original “why” was set, and far away from the decision to pivot to something “more important.”

The pairing isn’t just about catching mistakes. It’s seeing the forest and the trees at the same time — the human talent for pattern recognition when the data set is too small to automate it. It also helps protect tradecraft and train tomorrow’s leaders.

Tradecraft and business continuity

The tradecraft concern in MGF is about entry-level jobs potentially being replaced by AI. While I won’t address other disciplines, Frontier Development addresses this for entry-level Engineering — and after all, isn’t this the discipline we’re constantly reminded is most at risk? Junior engineers are important for bringing fresh thinking into an organisation.

As highlighted in the previous section, when junior engineers are included in the co-working bubbles — in these short, bounded engagements — they get to benefit from working with an experienced engineering leader, albeit for a short and productive period of time. When those junior engineers go back to their delivery teams, they return with newly acquired skills, and are able to slowly transfer that learning into their own team. It doesn’t just prevent deskilling — it starts to shape tomorrow’s engineering leaders.

In my own career, I’ve found it vital not just to learn my own craft, but to be curious and educate myself about all aspects of business administration and operations. In these engineering bubbles, individuals are also working with various stakeholders who have skin in the game and want to see the outcome come to life — so they’re also learning about various aspects of the business, and what’s important to each of these areas.

Frontier Engineers are actually upskilling themselves from a business administration and operational perspective. This type of learning is hard-earned in an Agile team — rather, it’s down to the luck of the initiative, and how long that initiative runs for.

In an agentic world, generalists are at a clear advantage — they know a little about a lot of things, and if they combine that with an agentic workforce that can fill in the known gaps, they can achieve something far more significant. Consider specialists: to remain relevant, they’re in dire need of generalising — expanding their toolkit into adjacent areas, and leveraging AI to learn fast.

Upskilling is not the answer — it’s cross-skilling! The Frontier Manifesto deliberately supports this through real work, and this is how the next generation of engineering leaders will be built.

Closing

The MGF asks organisations to think about governance as something they build in, not bolt on. Frontier Development’s answer is structural: governance is embedded within bounded scope, progressive controls, human checkpoints at every phase transition, and a co-working model that shapes the engineers doing the work.

Frontier Development doesn’t come with the overhead of Agile — less ceremony, more checkpoints — a better fit for an agentic workforce, focused on healthy outcomes, while protecting the futures of the humans who embrace it.