Series Navigation:
This is Part 2 of a 5-part series on Agentic AI Architecture.
- Part 1: Communication and AI
- Part 2: AI-First Delivery Model (you are here)
- Part 3: Inside an AI-First Pod
- Part 4: Architecture Roles
- Part 5: Talent & Culture
Two weeks.
That is how long the backend team had been preparing for this architecture review. Two weeks of diagrams, modelling sessions, refinement meetings, Jira slicing and cross-team alignment. They were proud of the work. They should have been. It was good.
The room settles as they walk through the design for the new workflow engine.
People take notes. Heads nod. Someone asks a question about resilience. Someone else about data retention.
Then, from the back of the room, someone clears their throat.
“We built a version of this yesterday… took about forty minutes with the AI.”
A few people smile, assuming it is a joke.
It isn’t.
They plug in their laptop.
A running prototype appears on screen.
Working endpoints. Real flows. Full test coverage. Documentation. Observability hooks. Everything.
Built by one engineer and an AI agent.
In less than an hour.
The room goes quiet.
The kind of quiet you only hear when people realise the world just tilted.
It is not that the backend team did anything wrong. They worked hard. They followed the process. They did what good teams do.
But the ground under them shifted.
AI changed the pace of what is possible, and the process stayed the same.
This is the new reality.
AI is no longer a convenience tool. It is a force multiplier that rewrites the delivery model. The organisations that win are not the ones who draw the best diagrams, but the ones who direct intelligent systems to produce the work.
The old world was built on doers.
The new world belongs to directors, people who design, orchestrate and prompt intelligent systems.
And this matters whether your team uses AI or not.
AI-first teams are setting a new speed limit.
Traditional teams are still driving on last decade’s roads.
The comparison is inevitable.
The gap only gets wider.
And every team is now measured against what AI makes possible.
This is not just about teams using AI. This is about every team. The comparison alone changes expectations. Your work will be judged against what is possible with AI, whether you use it or not.
Why teams without AI are already under pressure
Teams that do not use AI are not just slower. They are structured around manual execution. That means:
- Work items are sliced to fit human throughput
- Reviews and approvals are paced for human output
- Design decisions are slower because the cost of exploring options is high
- Coding is the bottleneck, so waiting a day for another team is considered acceptable
- Hiring strategies assume junior and mid-level developers handle the bulk of execution
This model collapses the moment another team introduces AI as the primary executor of work.
Suddenly:
- One engineer can generate more output in a day than a team of six
- Design exploration takes minutes, not afternoons
- Documentation and test suites appear instantly instead of slowly
- Entire features move from idea to production before lunch
You do not need to adopt AI for this to affect you. The comparison alone will change how your work is judged. Your stakeholders will see competitors shipping faster. Your board will ask why your costs per feature are higher. Your customers will notice slower delivery.
“Not using AI yet” is not a neutral choice. It is an organisational risk. Every week you delay, the gap widens. Teams using AI are learning, improving and accelerating. Teams without AI are standing still while the world moves faster around them.
We are in the AI-directed era
A few realities define the new landscape:
- AI can already write code better than a junior developer
- Entry-level programming roles are disappearing
- AI is the first programming language written in English
- Industries that route or process information will collapse unless they adopt AI
- Your prompt library becomes intellectual property
- Your ability to direct systems becomes more important than your ability to produce work
And the unforgiving truth:
Being good used to be safe.
In this era, being average is the bigger risk.
Whether your team uses AI or not, this shift applies to you.
What AI-first delivery actually means
As we established in Part 1 – Agentic AI: Changing Development, but Only if You Learn How To Communicate With It, communication is your job, not the AI’s. You must be clear, precise and context-rich in how you express requirements and constraints. AI-first delivery builds on that foundation. It is not just about using AI tools, but restructuring how work flows so that AI can actually deliver on its promise.
The core principle: compress the decision-making boundary to match the speed of AI execution.
In practice, this means creating teams — call them pods — that contain every role needed to take an idea from concept to production. No external dependencies for core capabilities. No handoffs to other teams for authentication, data access, testing or deployment.
A pod includes:
- Someone who understands the domain and can articulate what needs to be built
- Someone who can define the technical approach and constraints
- People who can work with AI to generate, review and refine code
- Someone who understands risk and can define test strategy
- Access to deployment pipelines without requiring another team’s approval
Most critically, a pod has the authority to make decisions within defined guardrails. They do not need permission to choose a database or pick an API pattern or deploy to production. The guardrails are pre-defined; inside those boundaries, the pod moves at the speed of thought.
Pods are what the second team in that opening story had, even if they did not call it that.
A tale of two approaches: same requirement, different structures
The requirement is simple on paper: customers need to pause their subscription for up to ninety days and have it auto-resume with all settings intact.
Two teams attempt the same thing. Their outcomes could not be more different.
Traditional squad (eight people, dependencies on platform, infra and data teams)
Most “agile” squads have experimented with AI tools such as Claude, Copilot and ChatGPT.
And most walk away frustrated. Not because the AI lacks capability, but because the team structure suffocates every bit of acceleration the AI creates.
Here is what it really looks like.
A developer uses AI to generate a new background worker.
It includes retries, monitoring, alerting, error handling and logging.
The AI produces it in twenty minutes. Clean. Tested. Ready.
But the worker cannot run until multiple other teams do their part:
- A new Kubernetes namespace
- A firewall rule
- Updated secrets
- A revised S3 bucket policy
- A platform capacity review
- A security exemption for a dependency the AI chose
- Operations approval for rollout
None of this sits within the squad’s ownership.
So the “twenty-minute” worker enters the organisation’s actual delivery pipeline:
Networking requests queue for days.
Platform are already over capacity.
Security raises questions and insists on a meeting.
Operations review changes twice a week and miss this one by an hour.
The developer can regenerate code instantly with AI.
Every dependency moves at human speed, with its own backlog, review cycles and timetable.
By the time the worker reaches staging and production, two weeks have passed.
The AI saved hours of typing.
The organisation added days of waiting.
AI can write code in minutes.
It cannot navigate your platform boundaries, your infrastructure queues or your approval gates.
This is why adding AI to a traditional structure produces marginal gains, not transformation.
And as we saw earlier, teams that do not use AI face all the same bottlenecks without any of the acceleration. The friction is shared, but the gap in outcomes becomes enormous.
AI-first pod (four people, no external dependencies)
The product lead posts the requirement at 9:00 on Monday.
The solution architect reads it, thinks for sixty seconds, then opens Claude.
Not because they are lazy.
Because spending three hours drawing a state machine manually when AI can draft it in three minutes is waste.
The question is not “should we use AI?”
The question is “how fast can we verify this is right?”
That mindset shift changes everything.
Day 1 (Monday morning)
9:00 — Product lead and solution architect review the requirement.
The architect gives the AI agent a fully contextualised prompt, instructing it to behave as a senior solution architect.
The AI generates a complete solution design: requirements, NFRs, application diagrams, data flows and data models.
9:15 — The team reviews the design together.
They correct assumptions, fill gaps and adjust logic.
They feed refinements back into the AI and iterate until the design is sound.
9:30 — They ask the AI for a detailed build plan.
It references the NFRs, organisational guardrails, cloud, security and data governance standards, and the definition of done.
The AI produces structured increments, dependencies and acceptance criteria.
9:40 — The team reviews, tweaks, sequences and finalises the plan.
9:50 — They hand off to the AI coding agent.
It has everything it needs: context, a clear design and a step-by-step plan.
The engineer monitors generation and reviews output.
10:30 — Implementation complete.
Engineer runs the full test suite locally.
Green across the board. Commit.
10:45 — Automated pipeline deploys to staging.
Integration tests run against the billing service (owned by the same pod).
One test fails, an edge case in billing logic.
11:00 — Quick fix, regenerate, commit.
Pipeline re-runs. All green.
11:15 — The team verifies the feature in staging.
Product lead checks behaviour.
Quality strategist checks observability.
Architect validates non-functionals.
11:30 — Approved. Deploy to production.
11:45 — Feature live.
Monitoring is clean.
AI generates documentation from the code and test suite.
Total time: under three hours.
Design done. Build done. Tested. Documented. Shipped before lunch.
When it does not work (and it will not, at first)
The first time this pod tried AI-first delivery, it was a disaster.
They gave the AI a massive prompt describing the entire feature. The AI generated 2,500 lines of code. It looked good. It passed basic tests. They deployed to staging.
It crashed immediately. The domain model was wrong. The state machine had a logical flaw. The error handling was nonsensical.
They spent two days debugging before throwing it away and starting over.
Lesson learned: AI accelerates execution, but if you are executing the wrong thing, you just fail faster.
They changed how they worked:
- First, they used AI to model the solution in small loops, not as a giant one-shot prompt. That meant solution design documents with clear requirements, NFRs, diagrams, data flows and data models, reviewed and refined with the team.
- Then they turned that design into a concrete build plan with increments, dependencies, coding standards, NFRs, testing requirements and definition of done baked in.
- Only then did they let the AI coding agent generate the implementation, in small slices, verifying each step as they went.
They still ship in hours instead of weeks. But they had to learn how to think before building.
KEY TAKEAWAY
AI does not remove the need for thinking. It removes the need for typing. If you skip the thinking, you will just build the wrong thing very quickly.
Why the pod was 20x faster
It was not because they were better at using AI. Both teams used AI to generate code and tests. The pod was faster because:
- No context handoffs — The same four people stayed with the work from start to finish. The AI always had full context because the humans providing that context did not change.
- No approval gates — The pod had authority to decide how to implement within their guardrails. They did not need permission from a platform team, data team or architecture review board.
- No waiting — When a decision was needed, the decision-maker was in the room or in the Slack channel. Questions were answered in minutes, not days.
- Integrated ownership — Because the pod owned both the subscription service and billing service, they could evolve both together. No cross-team coordination required.
- Tight feedback loops — From prompt to code to test to deploy was measured in minutes. Problems were caught immediately, while context was still fresh.
- Humans focus on the top 8 per cent — Where judgement matters most. AI handles the remaining 92 per cent.
The AI was the same. The difference was the structure around the AI.
The structure wins.
The AI amplifies the structure.
Teams without AI cannot compete.
Teams with AI but with the wrong structure barely improve.
Teams with the right structure and AI redefine delivery speed.
What pods are not
Before going further, let us clear up some confusion.
Pods are not just rebranded squads. Most agile squads still depend on other teams for critical capabilities. A squad might own the user-facing service but depend on platform teams for authentication, data teams for schemas and ops teams for deployment. A pod owns everything needed to deliver end-to-end.
Pods are not autonomous teams with no oversight. Pods operate within guardrails set by higher-level architects and platform teams. They are not free to do whatever they want. But within those guardrails, they have authority to act without asking permission.
Pods are not a way to avoid governance. Good pod structures actually increase governance effectiveness. Instead of reviewing every decision, which slows everything down, governance defines the rules as policy-as-code, and pods operate within those rules. Compliance becomes automated and continuous rather than manual and intermittent.
Pods are not replacing specialists. Pods still need expertise in product, architecture, engineering and quality. The difference is those specialists work together on the same thing, not in sequence on different things. Specialists become directors who guide intelligent systems rather than doing all the work manually.
Pods are not manual delivery. Pods build the machine that delivers the work.
The prerequisite: actual agility
Here is the uncomfortable truth that needs stating clearly: AI-first delivery will fail in organisations that are not actually agile.
This will annoy people who think their company is agile because they have sprint ceremonies and user stories. But consider these diagnostic questions:
- How often do you deploy to production? If the answer is “every two weeks” or “monthly” or anything slower than daily, you are not agile. You are waterfall with stand-ups.
- How many teams need to coordinate to ship a typical feature? If the answer is more than one, your “cross-functional teams” are not cross-functional. They are siloed teams doing handoffs faster than before.
- How long from commit to production? If the answer is more than thirty minutes, your deployment pipeline is a bottleneck that will choke AI-accelerated development.
- Can teams deploy without approval gates? If developers cannot deploy to production without a CAB meeting or manual sign-off from another team, you have centralised control in a way that prevents pods from existing.
- Is your architecture coupled or modular? If changing one service requires coordinated changes to five others, your architecture will prevent pods from working independently, no matter how you structure the teams.
Organisations that embraced continuous delivery, truly cross-functional teams and DevOps culture before AI arrived will adopt AI-first delivery smoothly. They already have the muscle memory for rapid iteration, short feedback loops and distributed decision-making.
Organisations still doing quarterly planning, monthly releases and sequential handoffs will struggle. AI will not fix these problems. It will make them more expensive because you will have fast code generation blocked by slow organisational process. The worst of both worlds.
Teams that do not use AI struggle with all of this.
Teams that do use AI struggle too unless their structure matches the speed of the tool.
AI will not fix structural issues.
It will expose them brutally.
The AI-first delivery loop
Working in a pod with AI follows a rhythm that is faster and tighter than traditional agile:
- Think — Understand the outcome, constraints and risks. This is humans talking to humans, clarifying intent. Time: minutes to hours, depending on complexity.
- Express — Articulate the domain model, constraints and intent as structured prompts. This is humans translating their understanding into language the AI can work with. Time: minutes.
- Generate — AI produces code, tests, diagrams and documentation. This is where AI shines: rapid generation of artefacts that would take humans hours or days. Time: seconds to minutes.
- Verify — Humans review AI output for correctness, completeness and alignment with intent. This is not just running tests; it is applying judgement about whether this solves the right problem in the right way. Time: minutes to hours.
- Iterate — Based on verification, refine the prompt, add constraints or adjust the approach. Then regenerate. Repeat until satisfied. Time: multiple cycles, each taking minutes.
This loop runs continuously, with cycle times measured in minutes to hours, not days to weeks. A user story that would take a traditional team five days might run through this loop dozens of times in a single day, with each iteration generating working, tested code.
Teams without AI follow the same conceptual loop but:
- Thinking takes longer
- Articulation takes longer
- Generating takes hours or days
- Verifying takes longer
- Iteration is slower because feedback is slower
AI compresses every part of the loop.
Teams without AI operate with human speed limits.
The key is keeping each iteration small. Letting AI generate a massive feature in one shot is like letting a human team work in isolation for two weeks without a demo. By the time you discover they misunderstood something, there is too much to undo.
Thirty-minute increments work well. Generate enough to verify the approach is correct, then extend. This matches the cognitive limit of how much context humans can hold while reviewing AI output effectively.
The communication shift
Part 1 emphasised that communication is your job, not the AI’s. In pod-based delivery, this becomes even more critical because the pod is communicating with AI continuously throughout the day.
The solution architect is not drawing diagrams in isolation. They are working with AI to explore options, model domains and validate constraints in real-time dialogue. They are also communicating continuously with the product lead, clarifying business rules, and with engineers, validating technical approaches.
The product lead is not writing user stories for humans to implement later. They are expressing intent and acceptance criteria as prompts that immediately produce working prototypes to evaluate. They are also staying in sync with engineers during implementation, answering questions about edge cases, validating that the implementation matches business intent and catching misunderstandings early.
The engineers are not primarily coding. They are instructing AI to code, reviewing the output and refining the instructions. They are conducting code reviews on a very productive but occasionally confused colleague who happens to work at millisecond timescales. They are also communicating with the product lead on requirements and the solution architect on patterns throughout implementation, not just at handoff points.
The quality strategist is not hand-writing every test case. They are defining risk profiles and test strategies that AI translates into comprehensive test suites.
All of this requires clear, precise, context-rich communication. Vague prompts produce vague results. Ambiguous requirements produce ambiguous implementations. The old saying “garbage in, garbage out” applies even more when the processor can generate thousands of lines of garbage in seconds.
For non-AI teams, the cost of poor communication is slower work.
For AI teams, the cost is multiplied output that is wrong or confused.
Clear communication now determines delivery speed.
Poor communication is now catastrophic.
Teams that communicated poorly before AI will communicate catastrophically with AI. Teams that communicated well will find AI amplifies their effectiveness.
Why this will feel uncomfortable
Pods represent a fundamental shift in how organisations are structured. That shift will create friction.
For managers: You are used to managing larger teams. A pod is four to six people. You will manage multiple pods instead of one large team. This requires different skills, setting context and guardrails rather than coordinating daily execution.
For architects: You are used to reviewing and approving designs. Pods will make architectural decisions within their boundaries without asking. You will shift from gatekeeper to guardrail-setter. This requires trusting people more and controlling decisions less.
For specialists: You are used to being the expert that multiple teams depend on. Pods will have broader, if shallower, capability. You will either join a pod or work at a higher level setting standards. Your role as the person who does the work will diminish; your role as the person who defines how work should be done will grow.
For everyone: You are used to work taking weeks. Pods will ship in days or hours. This compresses feedback loops. You will see mistakes faster, which feels uncomfortable until you realise it means fixing them faster too.
None of this is easy. Organisational change never is. But the alternative is watching competitors who embrace these changes pull further ahead while your traditional team structure keeps you slow.
What to do Monday morning
Do not try to transform everything at once. Start small.
Experiment. Take your next user story. Before anyone writes code, try this:
- Have the product owner, architect and a developer sit together for thirty minutes.
- Use AI to model the domain and generate an initial implementation.
- Review what it produced. Where did it misunderstand? What context was missing?
- Refine the prompt and regenerate.
- Measure: how long did this take versus writing it manually? Was the quality comparable?
This will not give you a pod, but it will give you a sense of what is possible when you compress the feedback loop.
Identify. Look at your last three features. Map out the handoffs. How many times did work move between people or teams? How much wait time was there? What would have to change to eliminate those handoffs?
You do not need to eliminate them yet. Just identify them. Make the bottleneck visible.
Ask. In your next planning or retrospective, ask:
“If we could deliver in one day instead of two weeks, what would have to be different?”
List the barriers. Some will be technical, such as deployment process and architecture coupling. Some will be organisational, such as approval gates and dependencies on other teams. Some will be cultural, such as trust, authority and fear of failure.
That list is your transformation backlog.
The shift to AI-first delivery is not optional. Competitors are already making it. The question is not whether to change, but how fast you can change without breaking things.
Pods are the organisational structure that lets AI deliver on its promise. Not the only structure, perhaps, but the one that is emerging as effective across multiple contexts.
Pods sound good in theory. But what actually happens inside one?
Who does what? How do four people collaborate with AI to ship what used to take twelve people weeks?
And most importantly: what happens when things go wrong?
The next article takes you inside a pod’s workday, showing exactly how this works in practice, including the failures.