Most organizations adopt AI coding tools the same way. They buy seats, turn on autocomplete, and wait for delivery to speed up. We did the first two, and delivery barely moved, because typing was never the bottleneck. This is how a global organization of engineers and research analysts moved from AI as a faster keyboard to AI as part of how work is planned, built, checked and run. Amazon Q Developer and Kiro were the mechanism. The bigger change was cultural: making it normal to try three working options before arguing about one.
Adding AI to the old process was the trap
The first wave was Amazon Q Developer, rolled out broadly for inline completion and chat. It helped. Engineers wrote boilerplate faster and interrupted each other less. But the shape of delivery did not change. Requirements still arrived as tickets, design still happened in meetings that ran for weeks, tests were still written last when they were written at all, and the AI sat at the one step that was already the cheapest.
The AI-Driven Development Lifecycle method definition, AI-DLC for short, gave us the language for what was wrong. It separates two eras. In the AI-assisted era, a person drives and AI helps with narrow tasks. In the AI-driven era, AI proposes the plan, breaks the intent into work and lays out the trade-offs, while people approve, correct and decide. Its first principle is to reimagine the method rather than retrofit AI into it, and its analogy stuck with our teams: you set the destination, the map proposes the route, and you stay in charge of the drive. We had retrofitted. We had built a faster horse.
The method makes a second point that landed just as hard. When build cycles shrink from weeks to hours, rituals designed for weeks start to lose their meaning. Story points matter less when AI blurs the line between simple and hard tasks, and velocity matters less than business value delivered. We did not drop the old rituals overnight, but we stopped defending them by default.
Industry research on AI-assisted software delivery points the same way. AI amplifies the system it lands in. A team with clear specs, small batches, fast feedback and a solid platform gets faster and safer. A team without them produces more code into the same queues, and stability gets worse. That shaped the whole program: fix the lifecycle first, then scale the tools into it.
The lifecycle we adopted
AI-DLC has three phases, and every step produces an artifact that becomes richer context for the next. That idea changes outcomes more than any single tool. A model is only as good as the context it is given, so a lifecycle that keeps producing well-formed context keeps producing better output.
Inception: from intent to units
Work starts as an intent, a plain statement of the outcome we want. In a mob elaboration session, the product owner, engineers and QA work with the AI on one shared screen. The AI asks clarifying questions, then proposes user stories, non-functional requirements, risks and a breakdown into units, which are loosely coupled pieces that can be built in parallel. The people in the room fix what is over-built or under-built. Work that used to take weeks of handoffs gets done in a few hours, and everyone leaves with the same picture.
Kiro's spec workflow made this concrete. A spec session turns a prompt into testable requirements, a design and a sequenced task list before any code exists. That is inception, captured as files in the repository instead of slides from a meeting.
Because the spec lives in the repository, it gets reviewed like code, in a pull request, before any implementation starts. This moved review to where it is cheapest. Reading two pages of requirements and design takes minutes, and a wrong assumption caught there never turns into two thousand lines of plausible code that someone has to read, question and throw away.
Construction: design before code, in short bolts
Construction moves through domain design, then logical design, then code and tests. The AI models the business logic first, applies the non-functional requirements and patterns, writes architecture decision records for review, and only then generates code with its tests. AI-DLC calls each short build cycle a bolt, measured in hours or days rather than sprint weeks.
Small bolts also protect the scarcest resource in an AI-driven team, which is careful human review. An agent can produce a very large change in minutes, and a large change gets skimmed, not reviewed. Keeping each bolt to a small, focused pull request keeps review real, keeps rollback cheap, and keeps the flow principles that make delivery fast in the first place.
Most of what we own is not new, so one step from the method mattered most. Before changing existing code, the AI first lifts it into a static model of components and responsibilities and a dynamic model of how they interact for the important use cases. Engineers check those models, and only then does construction begin. On a large legacy codebase, this habit cut down the confident but wrong changes that come from an agent seeing only the file in front of it.
Operations: the agent proposes, people approve
In operations, the AI reads metrics, logs and traces, matches what it sees against runbooks, and proposes an action. The DevOps agent we introduced across the delivery lifecycle works exactly this way: it drafts the fix or the scaling change, and a person approves it. The method describes each human checkpoint as a loss function that catches errors before they compound downstream, and that is how it felt in practice.
Adoption came in stages, not in one launch
AI-DLC did not arrive as a program with a launch date. The organization moved through the four stages in the first diagram, and each one earned the next.
Stage one: assist
Amazon Q Developer put AI in every engineer's editor and made access a solved problem. Sign-in ran through corporate identity, entitlements followed directory groups, new joiners had access on day one, and leavers lost it automatically. There were no shared credentials and no long-lived keys. This stage was about trust and habit more than productivity.
Stage two: specify
Kiro became the center of stage two for practical reasons. Its spec-driven workflow matched AI-DLC inception almost step for step. It was offered as the successor to Amazon Q Developer, so the existing fleet had a managed migration path instead of a replacement. It is built on Code OSS, so engineers kept their editor settings, keybindings and extensions, which removed most of the small annoyances that kill a new tool. It let us choose among models, which mattered because model availability differs by region, and one tool under one set of rules beat a patchwork of regional exceptions. And its extension points, steering files, agent hooks, MCP integration and Powers, turned out to drive almost everything that followed.
Licensing followed the work, not the job title. Seats came in tiers from standard to heavy agentic use, upgrades were approved against actual usage, and idle seats were flagged for reclaim. The fleet grew past 1,200 seats across Kiro and Amazon Q Developer, with roughly three in four users active in any 30-day window.
Stage three: practice, the people program
Choosing the tool was the easy half. A widely cited rule of thumb for AI programs puts roughly 10 percent of the outcome in the algorithms, 20 percent in the technology and 70 percent in people and process, and our experience matched it. So adoption ran as its own change program, with a plan, owners and measures, not as a side effect of buying licenses. The method itself says AI-DLC is learned by practicing its rituals on real problems, not by reading about it, and every part of the program was built around that.
Train the trainer. Working with the tool provider's solution architects, a core team trained a first cohort of champions in depth, one embedded in every domain team. Champions got early access, deeper training and a direct line back to the provider, and in return they became the local answer to the question every rollout depends on: how does this work on our code? A teammate showing a real diff from your own repository convinces people in a way no vendor demo can. It also scales. A central team can train a few dozen people well. Those people can reach everyone else.
Brown bags and immersion days. Around the champions ran short, hands-on sessions, each deliberately narrow: how to write a spec that produces testable requirements, how to set up hooks for commit messages, documentation and quality checks, how to manage context so the agent is not drowning in noise. One skill per session, practiced on real work, beats a broad overview every time. Immersion days ran in each time zone so no region learned second-hand.
Skeptics at the table. Fewer than half of developers trust the accuracy of AI output, and that caution is rational. Instead of arguing with it, skeptics were paired with champions and the diffs did the arguing. The goal was a specific shift, from manual coding with occasional AI help to AI-augmented system design, where the engineer's job is defining the problem precisely and reviewing the solution critically.
Reinforcement, not a launch. Prompt analytics at the individual level showed who needed what, so training went to the actual gaps, such as the unused test generation and code review features, instead of repeating the basics to everyone. Teams published short success stories with their numbers attached in the developer hub, which did more for adoption than any mandate. The roughly 75 percent active rate is the result. Plenty of enterprises buy AI seats that become shelfware. These got used because someone two desks away knew how to use them well.
Expansion. Then the change left engineering. Research analysts watched engineers work and asked for seats, and the champion model was extended to research teams. Because governance, license tiers and access were already in place, the expansion was orderly rather than shadow IT. Within a quarter, research roles produced about a quarter of all usage, mostly Python, SQL and YAML.
Stage four: automate
The last stage moved AI from the chat window into the system itself. Hooks run linting, tests and scans on save and on commit. MCP connects the agent to internal systems through vetted configurations. Powers bundle steering, hooks and MCP settings into one installable unit, so a new project starts on the paved road in a single step. The DevOps agent runs across the lifecycle under the same rules and the same audit trail.
An agent that can act needs the same controls as a person who can act, and a few more. Each agent runs under its own identity with least-privilege access. MCP tools are read-only by default, and anything that changes a system needs a human approval. Every action is logged. Content the agent reads from tickets, documents or web pages is treated as untrusted input, because instructions hidden in that content are the most common way an agent gets steered into doing something it should not.
Options, not opinions
The cultural change that mattered most was not about tools. It was about how decisions get made.
A design question used to go to a meeting. Two senior people argued from experience, the more confident view usually won, and the team found out months later whether it was right. With an agentic IDE, a working prototype of each option costs hours, not weeks. So we made it normal, and then expected, to bring running options to a design discussion instead of opinions about options.
The industry calls this vibe coding: describe what you want and let the model write it. It is excellent for speed and dangerous as a deployment strategy. We did not ban it. We gave it a clear place in the lifecycle. A vibe-coded prototype is a question, not a commitment. It is built fast, compared in the open, and then mostly thrown away. What survives is the decision, which goes into the spec, and the spec is what gets built properly.
Three norms kept this healthy. A prototype is labeled as one and never goes to production without passing through the spec and the gates. Discarding a prototype counts as a good outcome, because it answered a question for the price of an afternoon. And the comparison happens on running software, with the people who will build and own it in the room, which ties straight back to the mob rituals.
The same door opened for people who do not write code for a living. An internal studio lets an analyst pick a starting shape, a static site, a dashboard fed by an API or a chatbot, describe what they want, and get a versioned, hosted page on an internal domain with every iteration saved. During a fast-moving market event, an analyst stood up a live monitor of prices and supply flows without filing a single engineering ticket. That is the speed we refused to give up, and it is why the path to production had to be automatic.
Measure prompts, not seats
Seat counts and active users tell you people showed up. They say nothing about whether the work is good, and research on software delivery has warned that rising AI use can come with falling stability when verification does not keep pace. So we built prompt analytics into the developer portal. Prompts were logged to a governed data store, and a classification pipeline running a small, inexpensive model tags a rolling sample of 20,000 interactions every 30 days by category, complexity and a quality score from 1 to 5. Anything sensitive is flagged for security review.
The results were humbling.
Average quality was 2.3 out of 5. Teams spent 7.7 times more AI effort on reactive debugging, 22 percent of interactions, than on design and architecture, 3 percent. Simple tasks outnumbered complex ones about five to one, and simple prompts scored worse, 2.4 against 3.3. People write careful prompts when a problem scares them and one-liners when it does not, then accept weak output because the task felt too small to redo. The test generation and code review features were barely touched. We were applying AI at the cheap end of the lifecycle and ignoring the expensive end, where a defect found in production costs an order of magnitude more than one found in design.
One more lesson. Inline completion acceptance was low, because people had moved to the agent and chat. Judged by acceptance rate, the usual metric for AI coding tools, the rollout would have looked like a failure. Measure the workflow your people actually use, not the one a dashboard assumes.
Prompt quality is a leading indicator. Delivery outcomes are the lagging truth, so the two were read together. AI-assisted commits are labeled, which lets lead time, change failure rate, time to restore and review time be compared for AI-assisted and other work, instead of guessing. Lines of code and suggestion counts were never treated as success measures. They reward volume, and volume is the one thing AI already produces in excess.
Three changes that moved quality
Make good prompts the default
Instead of teaching prompt craft one person at a time, we changed the defaults. Every repository got steering files with our architecture decisions, naming conventions and standards, backfilled with Kiro's steering generation so it was a one-click job rather than a documentation project. Nontrivial work starts as a spec session, which forces the acceptance criteria the data said mattered. A developer hub holds spec templates, vetted MCP configurations, reference architectures, and a prompt library curated from interactions that scored 4 or 5. When the classifier finds a pattern that keeps scoring well, it goes into the library, so the defaults improve as usage grows.
Route models by task
There was a strong belief that the top model always gives better results. The data did not support it. Large models earn their cost in planning, task breakdown and design. Executing a well-specified task runs fine on smaller models. The pattern became simple: plan on the big model, execute on the small one. The cost conversation moved away from tokens and toward license use, which is where the money actually was.
Send knowledge questions somewhere cheaper
About half of all interactions were general explanations, boilerplate or the same routine tasks repeated. An agent session is an expensive way to ask what a design pattern is. We moved how-to content into internal documentation and pointed repeated boilerplate at shared templates and hooks, which kept agent time for real engineering and cleaned up the analytics.
From vibe to production, without a review board
Two paths feed one pipeline: the studio for analysts and Kiro for engineers. For engineers, an internal MCP server reads a project and maps its parts to deployment targets, static assets to object storage behind a CDN, services to containers and APIs behind a managed gateway, and generates the matching infrastructure code. A prototype no longer sits on a laptop waiting for someone to work out how to deploy it.
After that, it is automation. Hooks run linting, tests and security scans locally while the context is still on screen. In the pipeline, every AI-generated commit is checked against the architectural boundaries in the steering files, test coverage thresholds, static security checks and well-architected guidance for generative AI workloads. The checks group into three gates. The vibe audit verifies every dependency, because models regularly invent package names that attackers then register, scans for secrets, and splits the single giant file models like to write into modules a team can maintain. The rigor gate adds tests toward an 80 percent coverage bar, with the AI writing tests for its own code and a person reviewing them, and replaces loose typing with strict types and runtime schema validation. The red team gate enforces parameterized queries, sanitizes input, and wraps external calls in rate limits, circuit breakers and backoff. Policy lives as code, so it applies to everyone, every time, without a meeting.
What changed
Cycle time from concept to first pull request dropped on teams running spec sessions, because requirements, design and task breakdown now take minutes instead of a series of meetings. Feature velocity rose across domains, furthest on the champion-led teams. Test coverage on legacy services, the exact place the first analysis found almost no AI-generated tests, climbed once save-time hooks and retroactive test generation took over the tedious part. New teams ramp in days rather than weeks, because they fork the paved road instead of inventing their own. And concept to working prototype became fast enough that product ideas get tested with users before they get debated in planning.
The next steps follow the same lifecycle. Custom MCP servers are being wired into the platform control plane so the agent can act on infrastructure under the same steering rules and gates. Agentic CI/CD is next, where a failed gate does not just block a merge but opens a corrective pull request for a person to approve. The internal targets stay public: move design and architecture work into double digits as a share of AI effort, and keep raising average interaction quality.
What I would tell another leader
Reimagine the lifecycle instead of adding AI to the old one. Start with inception, where a spec is cheap and a wrong assumption is expensive. AI amplifies the system it lands in, so fix the system first.
Budget for enablement as part of the license cost, because it is. Champions, narrow hands-on sessions and pairing skeptics with practitioners are what turn seats into daily use.
Measure prompts, not adoption, and publish the numbers internally, including the uncomfortable ones. The quality scores changed behavior in a way the seat counts never did.
Make experimenting cheap and safe at the same time. Welcome vibe-coded options as the normal way to explore, then make the path to production automatic and strict. AI-generated code gets no pass a junior engineer would not get.
The tools made this possible and the telemetry kept it honest. The habit of trying options before debating them is the part that will outlast both.