The ADLC library · Topics
Every subject in the library, on one page.
The library runs to 193 published pieces across 14 series. This page exists so you can find the ones on your problem without reading the list in order. Series first, then the topics that cut across them.
Foundations
What the agentic development life cycle is, and which parts of your current process stop working when agents write a meaningful share of the code.
What we mean by the Agentic Development Life Cycle The SDLC rested on two quiet assumptions. Agents break both, and most of the pain teams are feeling right now is the sound of that breaking. The two assumptions the SDLC was built on, and why agents break both A human wrote the change. A human kept the plan honest. Take those apart one at a time and you can see exactly which load-bearing wall agents removed. Who actually writes your code now, an honest audit Most teams have a confident opinion about how much of their code is agent-written and no evidence for it. Here is how to find out, and why the answer is usually uncomfortable in both directions. Why "AI writes code" is the least interesting part of the shift Code generation is the visible half of the change and the settled half. The unsettled half is everything the act of writing code used to hold together on its way past. The bottleneck moved, from typing to verifying Speeding up one stage of a pipeline does not speed up the pipeline. It moves the queue. Here is where the queue went, and why verification is a much harder constraint than production ever was. Ground truth as an organising principle Every record in your company is a copy of something except one. Deciding which artefact is authoritative, and deriving the rest from it, turns a hundred small arguments into one design decision. Why the tracker became the weakest link Jira did not get worse. The world it was designed for stopped existing. Understanding what it quietly assumed explains why it fails now in a way that no configuration can fix. Autonomy versus control is a false binary The choice everyone thinks they face is how much to let agents do. The actual choice is how much you can verify, and it is verification, not restriction, that buys autonomy. What a life cycle even is, and why yours is implicit Nobody at your company wrote down how work becomes software. It happened anyway, by accumulation, and the parts nobody chose are the parts that fail first under speed. The ADLC in one diagram, explained slowly Six stages and two loops. Most of it is your existing life cycle unchanged. The parts that are new are new for a specific reason, and it is worth walking each one at reading pace.
SDLC vs ADLC
Where the old life cycle and the new one differ in practice: review, planning, estimation, and what a stage gate means when the author is a model.
Planning: from estimation ritual to derived plan Estimation was never really about accuracy. It was a scheduling device for scarce human attention. When the attention stops being the constraint, the ritual stops paying for itself. Requirements: prose for humans versus criteria for agents A ticket written for a colleague and a ticket written for an agent look almost identical and behave completely differently. The gap between them is where most agentic rework comes from. Code review: from gatekeeper to sampler Reading every diff was always a fiction, and agents turned it into an obvious one. What replaces it is not less rigour but rigour aimed at classes of change rather than individual ones. QA: what changes when tests are also generated A green suite used to be evidence because a human wrote the assertions from a different understanding than the code. When one system writes both, the independence disappears and the signal quietly weakens. Standups: the ceremony agents made obsolete The daily standup was a synchronisation protocol for a system with no other way to read its own state. Most of what it transmitted is now derivable. The part that is not is worth protecting deliberately. Sprint boundaries in a world of hourly cycles The two-week sprint was a batching decision made when planning was expensive and deployment was risky. Both costs collapsed. What remains is a rhythm, and rhythm is worth more than most people think. The pull request as the new unit of governance Every control an organisation cares about is converging on one artefact that was designed for none of them. That is mostly good and worth doing deliberately rather than by accident. Handoffs: fewer people, more machine boundaries Lean thinking taught us that every handoff is waste. Agentic teams have fewer human handoffs and considerably more boundaries, and the new ones fail differently: silently, plausibly and at speed. Documentation that regenerates itself We can now generate accurate descriptions of what code does, cheaply and continuously. That solves the smaller half of the documentation problem and makes the larger half more urgent. What the SDLC got right that we should keep Nine pieces arguing that the old life cycle rested on broken assumptions. This one argues the other side: which practices were load-bearing for reasons that have nothing to do with who writes the code.
Metrics & DORA
What happens to delivery metrics when throughput rises and the record of the work does not keep up. Which numbers still mean something, and which quietly stop.
What happens to DORA when you move to the ADLC The four keys still measure something real. They just stop measuring the thing you built them to measure, and the change is quiet enough that most teams miss it for a quarter. Deployment frequency when merges outpace decisions The oldest of the four keys was a proxy for removed friction. Under the ADLC it becomes a proxy for something else entirely, and the difference matters more than the number. Lead time for changes: the metric agents distort most Lead time was always a measurement of queueing. Agents collapse the part of the queue we measure and leave the part we do not, which makes the number improve while nothing gets faster. Change failure rate is the one to watch Three of the four keys get flattered by agentic development. Change failure rate is the one that can still tell you something is wrong, provided you stop reading it as a rate. Time to restore in an agent-heavy codebase The most robust of the four keys hides a phase that agentic development makes much harder. Restoring service is unchanged. Working out what to restore is not. Why elite DORA scores can hide a rotting board All four keys can be green while your system of record has become fiction. The metrics measure the flow of changes. Nothing in them measures whether anyone still knows what is true. The metrics DORA does not capture in the ADLC The four keys were designed for a world where writing code was the constraint. Here is what stopped being measured when that stopped being true, and which absences are worth filling. Rework rate: the missing fifth key Every one of the four keys treats a change that undoes a previous change as progress. Under the ADLC that is the single most expensive blind spot in the set. Definition-of-done adherence as a first-class metric For fifty years the definition of done was a document nobody read. It is now the interface an agent builds against, which makes adherence to it something you can and should measure per change. Measuring drift, and why it predicts slippage The gap between what your board says and what your repository shows is measurable, cheap to compute, and moves before your delivery dates do. Instrumentation-free measurement: reading the repo instead Most metrics programmes fail because they ask people to produce new data. The repository already contains almost everything, and it has the one property self-reported data never has. How to present ADLC metrics to a board A board does not want your deployment frequency. It wants to know whether the money is working, what happens if it is not, and how fast you would find out.
Definition of done
Acceptance criteria that can be checked, criteria an agent cannot game, and what done has to mean before a machine is allowed to decide it.
Why "works correctly" is now a production incident Vague acceptance criteria used to be free, because a human filled the gap with taste. An agent fills it with the literal text, and ships that at speed. Writing acceptance criteria an agent cannot game Precise criteria are not the same as unGameable criteria. Here are the specific patterns that look rigorous, pass cleanly, and deliver nothing. Given/When/Then, revisited for machine readers The format was designed to get a business analyst and a developer talking. It is now being parsed by software. That changes what a good scenario looks like. Checkbox criteria versus semantic criteria One has a state a machine can read. The other needs judgement to settle. Most teams mix them without noticing, and then wonder why automation is unreliable. Scoring your backlog's ability to define done Before you fix anything, measure it. A concrete rubric for grading acceptance criteria at scale, and what the first run usually tells you. Remediating four thousand vague tickets You measured the backlog and it is bad. Marching through it in order is the wrong answer. Here is a triage that finishes in weeks rather than never. From PRD to ERD to execution plan, mechanically Requirements, data model and work breakdown are usually three documents that drift apart. Here is what has to be true for the chain to hold without retyping. Who owns acceptance criteria when agents draft them A drafted checklist and an authored one look identical in the ticket. Only one of them carries a decision. That difference is an ownership problem, not a tooling one. The AC gate: what should block a merge A gate that blocks everything gets disabled in a fortnight. A gate that blocks nothing was never a gate. The interesting design is what happens in between. Verifying criteria against the diff, and its limits Reading a change and asking whether it satisfies a written criterion works better than expected, and fails in ways worth naming precisely before you rely on it. When to say "needs human verification" and mean it A decline is only useful if it changes what somebody does. Most teams turn theirs into a checkbox within a fortnight, and then wonder why the gate stopped catching anything.
Failure modes
The specific ways agentic delivery goes wrong: silent drift, tests that certify the bug, undeclared dependencies, and reviews nobody can explain.
Speed without a definition of done gets you to the wrong place faster The ticket said "improve the search experience." Nine days and eleven pull requests later, the team had shipped something nobody wanted. Nothing had gone wrong, exactly. The confidently wrong pull request It had a clear summary, a passing test suite, and a rationale for every decision. It was also wrong in a way that took eight days and a production incident to find. Silent scope drift in agent-authored work The ticket was a two-line config change. The merged diff touched nineteen files, and every one of those changes was individually justified. That is what makes it hard to catch. When your board becomes fiction, in weeks not quarters Boards have always drifted from reality. What changed is the rate. A board that used to take a quarter to become misleading now manages it in about eleven days. Review fatigue and rubber-stamping at volume Nobody decides to stop reviewing properly. It happens gradually, it is a rational response to an impossible queue, and the metrics get better the whole way down. Agents optimizing to the letter of the criteria You finally wrote acceptance criteria precise enough to check. Every one of them passed. The feature still did not work, and the criteria are now the reason nobody noticed. The orphan pull request problem A third of the changes going into production have no ticket attached. That is not a hygiene issue. It is a hole in every number your organisation reports about itself. Cross-team dependencies nobody declared The dependency was real, mutual, and invisible. Both teams found out about it in the same week, from the same incident, four days before a launch. Over-automation: when write-back makes things worse A board that updates itself is better than a board nobody updates. Except when it is not, and the failure mode of an automated record is meaningfully nastier than the one it replaced.
Transition playbook
Moving a real organisation from one way of working to the next, including shadow mode, brownfield backlogs, and what to do in the first ninety days.
A ninety-day plan for moving to the ADLC Not a maturity model and not a transformation programme. A week-by-week sequence that starts with measuring the gap and ends with a decision you can defend. Start in shadow mode, proving before writing Run the automation for a full cycle with every write turned off. The fortnight it appears to cost is the cheapest insurance available in this entire transition. Pick one team, not the whole org The selection criteria that actually predict whether a pilot survives contact, and why the most enthusiastic team is usually the wrong one to start with. Brownfield first, and why greenfield advice misleads Almost every account of agentic development you will read describes a new codebase with no history. Your codebase has history, and that changes which advice applies. Sequencing, criteria before automation, always Automating a process whose definition of done is vague does not fix the vagueness. It industrialises it, and gives it an audit trail that makes it look deliberate. What to automate first, and what to leave alone Rank candidate automations by the cost of being wrong, not by the time they save. The ordering that produces is unintuitive and it is the one that survives. Getting developer buy-in without a mandate Engineers have watched a decade of tooling arrive as surveillance wearing a productivity badge. Their suspicion is earned, and the way through it is not a better presentation. Convincing a skeptical VP of Engineering Their skepticism is usually well founded, and the way through it is to argue a smaller case than you want to argue, with numbers from their own organisation. The rollback plan you should have before you start Not a disaster recovery document. A written answer to what you switch off, in what order, and what state you are left in, produced before anything is switched on.
Roles & org
What the work of a tech lead, a manager and a TPM becomes when the bottleneck moves from writing code to deciding and verifying.
What a TPM does when the chasing stops Most of a technical program manager's week is spent reconstructing a status that already exists somewhere. Take that away and what is left is the part that was always the job. The product manager's job in the ADLC When code stops being the constraint, the specification becomes it. That is a promotion for product management and a much less comfortable one than it sounds. Engineering managers as system designers When output stops being scarce, managing output stops being the job. What is left is designing the queues, the gates and the loops that decide whether the output is any good. The staff engineer in an agent-heavy codebase When generating code stops being the constraint, the highest-leverage engineer in the building stops being the one who writes the most of it. What replaces that is less glamorous and considerably more important. What code review becomes when most code is generated Review was designed for a world where writing code was slow and expensive. Both halves of that assumption have broken, and the ritual has not been redesigned to match. QA does not disappear, it moves left and up Testing has been declared dead twice in twenty years and has come back larger each time. The agentic life cycle does not remove the need for quality work, it relocates it to the two places nobody staffed. Team shapes when throughput stops tracking headcount Almost every planning assumption in a modern engineering organisation rests on output being roughly proportional to people. Break that link and team design, capacity planning and the org chart all need different logic. Hiring for the ADLC, and what to screen for now Technical interviewing was calibrated to predict who could produce correct code under time pressure. That signal is now cheap to fake and less predictive of the job, and almost nobody has rewritten the loop. On-call for code nobody remembers writing Incident response has always leaned on a hidden asset: somewhere in the organisation, a human remembered building the thing. That asset is quietly disappearing, and most runbooks assume it is still there.
Governance & security
Policy, provenance, data residency, threat modelling and the evidence an auditor will actually ask for.
Proving what an agent did, six months later The question is never asked on the day. It is asked half a year later, by someone who was not there, about a change nobody remembers, and your answer has to survive that. Audit chains explained without the crypto hype Strip away the marketing and a tamper-evident log is a very old, very boring idea that fits on a napkin. Worth understanding, because the boring version is the one that holds up. What auditors will start asking about AI-written code The questions are not new. What is new is that the answers your change-management process has given for a decade quietly stopped being true, and nobody has told the auditor yet. Least privilege for agents, and what they should never be able to do Most agent deployments inherit the permissions of whoever set them up, which is the single most consequential unexamined decision in the whole stack. Some capabilities should be structurally unavailable regardless of how well the agent behaves. Data residency when the model lives somewhere else Every honest conversation about agentic coding in a regulated environment arrives at the same question, and most vendors answer it with a claim they are not in a position to make. The air-gapped ADLC Running an agentic life cycle with no outbound network at all is not the same system with the internet removed. Several things you rely on quietly assume connectivity, and finding them during the build is much cheaper than finding them after. Prompts, context, and the leak surface that did not exist before Data loss prevention was built around files moving and people sending them. Agentic development creates a channel that looks like neither, carries more context than anyone intends, and is largely unmonitored. Change management when the committer is a machine Most change control frameworks were written assuming a person authored, a person approved, and both could explain themselves. None of the three survive contact with an agentic pipeline, and the frameworks have not been updated. Incident response when an agent caused the incident Blameless postmortems were designed around human error, and they work because they assume a person had a reason. Remove the reason and several load-bearing parts of the practice stop functioning.
Economics & tooling
What agent work costs, how to attribute it to the work it served, and how to choose tooling that survives a change of vendor.
What agents actually cost, per ticket Your provider invoice is a single number for a hundred different activities. Here is how to build a per-ticket cost model that survives the next price change. Attributing model spend to features and teams Splitting one provider invoice across an org chart looks like an accounting problem. It is really a question about where you draw the boundary, and the boundary you pick changes behaviour. Cost controls that do not degrade quality Most cost controls are quality cuts in disguise, and the bill just moves to a line item nobody is watching. A few are free. Here is how to tell them apart. Build versus buy for the ADLC control layer This decision gets made badly in a specific and repeatable way: teams estimate the demo and pay for the maintenance. Here is what the real comparison looks like once you count the parts nobody demos. The hidden cost of context Every conversation about agent economics focuses on output tokens, which are the visible half of a bill dominated by the invisible half. Context is the line item nobody budgets and almost everybody overpays. Model choice as an economic decision Teams pick models the way people pick text editors, on affinity and habit. It is a routing problem with a measurable answer, and the answer is different for different kinds of work in the same codebase. When the agent is cheaper than the meeting about the ticket Software economics has always been discussed in terms of engineering time, which was the expensive input. Once generation is nearly free, the expensive input turns out to be coordination, and almost nothing in how we work is organised around that. Measuring ROI without lying to yourself Almost every published productivity figure for agentic development is measuring something easy in place of something that matters. Here is what the honest version looks like, including the parts that are uncomfortable.
Open knowledge
Documentation, retrieval, context and the knowledge an agent needs before it can do anything useful in your codebase.
What the Open Knowledge Format is, and why the ADLC needs one Google Cloud published a v0.1 spec that says knowledge is a directory of markdown files. The unglamorous part is the point, and it is exactly what agentic development has been missing. The LLM-wiki, formalised The pattern spread as folklore before it had a specification. Now that it has one, it is worth asking what formalising a folk practice actually buys you, and what it costs. One concept per file: the filesystem as schema The oldest data structure in computing turns out to be a decent knowledge schema, provided you accept one rule. Getting the cut right is harder than it sounds. Front matter as the agent's index The spec requires exactly one field. That restraint is a design decision worth taking seriously, and it says something about what metadata is actually for. Markdown links as a knowledge graph A directory of linked markdown files is a graph nobody had to build. It is weaker than a real graph database in ways that matter, and stronger in the one way that matters most. Acceptance criteria as portable knowledge Most criteria die with the ticket that carried them. Treating them as concepts with a path, rather than a text field in a tracker, changes what they can do. Your PRD and ERD are knowledge, not documents Planning artefacts are written once, read during kickoff, and abandoned. Most of what they contain is durable. The document format is what kills it. Runbooks, metric definitions and the shared vocabulary problem Two teams in the same company, using the same word, meaning different things. It was survivable when humans mediated. It is not survivable when agents write the query. Curated context versus retrieval: when structure beats search You can index everything you already have in an afternoon. Curating a knowledge base takes months. The case for doing the slow thing is narrower than advocates claim and stronger than sceptics think. Keeping a knowledge base true, the drift problem all over again Everything that makes a board go wrong makes a knowledge base go wrong, for the same reason. A record nobody is obliged to update is a record that will be false.
The long view
Where this is going over years rather than quarters, and which of today’s assumptions are likely to break.
Predictions we are willing to be wrong about Seven claims about where the ADLC goes next, each with a date and a stated condition that would prove it wrong. A prediction nobody can check is not a prediction. The ADLC in five years, and what stays human The generation of code is nearly solved. Taste, judgement about what is worth building, and the person who answers when an agent is wrong are not, and will not be. What we will miss about the SDLC Every transition in this industry gets narrated by its beneficiaries, which means the losses go unrecorded until it is too late to keep any of them. Some of what the old life cycle provided was genuinely good.
Verticals
How the same problems look in regulated, embedded, public-sector and other settings where the rules are not negotiable.
What agentic delivery changes in fintech and payments Money movement has a property most software does not: the failures are irreversible and somebody else's. That changes which parts of the agentic life cycle you can adopt quickly and which you cannot. What agentic delivery changes in banking core A core banking platform is the least forgiving environment in commercial software: decades of accumulated logic, a change advisory board, and a ledger that regulators can ask about years later. Almost none of the standard advice survives contact. What agentic delivery changes in healthcare The constraint in health software is not that changes are risky. It is that the data an agent would find most useful is the data it must never see, and that shapes the whole adoption path. What agentic delivery changes in insurance Insurance has a constraint almost no other software industry has: some changes cannot legally take effect until a regulator approves them, and the software has no idea which changes those are. What agentic delivery changes in medtech Device software is the one domain where the documentation is not overhead around the work: it is a regulated deliverable in its own right. That inverts the usual argument about what automation is for. What agentic delivery changes in defense and govtech This is the one industry where the standard architecture is simply unavailable. No egress, no hosted model, and an accreditation boundary that treats new software as a change to be justified rather than a capability to be adopted. What agentic delivery changes in telco Telco engineering is split down the middle: a network side where change windows are measured in months, and a digital side that ships daily. Agentic delivery lands very differently on each, and conflating them is the standard mistake. What agentic delivery changes in e-commerce and retail Retail is the one domain in this set where you can adopt almost everything immediately. The interesting constraints are not regulatory: they are the peak freeze, the experiment layer, and a catalogue that behaves like production code without being any. What agentic delivery changes in energy and utilities Utilities run two systems with almost nothing in common: an operational technology estate where a bad change has physical consequences, and an IT estate that looks like everyone else's. The boundary between them is the whole story. What agentic delivery changes in dev tools and infrastructure Building software that other engineers build on has a property no other domain shares: your bugs execute inside your customers' pipelines, and your blast radius is every team that depends on you.
Live debates
Arguments currently running in the field, taken seriously on both sides rather than resolved in our favour.
Review is the bottleneck. Adding reviewers will not fix it. The numbers on agentic pull requests are worse than most teams realise, and the obvious response is the one that reliably fails. Queue length is a system property, not a staffing gap. Spec-driven development is not waterfall, and the comparison is lazy Every time specification comes back into fashion, someone says waterfall. It is the fastest way to sound experienced while avoiding the actual question, which is who writes the spec and whether anything can check it. AI-generated technical debt deserves its own category The debt everyone is worried about is not worse code. It is code that works, that nobody has read, in quantities no team can catch up on. That is a different problem with a different fix. The junior pipeline broke and nobody owns fixing it Entry-level postings are down around 40%. The work juniors learned on is the work that automated first. Every organisation is quietly assuming someone else will train the next generation of seniors. The AI Act arrived in August. Most teams noticed nothing. Enforcement began on 2 August 2026 and no developer workflow changed that morning. That is not evidence the obligations are light. It is evidence they land somewhere engineering does not look. The zero-review merge is the only number that matters Most review metrics can be satisfied without anybody reading anything. The rate at which changes reach production entirely unread cannot. It is the one figure I would put on a wall. Context engineering is requirements gathering wearing a new hat The discipline is forty years old and we already know how to do it. What changed is not the skill, it is that the work moved from a phase at the start of a project to something that happens on every single ticket. The remediation market is coming. Do not be its customer. Gartner expects a market for auditing and refactoring AI-generated debt. The category will exist and it will be well funded. Most of what it sells is priced against a symptom by vendors with no reason to remove it. Entry-level postings fell 40%. That is a choice, not a trend. The drop gets reported the way weather gets reported, as something that happened to the industry. It is the sum of decisions taken by named people using a cost model that was wrong before agents arrived. Article 12 is a logging requirement your pipeline probably fails Most teams answer the traceability question by pointing at their observability stack. Debugging logs and traceability records are built to opposite specifications, and the substitution is where the failure hides. What review is for when the author cannot explain itself Code review was always half a conversation with a person who held the intent. Remove the person and most of the ritual stops working. What survives is narrower and more valuable than what we lost. Context blindness is the defining failure of 2026 Hallucination was the failure we prepared for. The one actually costing teams money is output that is internally flawless and incompatible with the repository it was written for, and no better model fixes it. Comprehension debt is worse than code debt Code debt makes change expensive. Comprehension debt makes change unsafe, and the real cost is not the hours you spend but the changes you quietly stop attempting. What to hire for when everyone ships fast Shipping speed has stopped being a differentiator between engineers because it stopped being scarce. The job description that still leads with it is selecting for the one input that got cheap. There is no provenance standard for generated code Generated images carry machine-readable marks. Generated code carries nothing. The instinct is to fix that by marking the code, and that instinct is wrong: provenance for software belongs to the change, not the artifact. A model reviewing a model is not verification Pointing a second model at the first one's output feels like a control. It is a filter with correlated blind spots, and the confidence it manufactures is the dangerous part. The spec is the artifact of record now For thirty years the code was the only document guaranteed to be true. That guarantee rested on a fact that no longer holds, which is that a person decided every line of it and could tell you why. Generated code is maintainable. Unread code is not. The claim that AI writes unmaintainable code confuses a property of an artefact with a relationship between an artefact and a reader. Maintainability was never in the file. Seniority is now a verification skill Most engineering ladders still promote on evidence of production, which is the one input that stopped being scarce. The senior work now is deciding what is true about a change nobody wrote by hand. Tamper-evident is a stronger word than teams realise Teams hear tamper-evident and think of storage settings. It is a claim about people: that someone with a motive to alter the record cannot do it without being caught. Almost no delivery pipeline can make that claim today. Merge on green is a policy. Choose it deliberately. Most teams already merge on green. They just have not admitted it, so nobody has decided what green needs to mean. Undeclared merge-on-green is the worst of both worlds. Who writes the spec decides who runs engineering Authority in software has always sat with whoever made the last irreversible decision. That used to be the person typing. It is moving to the person who wrote the criteria, and most organisations have not noticed they are reassigning power. Delete more than you think you can Writing code got cheap. Deleting it did not, and its value went up. Deletion is now the highest-return operation in a codebase and the one your organisation rewards least. The interview should measure reading The build exercise tests the one thing candidates no longer do alone. Replace it with a reading exercise: a real change, a real spec, and a decision to merge or not, defended out loud. Six months of retention is not an archive strategy A retention floor tells you when you may delete, not when you will be asked. Most of the questions that matter arrive well after month six, and by then the problem is not storage cost, it is that nobody can read what you kept. Trust in AI output fell to 29%. That is the correct direction. A falling trust number is usually read as an adoption problem to be managed. It is calibration improving. The real problem is that stated trust and actual behaviour are moving in opposite directions. Against prompt libraries Shared prompt collections look like reusable knowledge and behave like undocumented folklore. They store phrasing rather than intent, they cannot be tested, and they rot without anyone noticing. Sixty-one billion workdays is a number that means nothing Global technical debt estimates size a market. They cannot justify a single decision in your organisation, and a budget request built on one gets funded once and cancelled twice. Against the ten-x claim, in all its forms A tenfold productivity claim never names its denominator, which is what makes it unfalsifiable and useful to the person making it. The measurable truth is stranger: one stage collapsed and another got dramatically slower. What an auditor will actually ask about AI-written code Teams prepare an AI policy binder for an audit that will barely mention AI. The questions are the ones your change control has always answered. What changed is which of those answers is still true. Pickup time is the metric your dashboard is hiding The interval between a change being ready and a human first looking at it is where delivery time now accumulates. It is also the only number that measures whether your engineers are willing to open the diff. A spec a machine cannot check is a wish The test for an acceptance criterion is not whether a person agrees with it. It is whether anything could ever disagree with it. Most criteria fail that test, and the failure is invisible until the work comes back wrong. Craft when typing is free Craft has always been defended on moral grounds, and that argument loses every budget meeting. When generation costs almost nothing, the case for craft becomes a cost case, and it is much stronger than the aesthetic one ever was. Small teams, big blast radius A six-person team now ships at a volume that used to require sixty people, and it is doing it with none of the coordination machinery sixty people were forced to build. The risk profile changed. The controls did not. Compliance theatre starts where evidence stops Theatre is not caused by people being dishonest. It is what a control turns into when it stops producing an artifact, and you can find every instance of it in your own register in an afternoon. Against uniform review One review policy applied to every change is why review is collapsing. You already have tiers, set by whichever diff happened to look boring on a Thursday afternoon. The only real question is whether you chose them. Fifty percent fewer errors is a ceiling, not a floor The finding that human-refined specs cut errors by up to 50 percent is being sold as a promise. It is an upper bound under favourable conditions, and the half it does not touch is a different kind of error that no amount of specification will reach. The refactor that pays for itself thirty times The value of a refactor was always the saving per future touch multiplied by the number of future touches. Agents did not change the saving. They changed the multiplier, and that turns a small number of cleanups from indulgence into obvious spending. On-call for code nobody read Your time to restore will look fine while your incidents get structurally worse, because the median hides what is happening in the tail. Putting someone on a rota for a system nobody has read is a staffing decision, not a documentation problem. What "provable" actually requires Provable has four hard requirements, and most things sold as audit trails satisfy one of them. Reconstructed evidence is not evidence, and a log that can be edited without trace is a document rather than a record. The rubber stamp leaves no artifact A careful forty-minute review and a ninety-second scroll produce identical records in your system. No amount of analysis of approval data can separate them, which means the fix is not another metric. It is changing what a review emits. Your repository is the context, and it is a mess Teams argue about prompts and retrieval while the largest input to every agent run sits in git, unaudited. Your repository is a corpus of worked examples, and every abandoned pattern in it is a vote for doing the wrong thing. Consistency stopped being a preference Arguments about doing things one way used to be about taste, with a modest payoff in onboarding. Consistency is now a metered input cost, paid on every generation and every review, and the economics of the argument have completely inverted. The staff engineer who writes rules, not code The shift from writing implementations to writing constraints is real and mostly correct. It is also invisible to every measurement system your organisation runs, which is how good versions of this role quietly starve and bad versions quietly proliferate. High risk is a classification, not an adjective Teams use high risk as a feeling about anything involving AI, which simultaneously over-scopes their controls and hides the systems that genuinely carry obligations. Classification attaches to a system with a boundary, and most organisations cannot yet list theirs. The review comment that engages with nothing A nit about a variable name used to be harmless. On a generated pull request it is often the only recorded evidence anyone looked, and it certifies a review that did not happen. The unreviewed merge is not the worst category. Stop writing prompts. Start writing contracts. Prompt craft is a personal skill with no owner, no version, no review and no way to check whether it worked. A contract states what must be true when the work is done, which is the only artefact that survives the run that produced it. Against the AI debt panic A remediation market is being sold before most buyers have measured the problem. The panic buys the wrong thing: an audit produces a report, and a report is not the deliverable you need. The fix is a rate control you already own. Your org chart assumed a conversion rate that no longer holds Staffing ratios are a model with hidden assumptions: how many juniors become seniors, and how long it takes. Both inputs moved, the shape did not, and the first place you will notice is a mid-level band you cannot hire into. Your logs are self-reported, and that is the problem Almost every record of what an agent did was written by the agent or its harness. The actor is attesting to its own behaviour, which fails in exactly the case you built the record for. Derive evidence from artefacts the actor cannot rewrite. Your review SLA is making quality worse A four-hour review target puts a number on the one variable you should let float. There is always a way to hit the clock, it is called approving, and under agentic volume that is exactly what the target buys you. The agent that asks a question is worth ten that do not Every vendor benchmark rewards one-shot completion, so every agent is being tuned to guess rather than ask. That is the wrong optimisation, and the questions you are suppressing are the cheapest quality signal you will ever get. Your test suite now certifies the bug When the same interpretation produces the code and the tests, a wrong assumption does not just slip through. It gets a regression guard, a CI budget and a permanent defender. That is a liability with a recurring cost, and almost nobody accounts for it. Managers stopped being a bottleneck and became a constraint A bottleneck is a queue you can staff your way out of. A constraint is the thing that sets the safe rate of the whole system. Managers moved from one to the other, and most organisations are still applying the old fix. Segregation of duties survives contact with agents, barely Most implementations of segregation of duties check that two usernames differ. That test passes trivially once one person and one service account can author, test and approve a change. The control still works, but only if you re-anchor it from identity to authority. Blast radius beats diff size Every review process on earth triages by lines changed, because for thirty years lines changed was a decent proxy for effort and risk. Generation broke that proxy. What a change can reach now matters far more than how big it is. Specs rot faster than code Code has a compiler, a test suite and a production environment all pulling it toward truth. A specification has nothing. The difference never mattered much while humans read specs and silently corrected them. Agents read them literally. What the AI-native SDLC playbook gets right, and the layer it leaves out Anthropic has published a six-stage model for building software with agents. The diagnosis is correct and the artifacts are the best version of that idea anyone has shipped. Two things are missing, and both are load-bearing. The parts of this that get more expensive the longer you wait Most of what you will need for an agentic organisation can be added the day you need it. Two things cannot, and they are the two everybody defers. Here is why the order matters more than the timing.
Field guides
Practical guides for making a specific tool or process faster and more reliable, with and without any product of ours.
Linking Jira work to code, reliably How Jira's development panel actually gets filled in, the handful of ways the link silently fails, and how to get linking rate close to 100 percent without adding ceremony. Linking GitHub work to code, reliably Closing keywords, the development sidebar and Projects automation do more than most teams use. Here is how the link is really made, where it silently fails, and how to measure your own linking rate. Linking Azure DevOps work to code, reliably Azure DevOps can refuse to complete a pull request that has no work item attached. Here is how the linking actually works, when to turn that policy on, and what it still will not catch. Linking GitLab work to code, reliably GitLab links issues to merge requests better than any other combination on the market. Here is how the mechanism works, the four ways it still slips, and how to measure the gap. Linking Linear work to code, reliably Linear's git integration is the best-designed one on the market and it still leaks. Here is exactly how the branch-name link works, the four ways it breaks, and what to do about each. Linking Bitbucket work to code, reliably Bitbucket's link to your tracker is built from issue keys in branch names and commits. Here is what Cloud and Data Center each give you, where the link silently drops, and how to close the gap. Branch and PR conventions that survive contact with GitLab How to name branches and merge requests so GitLab links them to issues on its own, what its native referencing actually covers, and where the automatic link quietly stops working. Branch and PR conventions that survive contact with Linear Linear will move issues through your workflow on its own, but only for branches that carry the identifier. Here is how the matching actually works and how to catch the work it never sees. Branch and PR conventions that survive contact with Bitbucket Bitbucket and Jira will link your branches, commits and pull requests to issues automatically, if the key is present. Here is what the native linking covers, the account-mapping trap that silently breaks it, and how to check. Branch and PR conventions that survive contact with Asana Asana has no short issue key, so the usual branch naming advice does not apply. Here is what to link instead, how to mint a human-typable key if you really need one, and how to check it is working. How to measure your Jira linking rate A repeatable way to work out what share of your merged code actually connects to a Jira issue, including the key-matching traps that make the first number you get wrong. How to measure your Asana linking rate A repeatable way to find out what share of your merged code traces back to an Asana task, why the number is harder to get in Asana than in a ticket-key tracker, and what to do with the answer. Finding the work Jira never recorded Orphan work is invisible to JQL by definition, because there is no issue to query. Here is how to find it from the code side, classify it properly, and fix the causes rather than the symptom. Finding the work GitHub never recorded GitHub is a better witness than most teams give it credit for. The gaps are narrow and specific: work that bypassed the pull request, work in repositories nobody inventoried, and evidence that expired. Here is how to find all three. Finding the work Azure DevOps never recorded Azure DevOps has the strongest native lever of any tracker for preventing untracked work, and most teams have it switched off. Here is how to find what already slipped through, and how to stop the next lot. What Azure DevOps automation does, and exactly where it stops Azure DevOps has four separate automation surfaces and none of them is a general rules engine. Here is what each one is genuinely good at, and the exact point where you have to write code. What GitLab automation does, and exactly where it stops GitLab's answer to almost every automation question is a CI job, which is more powerful than a rule builder and much less convenient. Here is what that trade costs you, and the four places it genuinely runs out. What Linear automation does, and exactly where it stops Linear automates more out of the box than most trackers do after a month of configuration, and then offers almost nothing between that and writing GraphQL. Here is how to work with the missing middle rung. What Bitbucket automation does, and exactly where it stops Bitbucket never set out to be an automation platform, and understanding that saves you a week of looking for features that were never there. What it does have is enforcement at the merge, and that is the part worth using properly. Deriving status from source control instead of maintaining it in Bitbucket How to turn branch, pull request and deployment events in Bitbucket into a status your board can trust, and how to tell when the derivation has quietly stopped covering most of your work. Deriving status from source control instead of maintaining it in Asana A practical route to keeping Asana in step with what engineering is actually doing, starting with the identifier problem that makes Asana harder to automate than a developer tracker. Making "done" mean something in Jira How to move your definition of done out of a wiki page and into the Jira workflow itself, using status categories, transition conditions and validators rather than hope. Making "done" mean something in GitHub GitHub has no status called done, so teams silently adopt merged as a substitute. Here is how to build a real finish line out of required checks, linked issues and deployment records. Making "done" mean something in Azure DevOps Azure DevOps can already tell you which work items went into a given deployment. Here is how to wire states, branch policies and environments so that answer is trustworthy.
Topics that cut across the series
A piece often belongs to one series and several subjects. These lists are built from the titles and standfirsts, so they follow what the writing actually covers.
Agent behaviour (56)
- What agentic delivery changes in fintech and payments
- Proving what an agent did, six months later
- Review is the bottleneck. Adding reviewers will not fix it.
- What agents actually cost, per ticket
- What the Open Knowledge Format is, and why the ADLC needs one
- What we mean by the Agentic Development Life Cycle
Pull requests and merges (22)
Cost and attribution (19)
Audit and provenance (17)
Governance and policy (17)
Trackers (16)
Context and documentation (16)
Code review (14)
- Review is the bottleneck. Adding reviewers will not fix it.
- Code review: from gatekeeper to sampler
- What code review becomes when most code is generated
- Review fatigue and rubber-stamping at volume
- The zero-review merge is the only number that matters
- What review is for when the author cannot explain itself