How forward-thinking architects are rewriting the SDLC - and what IT leaders, architects, and engineers need to know right now.
There is a quiet transformation happening on some engineering teams. It looks like a markdown file, a folder of agent definitions, and a single command typed into a terminal.
/ship TICKET-ID
And then the work begins - without a developer writing a single line of code yet.
This is the agentic software development lifecycle. And the teams pioneering it aren't moving faster because they have more people. They're moving faster because they've restructured how people and AI divide the work.
Here's the playbook.
The Core Insight: AI Needs a Role, Not Just a Prompt
The biggest mistake teams make with AI in engineering is treating it like a search engine or a smarter autocomplete. You ask, it answers, you move on.
The breakthrough comes when you stop asking AI to respond and start giving it a role.
Roles come with responsibilities, boundaries, and a perspective. An architect thinks differently from a developer. A QA engineer asks different questions than a senior reviewer. When you encode those differences into how your agents are configured, you stop getting generic answers and start getting professional judgment.
The pattern looks like this:
/agents/architect.md - Designs the solution, resolves open questions, records decisions, approves the plan before a single line of code is written.
/agents/developer.md - Implements against the approved plan. Knows the codebase conventions. Does not freelance on architecture.
/agents/qa-tester.md - Tests the implementation. Knows what failure looks like. Produces evidence, not just a pass/fail.
/agents/senior-reviewer.md - Reviews the PR. Holds the bar. Pushes back when the implementation drifts from the plan.
Each agent is a markdown file - a carefully written persona and instruction set. Together, they form a team.
The Plan Document:
The single most important artifact in this workflow is the plan document.
It is not a ticket. It is not a spec. It is a living decision record that every agent reads, contributes to, and is bound by.
A well-structured plan document contains:
Status and ownership - Who approved it, when, and at what level of authority. This creates accountability and prevents scope creep.
Architectural Q&A - Every significant open question, answered before implementation begins. Should we introduce a new logging profile or reuse an existing one? Should we wire OpenTelemetry now? Each question gets a decision and a rationale. This is where architectural thinking happens.
Explicit scoping - What is in this story. What is deferred and why. This is one of the most underrated practices in engineering: making the boundary of the work visible so it doesn't silently expand.
Context that would otherwise live in someone's head - Why does this problem exist? What is the current behaviour? What does the correct behaviour look like? Write it down, because agents - like new team members - only know what you tell them.
The plan document is the contract between the human and the AI team. When it's good, every agent downstream produces better work. When it's vague, you get vague results.
The /ship Command: Orchestrated, Not Ad Hoc
Once the plan is approved, the engineer types one command. The orchestration begins.
/ship is not magic. It is a skill - another markdown file that defines the sequence of steps, the handoffs between agents, and the evidence each stage must produce before the next begins.
The sequence typically looks like:
- Architect agent reviews the plan, confirms decisions are complete, flags any gaps
- Developer agent implements against the plan - code, config, tests
- QA agent runs the test suite, exercises edge cases, produces a test evidence report
- Reviewer agent reads the diff against the plan, checks for drift, approves or raises concerns
- PR is raised - with a description auto-generated from the plan, evidence attached, decisions traceable
What used to require four people across multiple calendar days can run in minutes. More importantly, the audit trail exists by default. The decisions, the evidence, the review - all recorded, all linked to the original plan.
What This Means for IT Executives
Your engineers spend a significant portion of their time on work that is important but not differentiating - writing boilerplate, chasing context, reviewing code for obvious issues, writing PR descriptions. Agentic workflows absorb that work. Your engineers move up the value chain.
The teams that will pull ahead are the ones that invest now in:
- Agent design - the craft of writing roles and skills that produce reliable, professional-grade output
- Plan discipline - the habit of resolving architectural questions before implementation, not during
- Workflow codification turning your best engineers' implicit knowledge into skills that every team member, human or AI, can follow
Teams who master this pattern can potentially ship in days what your teams ship in sprints.
What This Means for Architects
Your role is changing - and becoming more important, not less.
In an agentic workflow, the architect is the highest-leverage person on the team. The quality of the plan document determines the quality of everything downstream. A well-resolved set of architectural decisions, encoded in a clear plan, multiplies the output of every agent that follows.
This means the architect's job shifts toward:
- Asking better questions earlier
- Writing decisions in a form that AI can reason from
- Designing agent roles that reflect how your organisation actually works
- Reviewing agent output with a critical eye - not rubber-stamping because it looks plausible
The architects who thrive will be the ones who treat plan documents and agent definitions as first-class engineering artefacts - as important as the code itself.
What This Means for Engineers
The engineers who will excel in this environment are the ones who can do two things well:
- Write context that AI can act on. Vague instructions produce vague output. The skill of writing a plan document - specific, complete, with explicit decisions and explicit scope - is now a core engineering competency. It is not documentation. It is design.
- Evaluate AI output critically. An agent that writes confident-sounding code is not the same as an agent that writes correct code. The engineer's judgment - knowing when to trust the output, when to push back, when to intervene - is more valuable than ever. AI raises the floor. The engineer raises the ceiling.
The workflow is not engineer is replaced by agents. It is engineer orchestrates agents, reviews output, and focuses on the hard problems that require human judgment.
Getting Started: A Practical Path
You do not need to build this all at once. Here is a staged approach:
Week 1–2: Start with one agent. Pick the role where AI already helps your team most - often the developer or the reviewer. Write a proper role definition for it. Use it on one real ticket.
Month 1: Add the plan document habit. Before every story, write the architectural Q&A. Even if you're not using agents yet, this practice alone will improve your output quality.
Month 2: Build the skill library. Codify your team's best practices into skill files - how you write tests, how you structure PRs, how you do code review. These become the shared standards your agents work from.
Month 3: Wire the orchestration. Once you have agents and skills, build the /ship command. Start simple. A three-step sequence that runs reliably is better than a ten-step sequence that breaks.
Ongoing: Iterate on the agents like you iterate on code. They will have bugs. They will miss edge cases. Review their output, improve their definitions, commit the changes. This is engineering work. Treat it that way.
The Deeper Shift
What this workflow represents is not just a productivity improvement. It is a different theory of how software gets made.
The old model: knowledge lives in people's heads, work happens in meetings and Slack threads, quality depends on who happens to review your PR.
The new model: knowledge is encoded in plans and agent definitions, work is orchestrated and auditable, quality is structural rather than dependent on availability.
The teams building this way are not waiting for an AI product to make it easy. They are building the workflow themselves, with tools that exist today, because they understand that the competitive advantage is not the AI - it is the system you build around it.
The question for every engineering leader, architect, and engineer is not should we use AI?
It is: what system are we building?
If your team is working through what this looks like in practice - the agent design, the plan discipline, the orchestration patterns - this is one of the most valuable conversations to be having right now. Drop a comment or reach out directly.
#AIEngineering #SoftwareDevelopment #AgenticAI #EngineeringLeadership #FutureOfWork #ClaudeCode #TechLeadership
Here's the playbook