Context & Motivation
Aiske.ai has built an AI-augmented SDLC framework that applies Claude Code, multi-agent review, and Atlassian integration to our existing engineering process. This framework makes traditional teams significantly faster — but the fundamental team structure remains unchanged: product owners write tickets, developers implement, QA validates, and code review is a separate gate.
The question Fabien raises is whether we should also design a blank-slate, AI-native structure — one built from first principles for a world where AI is the primary development engine, not an accelerator bolted onto human workflows.
The core shift: In the traditional model, humans write code and AI assists. In the AI-native model, AI writes code and humans direct, validate, and own accountability. This inverts the ratio — from 80% human / 20% AI to 20% human / 80% AI — and the org structure must reflect that.
Traditional vs AI-Native Structure
Traditional Team (5-7 people)
- Product Owner writes user stories
- Architect designs solutions
- 2-3 Developers implement
- QA validates and regression tests
- Scrum Master coordinates
- 2-week sprint cadence
- Jira board with 40-60 tickets
- Peer code review required
- Handoffs between roles at each stage
AI-Native Pod (1-2 people)
- Engineer talks directly to stakeholder
- AI structures requirements from conversation
- AI generates implementation + tests
- Engineer validates, refines, and ships
- AI reviews for security, performance, quality
- Continuous delivery — no sprint boundaries
- Spec-to-ship in the same session
- AI code review + engineer sign-off
- No handoffs — one person owns end-to-end
| Dimension | Traditional | AI-Native Pod |
|---|
| Team size | 5-7 per feature team | 1-2 per pod |
| Roles | PO, Architect, Dev, QA, SM | Senior Engineer + Stakeholder |
| Code authorship | 100% human-written | 70-80% AI-generated, human-validated |
| Requirements | PO writes tickets in Jira | Engineer + AI structure from stakeholder conversation |
| Quality assurance | Dedicated QA role, manual testing | AI-generated tests, CI/CD, engineer validates |
| Code review | Peer review (1-2 day turnaround) | AI multi-agent review + engineer sign-off (minutes) |
| Delivery cadence | 2-week sprints | Continuous — feature-complete when done |
| Cost per feature | Baseline | 50-70% reduction |
| Seniority mix | Senior + mid + junior | Senior-heavy (mid with AI experience) |
The AI-Native Pod
Pod Composition
Stakeholder
Business context & priorities
→
Senior Engineer
Owns end-to-end delivery
↔
Claude Code + Agents
Generates, tests, reviews
The pod is the atomic unit of delivery. Each pod consists of:
- 1 Senior Engineer — the accountable human. Owns architecture, implementation quality, production readiness, and the relationship with the stakeholder. This person must be capable of working autonomously and must understand the AI's output well enough to validate it.
- 1 AI Development Engine (Claude Code) — the primary code author. Handles specification structuring, implementation, test generation, code review, documentation, and PR preparation.
- Direct stakeholder access — not a PO proxy. The engineer has a direct line to whoever understands the business need. This could be a product manager, domain expert, or customer. The key is: no game of telephone.
Optional: Pod Scaling
For larger initiatives, pods can scale to 2 engineers — but the principle holds: each person works autonomously on their slice, with AI handling the heavy lifting. There is no manager-of-engineers role inside the pod.
| Pod Size | When to Use | Example |
|---|
| 1 engineer | Features, bug fixes, refactors, integrations | New report module, API integration, UI rebuild |
| 2 engineers | Large features with separable concerns | New product area (one on backend, one on frontend) |
| 3+ engineers | Avoid — split into separate pods instead | Coordination overhead negates AI speed gains |
Roles That Disappear & Transform
Roles That Disappear
| Traditional Role | Why It Disappears | Risk to Mitigate |
|---|
| Dedicated QA |
AI generates comprehensive test suites alongside implementation. CI/CD runs them automatically. The engineer validates edge cases. A separate human re-testing AI-generated code that already passed AI-generated tests adds delay without proportional value. |
Quality culture must be embedded in the engineer, not delegated. If the engineer doesn't care about quality, no QA role saves you anyway. |
| Product Owner (as ticket-writer) |
The engineer structures requirements directly from stakeholder conversation using AI. The specification is generated in the same session as the implementation. Writing detailed Jira tickets for an AI to read is an unnecessary translation layer. |
Someone still needs to prioritise what to build. The function exists — the dedicated role doesn't. |
| Scrum Master |
No sprints, no stand-ups, no velocity tracking. The pod delivers continuously. Progress is visible in Git history and deployed features, not Jira board columns. |
Cross-pod coordination still matters — but that's a tech lead function, not a ceremony facilitator. |
| Junior Developer |
AI fills the role that juniors traditionally occupied — writing boilerplate, implementing well-specified features, writing tests. The remaining human work requires judgement that comes with experience. |
This creates a long-term talent pipeline problem. Addressed below. |
Roles That Transform
| Traditional Role | Becomes | Key Change |
|---|
| Tech Lead / Architect |
Pod Lead / Principal Engineer |
Oversees 3-5 pods. Sets architectural guardrails via CLAUDE.md and rules/. Reviews cross-pod decisions. Doesn't write code daily — curates the AI's constraints. |
| Engineering Manager |
Pod Coordinator |
Manages people, not process. Fewer direct reports (since teams are smaller). Focuses on hiring, growth, and cross-pod dependencies. |
| Product Manager |
Product Strategist |
Focuses on what and why, not how. Works directly with pod engineers instead of writing detailed specs. Prioritises across pods, not within them. |
AI-Native SDLC Process
The AI-native workflow compresses the traditional 6-phase SDLC into a tighter loop. The phases still exist conceptually, but they happen in a single continuous session rather than as gated handoffs.
1
Scope
Engineer + Stakeholder
→
3
Build
AI (engineer validates)
→
4
Verify
AI tests + CI/CD
→
Phase 1 — Scope (minutes)
Engineer has a direct conversation with the stakeholder. Could be a Slack message, a 10-minute call, or a sentence in a meeting. The output is not a Jira ticket — it's understanding. The engineer knows what problem to solve and why.
Phase 2 — Spec (minutes to hours)
The engineer opens Claude Code and describes the feature. AI structures it into a specification: acceptance criteria, edge cases, data model changes, API contracts. The engineer reviews and refines. This replaces the PO writing tickets, the architect drawing diagrams, and the team doing sprint planning — all in one conversation.
- Claude generates the spec from natural language
- Engineer validates and adjusts scope
- Architecture decisions are made here, not in a separate meeting
- Output: a plan stored in
.claude/plans/
Phase 3 — Build (hours)
AI generates the implementation: code, database migrations, API endpoints, UI components. The engineer monitors progress, intervenes when the AI makes wrong assumptions, and steers direction. This is not "prompt and pray" — the engineer is actively engaged, but the keystrokes are AI's.
- AI writes code in small, testable increments
- Tests are generated alongside implementation — not after
- Engineer can pause, redirect, or take over at any point
- AI generates conventional commits as it goes
Phase 4 — Verify (minutes)
AI runs its own multi-agent review: security audit, architecture review, performance analysis. CI/CD pipeline runs the test suite. The engineer reviews the AI's findings and the diff. This replaces: peer code review, QA testing, and security review — all in one automated pass.
- AI security auditor checks OWASP top-10, secrets, injection
- AI architecture reviewer checks patterns, coupling, tech debt
- AI performance reviewer checks queries, bundle size, re-renders
- CI/CD runs the full test suite
- Engineer reviews findings and approves
Phase 5 — Ship (minutes)
AI generates the PR description. Engineer pushes, merges, and deploys. No waiting for reviewer availability. No sprint boundary. The feature is live.
Total cycle time: A feature that would take a traditional team 1-2 sprints (2-4 weeks) can be scoped, built, verified, and shipped in 1-3 days by an AI-native pod. The constraint is no longer development capacity — it's decision-making speed and stakeholder availability.
Quality Without QA
"No QA" does not mean "no quality." It means quality is embedded in the process rather than bolted on as a gate. Here's how each quality dimension is covered:
| Quality Dimension | Traditional Approach | AI-Native Approach |
|---|
| Unit tests |
Developer writes (often skipped under pressure) |
AI generates alongside code — never skipped |
| Integration tests |
QA writes after implementation |
AI generates as part of build phase |
| Security review |
Periodic manual audit or SAST tool |
AI security agent runs on every PR automatically |
| Performance |
Found in production, fixed reactively |
AI performance reviewer flags issues pre-merge |
| Regression |
QA runs regression suite (hours/days) |
CI/CD runs full suite on every commit (minutes) |
| Code review |
Peer reviews in 1-2 days |
AI multi-agent review in minutes + engineer sign-off |
| Accountability |
Diffused across team |
One engineer owns it — clear accountability |
The risk to watch: Quality without QA only works if you hire engineers who care about quality intrinsically — not because someone else will catch their mistakes. This raises the bar on who you hire. A senior engineer in an AI-native pod needs to be someone you'd trust to deploy to production without a safety net.
Requirements Without a Product Owner
The PO role as traditionally defined — writing user stories, managing a backlog, grooming tickets — becomes unnecessary when the engineer can structure requirements directly with AI assistance. But the functions a PO serves still need to happen:
| PO Function | Who Owns It | How |
|---|
| Prioritisation | Product Strategist / Leadership | Decides what the pods work on and in what order |
| Requirements clarity | Pod Engineer | Engineer talks to stakeholder, AI structures the spec |
| Acceptance criteria | AI + Engineer | AI generates from spec, engineer validates with stakeholder |
| Backlog management | Eliminated | No backlog — pods pull the next highest-priority item |
| Stakeholder communication | Pod Engineer | Direct relationship, no proxy |
Hiring Implications
The AI-native model fundamentally changes who you hire and how many.
Hire For
- Senior engineers who can work autonomously. They need to make architectural decisions without an architect, validate quality without a QA, and structure requirements without a PO. 5+ years minimum, with evidence of end-to-end ownership.
- AI fluency. The engineer must be comfortable directing AI, reviewing AI output critically, and knowing when to intervene. This is a new skill set — not all senior engineers have it.
- Product intuition. Without a PO translating business needs, the engineer needs to understand the domain well enough to push back on bad requirements and suggest better solutions.
- Communication skills. The engineer is the interface between stakeholders and the codebase. Poor communication = poor requirements = poor output, regardless of how good the AI is.
Don't Hire
- Junior developers who need mentoring and structure. The AI-native pod has no capacity for training. Juniors need a traditional team environment to develop the judgement that makes the pod model work.
- Specialists who only do one thing. The pod engineer is a generalist — frontend, backend, database, deployment. Specialists create handoffs, and handoffs are what the pod model eliminates.
- People uncomfortable with AI. If someone sees AI as a threat rather than a tool, they will fight the model rather than leverage it.
Talent pipeline risk: If the industry stops hiring juniors, where do the next generation of senior engineers come from? Aiske.ai should maintain at least one traditional team structure — even a small one — for developing junior talent. This is a long-term investment, not an efficiency play.
Governance & Guardrails
Smaller teams with more autonomy need stronger guardrails — not weaker ones. The AI-native model replaces process gates with automated enforcement:
| Guardrail | How Enforced |
|---|
| Code standards | CLAUDE.md and .claude/rules/ define conventions — AI follows them automatically. No style review needed. |
| Security | AI security auditor runs on every PR. Branch protection prevents merge on critical findings. |
| Architecture | Pod Lead defines constraints in .claude/rules/. AI architecture reviewer flags violations. |
| Test coverage | CI pipeline enforces minimum coverage. AI generates tests as part of implementation. |
| Production access | Pod engineer can deploy but not modify production data directly. Standard DevOps controls apply. |
| Accountability | Every commit is attributed. Git history is the audit trail. The engineer who merges owns the change. |
| Cross-pod coordination | Pod Lead reviews cross-cutting changes. Shared CLAUDE.md files prevent conflicting approaches. |
Proposed Organisation Structure
For a team of ~10 engineers (replacing ~25-30 in traditional structure)
| Role | Count | Responsibility |
|---|
| Head of Engineering | 1 | Strategy, hiring, cross-team alignment |
| Pod Lead / Principal | 1-2 | Architecture guardrails, cross-pod review, mentoring |
| Pod Engineers (Senior) | 5-7 | Autonomous pods, end-to-end feature delivery |
| Product Strategist | 1 | Prioritisation, stakeholder alignment, roadmap |
| DevOps / Platform | 1 | CI/CD, infrastructure, deployment pipelines |
The maths: 5-7 autonomous pods, each delivering at the rate of a traditional 5-person team, gives you the output of 25-35 traditional developers with ~10 people. The savings are not just salary — it's coordination overhead, meeting time, sprint ceremonies, and handoff delays that disappear entirely.
Questions for AMCS Discussion
AMCS are reportedly further down this road. The following questions are designed to validate our model against their experience and identify gaps we haven't considered.
1
What's your pod size and structure? How many people per delivery unit, and what roles exist inside the pod?
We're proposing 1-2 engineer pods with no QA or PO. Want to validate this against their actual experience — did they start here, or did they arrive at a different number?
2
How do you handle requirements without a Product Owner? Who decides what to build, and how do engineers get context?
The biggest risk in removing POs is requirements quality degrading. Need to understand how AMCS keeps engineers aligned with business needs without the PO translation layer.
3
Who owns quality when there's no QA? What broke during the transition, and how did you fix it?
We need real-world data on failure modes. Did bugs increase short-term? Did they find quality improved because accountability was clearer? What was the learning curve?
4
What's your ratio of senior to mid to junior engineers? Did you change hiring criteria, and if so, how?
Our model is senior-heavy. If AMCS found they could make mid-level engineers productive in pods with the right AI tooling, that changes our hiring approach significantly.
5
How do you handle on-call, production incidents, and cross-pod dependencies?
Autonomous pods can create silos. Need to understand how AMCS handles: who gets paged for a pod's code, how shared services are maintained, and what happens when pods conflict.
6
What AI tooling stack are you using? Is it Claude Code, Copilot, Cursor, or something else — and how deeply is it integrated into your process?
Understanding their tooling choices validates or challenges our Claude Code investment. Also reveals whether they've built custom agents/workflows (like our SDLC plugins) or use off-the-shelf.
7
What was the transition path? Did you restructure all at once, or run AI-native pods alongside traditional teams? How long did it take?
Critical for our planning. If we need to hire soon, we need to know whether to start with one pilot pod or restructure everything. AMCS's timeline and approach informs ours.
8
How do you solve the junior talent pipeline problem? Are you still hiring juniors anywhere, and if so, how do you develop them?
If the whole industry goes senior-only, there's a systemic risk. Want to know if AMCS has thought about this and whether they have a solution we can learn from.
9
What governance model do you use? How do you ensure consistency, security, and architectural coherence across autonomous pods?
Our proposal uses CLAUDE.md, AI-enforced rules, and Pod Leads. Want to see if AMCS has a similar approach or something different — especially around security and compliance.
10
What metrics do you track? How do you measure pod productivity without sprint velocity, story points, or traditional KPIs?
If there are no sprints, there's no velocity. We need new metrics: cycle time, deployment frequency, time-to-value, code quality scores, customer satisfaction. Want to know what AMCS found actually matters.
Recommended Next Steps
- AMCS conversation (this week). Arrange through Theo. Focus on the 10 questions above. Record key findings.
- Pilot pod (2 weeks). Stand up one AI-native pod on a real project — ideally a greenfield feature or a well-scoped rebuild. Use the process described in this document. Measure cycle time, quality, and engineer satisfaction.
- Hiring brief (after AMCS + pilot). Refine the hiring profile based on real data. Start with 1-2 senior engineer hires who fit the AI-native profile.
- Framework refinement (ongoing). Adapt this document based on AMCS learnings and pilot results. The AI-native SDLC will evolve as we learn what works.
The urgency is real. If we hire for a traditional structure now and pivot later, we'll have the wrong team. If we wait too long, we lose competitive advantage. The AMCS conversation and a rapid pilot give us the data to hire with confidence.