Workflows · Engineering

Engineering: Workflows

What arrives, what ships, the eight-stage path from architect to monitoring, and the handoff contracts with the PMO, QA, Security, AI Engineering and Support.

Markdown. No sign-up, no email.

Eight stages, two of which are human and six of which are not. The shape matters more than the tooling: a person decides at the front, a person is accountable at the back, and everything between is allowed to stop the change.

What arrives#

FromWhatBecomes
PMOA prioritised change, with an ownerWork, once the requirement is testable
ProductA requirementAn architecture question, if it touches a contract
SupportA defectA reproduction, then a test, then a fix. In that order
SecurityA findingEither a fix now, or a recorded accepted risk with a date
AI Engineering and ProductThe behaviour inside an AI featureAn interface contract, not an implementation
MonitoringA regression signalAn incident or a ticket, depending on severity

A defect becomes a reproduction before it becomes a fix. A fix without a reproduction is a change that correlates with the symptom disappearing, which is not the same thing and is discovered to be different at the worst possible moment.

What ships#

ToWhat
ProductionWorking software, behind gates that all passed
Knowledge ManagementArchitecture decision records, including the rejected options
SecurityScan results and any accepted risks, dated
SupportRelease notes written from the diff
PMODelivery status measured in production, not in merged branches

The eight stages#

StageWhoCan it stop the change?
Architecture decisionHumanYes, and it is the cheapest place to stop one
Coding agentAgentYes, by refusing an ambiguous requirement
AI code reviewAgentYes
Automated testingAgentYes
Security scanAgentYes
CI/CDAutomatedYes
Production acceptanceHumanYes
AI monitoringAgentRaises, does not stop. By then it is a rollback decision

Six of the eight can stop a change and only two of those are human. That is the intended shape: stopping should be cheap and frequent, deciding should be rare and attributed.

Handoff contracts#

From the PMO. Work arrives with an owner and a testable requirement. "Make it better" is not a requirement, and accepting one produces a change nobody can review, because there is nothing to review it against.

To QA. Everything deterministic. Anything measured against a distribution belongs to AI Engineering and Product. Mixing them gives you either untested AI features or an engineering team asked to certify something it has no method for.

With Security. Findings raised on every commit, closed jointly, never closed by the agent that raised them. An accepted risk is written down with a date and an owner, not left implied.

To Support. Release notes from the diff before the deploy lands, so the first person to hear about a change is not a customer describing it.

Cadence#

Per changeAll eight stages. No exemption for small changes, which cause most incidents by skipping steps
DailyDeploys, unplanned work
MonthlyGate audit: what fired, what was bypassed, what escaped
QuarterlyArchitecture review and technical debt

The failure this design is built against#

An organisation adopts AI coding, output triples, review stays where it was, and six months later nobody understands the system well enough to change it safely. Nothing looks wrong at any point along the way, because the delivery numbers improve the entire time.

Every element here, the human decision at the front, six gates that are allowed to stop things, the review-depth counter-metric, and a monthly audit that asks which gate has stopped nothing, exists to make that outcome visible while it is still cheap to correct.

Back to Engineering

Get new material when it is published

Everything here is free and stays free. There is no form in front of any document. If you want to know when new guides and templates go up, leave an email.

Roughly monthly. Unsubscribe in one click. We do not share your address, and we will not call you.