Free course · 9 modules · 52 minutes. The focus moves from writing code to the specification and the environment around the model. The course covers what AI-PDLC is and how the approach differs from conventional development. The core idea: outcomes are decided by the environment around the model, not by which model you pick. No tool setup, no prompt tricks — this is about how the process of building a product is put together.
For everyone on a delivery team, and for anyone who wants to understand how product development will work over the next few years. No technical background required: we work through one concrete task rather than through code.
A plain definition, where it came from and what it is not
Definition · What it consists of · What it is not
The same task run through two processes — we look at what changes
The task, and how it runs today · The same task in the new process · Where the gain evaporates
The arithmetic of the cycle, the effect of scale, and the price of speed without control
The simple arithmetic behind the disappointment · Speed on credit · Agree up front on what counts as a result
An honest picture: where the data confirms the effect and where it refutes it
The most rigorous study gives an inconvenient result · DORA: acceleration exposes weaknesses · Where the effect is real and where it is not
Why the budget goes into the agent environment, not into subscriptions
What the environment is and why it decides the outcome · The specification becomes the main document · Context costs money
How to move faster without losing control over what the agent does
Three questions, answered by different parties · Agent permissions depend on what the agent can damage · What to account for in regulatory and security requirements
Who to hire, who to grow, and whether you can really cut headcount
The main question owners ask · Which work disappears and which appears · How each role changes · New roles and when to create them · What to do as an employee when management decides to move · What to do with the people who do not want this
Metrics, false attribution and why a speed number is never shown on its own
Four groups of metrics · Three ways to fool yourself · Keep metrics in pairs
Seven steps for the first quarter: what to do, who owns it, how it ends
What to prepare in advance · Seven steps for the first quarter · How the quarter ends and what to report upwards
Partly hype, partly not, and the two are easy to tell apart. Promises like "development will get ten times cheaper" are hype. But the shift of the bottleneck from writing code to verifying intent is not going anywhere, because it is driven not by fashion but by the fact that generation really has become cheap. Even if the names of specific methodologies change, the work of putting the code in order, building automated checks and keeping an audit trail stays useful under any scenario — that is what makes it sensible insurance.
Exactly the same people as before: the team and the person who runs it. Accountability does not move to a tool, just as it does not move to a compiler or a framework. The practical side of the question is different — it is about having an audit trail of agent actions, a tested rollback and clear permission levels. Then the incident review is no different from an ordinary one: you can see what was proposed, who approved it and at which step the check failed to fire.
That is a question about the choice of model and environment, not about methodology. The methodology itself is agnostic: it describes a process and works the same way with a model in a public cloud, in an isolated perimeter or deployed locally. What does need attention is which data ends up in the agent context and in the logs. Personal data leaks more often through debug logs and test samples than through the model itself, and that has to be closed off whether or not you are adopting anything new.
The costs split into three parts, and the most visible one is not the largest. The first is payment for model usage; you will learn its order of magnitude on the very first real task, which is exactly why the cost per pass has to be measured straight away. The second is the work of preparing the environment: automated tests, module boundaries, automated checks. The third is the time people spend relearning. The second part usually turns out to be several times larger than the first, and it is also the one most often left out of the budget.
Not in the first year and not automatically. The work does not disappear, it shifts up in complexity: less writing of routine code, more reading requirements closely, designing checks and assessing plans. Compact teams of four to six people do exist, but they appear after the environment has been built, not before. Cut people earlier and there will be nobody left to do the very preparation work the whole thing was started for.
The costs split into three parts. The first is payment for model usage. My own estimate is that for a team of ten working daily this is usually hundreds of dollars a month, not tens of thousands — but the spread is enormous and depends on the model and the volume of context, so you will only learn the exact figure on the very first real task, which is why it should be measured before anything else. The second part is preparation: automated checks, putting the code in order, setting up the environment. It is usually several times larger than the first and is measured in person-months, not subscriptions. The third is the time people spend relearning, roughly a quarter of reduced productivity for those who go first. The most common budgeting mistake is to plan only for the first part.
It applies, but differently. You are not adopting the methodology yourself — you are changing what you buy and how you check it. In practice: ask the vendor to show the specifications the work is generated from, not only the result; put the handover of automated checks along with the code into the contract; ask how rollback works on their side and whether there is an audit trail of agent actions. If the vendor already works with agents, your speed will go up — but so will the risk of being handed unverified generated code. Acceptance matters more than it used to.
That is a question for your lawyers, not for me, and the answer depends on the jurisdiction and on the terms of the specific model provider. What is worth checking before you start: the terms of use of the service you pick — what they say about rights to the output and about the use of your data for training; contracts with employees and contractors — whether they cover output created with the help of tools; your confidentiality obligations to your clients. A separate practical risk: an agent can reproduce a fragment of code under a license incompatible with yours. Checking dependency licenses and code provenance is the same kind of automated check in the pipeline as any other.
There is no need to put anything on hold. The first month is one team and one task from the ordinary backlog, that is, work you were going to do anyway. No extra resources are required; what is required is agreement that this particular task will go slower than usual: working through the requirements up front and keeping records along the way takes time. In my experience with this it is worth planning for the first task to run about one and a half times longer than a typical one — that is an estimate, not a measured value. That is the price of finding out where your gaps are on a single task rather than across the whole portfolio.
It depends entirely on what you do with the checks. The data shows that generation speeds up writing by about a third and, with review left unchanged, adds around a quarter more vulnerabilities. So on its own quality goes down. It stops going down when the checks become automatic and blocking: regression, security analysis, evaluation on a reference set of scenarios (golden dataset). That is the main work of the second month in the adoption plan.
It is applicable, but more slowly and with a different first step. An agent struggles with code that has no clear boundaries: the more has to be pulled into context, the lower the quality of the plan and the higher the cost. So on legacy the first tasks are taken in the most isolated areas, while in parallel the code is carved into modules — work that was needed without AI anyway, except that now it has a measurable justification. Do not expect a fivefold speedup on a monolith in the first quarter.
The first measurable result comes after a month, and it is not a speedup. It is a list of controls that failed to fire and the cost of one pass through a task. A speedup at the level of individual teams usually shows up in the second or third month, and at the level of product release dates no earlier than six months, because until then the gain runs into unchanged release windows and approvals.
Not immediately and not from a slide deck. It makes sense to change the structure on the evidence of practice: first three teams take real tasks through the process, then it becomes visible which roles have actually changed and where new responsibilities have appeared — for example, somebody has to watch how agents behave in production. Redrawing roles before the first pass is one of the most common ways to waste a quarter.
This is exactly the case where investment in the environment pays off. The methodology is not tied to a specific model or tool: the process rules, the specifications, the automated checks and the audit trail remain yours. Changing the model turns into replacing a component and rerunning the checks. That is why you should not build the process around the unique capabilities of a single provider — and why you should keep a set of reference scenarios on which a new model can be compared against the old one quickly.
The same way buying machine tools differs from rebuilding the shop floor. An assistant in the editor speeds up one operation that takes about a quarter of the cycle — arithmetically that gives 12–15% and gets lost in the spread of delivery dates. The methodology changes the order of work: requirements are worked through with the agent up front, checks become automatic and distributed, approval receives a ready-made set of documents. The data confirms it: among companies with ten or more use cases, 66% see a speedup; among companies with five or fewer, 35%.
True enough — you can start from almost any point, and the agent really will write the tests. The readiness questions are there not to decide whether to start, but to know in advance what you will have to finish by hand. Two of the four items are not covered by a specification at all: the ability to put the system back quickly is a property of how deployment is built, not text in a document; and the baseline cost per pass, which cannot be reconstructed after the fact. On top of that, tests written by an agent block nothing on their own — you need a place where they run automatically and an agreement that a red run stops the release. At the same time it is reasonable to do the preparation with an agent too: set up the test runs, add checks for existing code, assemble a rollback script, get metrics collection going — that is days instead of weeks. The only thing an agent does not replace is what requires somebody to consent or to accept risk: the decision to stop a release on a red test, verifying rollback on a live system, and judging whether the checks that were written are meaningful.
The methodologies in question appeared in 2025–2026, there is no industry standard yet, and in a year much of this will look different. That is true. But notice what exactly goes out of date: the names of methodologies, specific tools, the wording of steps. What you do along the way — automated checks, order in the code, traceability of changes, fast rollback, a measured cost of the work — is useful under any turn of events and will not be wasted even if everything is called something else in a year. So the sensible strategy is not to wait for a standard but to invest in what will outlive the change of fashion.
With the four questions from module eight — is there a blocking automated regression, is there a trail fit for verification, has rollback been tested, is the cost per pass known. Then pick one team, on a voluntary basis, and one real task from the backlog. In a month you will have two documents: the list of controls that failed to fire and the cost per pass. With those you can go to the board; without them the conversation will inevitably slide into a discussion of hype.
The course is interactive: each module ends with a short quiz, and the next module unlocks once you pass it. Taking the course requires JavaScript. Above is the full program, the answers to common questions and the glossary in static form.
By Yury Kononov, Chief Technical Officer. The course is free and published under CC BY 4.0. Contact: @ykononov, ykononov.com.