Engineering · AIDLC
AIDLC
AI in software delivery is usually one of two things: banned, or ungoverned. Neither is a position you can put in front of an assessor. [Draft copy]
The problem
It is already in your delivery, whether or not it is in your policy.
Developers are using AI tooling now. In most organisations there is no statement of what may be sent to a model, no record of what came back, and no gate that says a human read it before it merged. The productivity gain is real and entirely unmeasured, which makes it impossible to defend when someone asks.
The exposure is not that AI wrote some code. It is that you cannot say which code, reviewed by whom, against what data, when a customer or a regulator asks.
What enterprise-grade looks like here
The same discipline you would apply to any other tool.
AIDLC is an AI-assisted development lifecycle: AI applied at design, build, test and documentation, with the same three properties every other part of your delivery needs — known inputs, reviewed outputs, and a record.
That means a stated boundary on what may leave your estate, generation that happens inside the pipeline rather than on a laptop, review in the merge request by a named person, and tests that assert the rules rather than restating the implementation. The point is not to slow it down. It is that governed AI can be defended, and ungoverned AI has to be stopped the first time anyone asks.
This framing repeats on every capability page. It is the differentiator, and it reads consistently across all of them (§9 T3).
What we do
Five moves, in this order.
-
Design
Requirements turned into specifications, domain models and acceptance criteria with AI assistance and human ownership. The specification is the artefact, and it is reviewed as one.
-
Build
Generation runs inside the pipeline against your own patterns, not from a general prompt. Output arrives as a merge request and is reviewed like any other contribution.
-
Test
Cases generated against the rules and the paths people forget — boundaries, empty states, permission edges. Coverage is a starting point for the conversation, not the goal.
-
Document
Technical documentation produced from the work as it happens rather than written up afterwards, which is the only version that stays true.
-
Govern
What may be sent to a model, what must be reviewed, what is retained, and where the record lives. Written down, and enforced in the pipeline rather than in a policy nobody opens.
[Draft copy]
What you end up owning
Documents and configuration, not a dependency.
| Deliverable | Owned by |
|---|---|
| A written AIDLC definition for your organisation | Engineering leadership |
| Data-handling boundary for model inputs | Security and legal |
| Review gates enforced in the pipeline | Engineering |
| Record of generated contributions and who accepted them | Risk & compliance |
| Measured baseline, so the change can be evidenced | Engineering leadership |
[Draft copy]
Tell us what you are being asked to prove.
Bring your current position on AI in development — including if that position is a ban.
Start a conversation