Governance and value
More code and pilots are mistaken for business value while ownership and do-not-build choices remain implicit.
Renew critical software without making the rebuild itself your biggest risk.
Fourlab first determines what you can retain, what still needs evidence and which smallest intervention is defensible. AI then accelerates selected work while scope, quality, security, ownership and release decisions remain explicit.
Do not turn a rebuild into an irreversible project promise.
You do not need to know yet whether a rebuild is necessary. That is the first decision Fourlab helps substantiate.
- Releases are becoming riskier because of legacy, hidden dependencies or unclear ownership.
- An AI prototype is convincing, but exceptions, integrations, security and operations remain unproven.
- A full rebuild is on the table without sufficient evidence for that all-or-nothing choice.
- AI output is growing faster than review, QA, security or operations capacity can handle.
First, a decision you can defend. Only then, delivery.
- Pathfinder Signal · 4 minutes: Initial risk direction, recommended route and a shareable internal memo.
- Pathfinder Scan · 2–3 weeks: Decision document, risk and dependency map, evidence register and roadmap.
- Focused delivery: Focused Build Sprint or controlled rebuild after an evidence-backed go decision.
Anonymised project story · healthcare platform rebuild
From one large rebuild plan to a series of defensible choices.
- Situation
- The existing healthcare platform was becoming restrictive; a full rebuild felt too large and risky.
- Engagement boundary
- First establish what was certain, what remained unknown and what the first step needed to prove.
- Delivered
- A decision-ready narrative, open-question list, clear first route and approach to handover.
Thought leadership · Fourlab ADLC · July 2026
The market is not going back. It is growing up.
The next phase of AI is not only about possibility, but about accountability, cost, risk, understanding and production. AI does not create messy processes, fragmented data, weak decisions or unclear ownership; it exposes that existing organisational debt faster and amplifies the consequences.
Code is becoming abundant. Demonstrable trust is becoming scarce.
A fast demo is not yet production-ready software.
Fourlab ADLC makes value, ownership, security evidence and release readiness testable before the organisation proceeds.
Eight risk zones a convincing demo does not reveal
Context and assumptions
Agents confidently fill gaps in domain knowledge, weak sources and product decisions; generated errors can then circulate as sources.
Prototype and architecture
A happy flow does not prove scalability, integrations, access rights, exceptions or maintainability.
Security and review
Late security, blind trust or unprioritised findings create the appearance of control.
Review capacity
Generation can grow faster than architecture, QA, security and operations can responsibly assess.
Understanding and craft
Comprehension debt, session or person dependency, knowledge loss and an eroding junior-to-senior path threaten ownership.
Cost and dependency
Token burn, model selection, cost allocation and provider lock-in affect the business case and continuity; compute use and any environmental impact are considered where relevant and measurable.
Release, liability and trust
A green pipeline can hide artifact drift, missing rollback, unbounded recovery, reputational damage or an operational vacuum.
This is not an anti-AI story. The relevant distinction is controlled versus uncontrolled; evidence determines trust.
Three execution loops. One continuous control layer.
- Value Loop: Do we know what is valuable, for whom and why?
- Request Loop: Is the request clear, bounded, accepted and owned?
- Delivery Loop: Is it demonstrably built, tested, accepted and operationally manageable?
The three loops govern the work, the seven steps describe the client journey and the verified decision chain shows which evidence each step leaves behind.
Continuous Assurance covers governance, security, quality, ownership and release readiness across all loops.
Seven steps to controlled software
- Direction
- Pathfinder
- Product definition
- Delivery baseline
- Agentic build
- Acceptance
- Continuity
Not a piece of code, but a verified decision chain
- Source and context
- Choice
- Execution
- Verification
- Authorised decision
- Operational result
What you can see throughout the engagement
- Scope, exclusions and ownership
- Product, architecture and security decisions
- Acceptance criteria and test results
- Release and rollback evidence
- Operations readiness and monitoring
- Runbooks, documentation and handover
Agents accelerate. People decide.
Authorised people retain the decision rights over value, budget, scope, material risk, acceptance and production release. Evidence determines whether delivery may continue.
Twelve questions every AI-enabled organisation should answer
- Who is ultimately accountable for software created largely with AI?
- Which criteria determine whether an AI demo is production-ready?
- Can we prove requirements, tests, reviews and security controls for every release?
- Do we know which AI projects, models and costs are active?
- Can review, QA, security and operations capacity handle the higher output?
- Can we safely roll back and identify the exact live artifact?
- Does our own team understand the software well enough to maintain and repair it?
- What happens when a model disappears, becomes more expensive or changes behaviour?
- Which decisions may agents take and which require human approval?
- Is operations demonstrably ready before a solution goes live?
- How will new professionals learn to assess complex systems and AI output?
- Which metrics prove value rather than merely more output?
If several answers are missing, the organisation probably needs a better operating model, not more AI tooling.
From technical control to executive confidence
ADLC makes software delivery decidable for the people who must carry value, product, technology, risk and operations.
- Leadership
- Product
- Engineering
- Security, risk and compliance
- Operations
We first determine what should be retained, repaired, replaced or stopped.
The smallest defensible intervention may also be configuration, training, process improvement, additional support or a smaller experiment — without new build scope.
Focused Build Sprint
Typically 6–10 weeks for one critical flow or component.
(Re)build / Replacement Project
Typically 3–9 months with migration, acceptance, release and handover.
Frequently asked questions about Fourlab ADLC
Does ADLC replace the normal Software Development Lifecycle?
No. ADLC adds controlled agentic execution, evidence and explicit decision rights to professional software engineering.
Does AI decide whether software may go to production?
No. Agents can perform controls and prepare evidence. Authorised people decide on value, material risk, acceptance and production release.
Does ADLC make software delivery slower or more bureaucratic?
ADLC does not add control for its own sake. Assurance follows scope and risk. The route visibly stops only when context, evidence, review capacity or an authorised decision is missing.
Is AI-generated code unsafe by definition?
No. Quality depends on demonstrable requirements, architecture, tests, review, security controls and open risks, not on who or what wrote the code.
Why is “human in the loop” not enough?
A person without time, context, authority or the right evidence is not an effective control. ADLC defines decision rights, required evidence and the route after rejection.
Does a legacy system automatically require a rebuild?
No. Fourlab first investigates what should be retained, stabilised, improved, replaced or stopped.
How do you address model costs and provider dependency?
Where relevant, model selection, usage cost, value, evaluation baselines, fallback and portability become explicit product and continuity decisions.
What happens when a gate or acceptance control fails?
The route moves to bounded repair, reassessment, a scope change, explicit risk acceptance by the authorised owner or a hold/no-go.
Can we see how the outcome was produced?
You receive project-specific scope, relevant decisions, acceptance and release evidence, documentation, runbooks and handover agreements. This keeps the result reviewable, operable and transferable without exposing our internal execution details.
Which source code and data may reach AI tools?
The delivery baseline defines which context, systems and data are necessary and permitted for each step, supported by project-specific privacy, security and contractual agreements.
Can our own team or another supplier take over later?
Transferability is designed through documentation, tests, runbooks, ownership and knowledge transfer. Exact repository, licence and handover rights are defined in the contract set.
Make the next decision smaller before the project becomes larger.
Share your build/rebuild context · Start the 4-minute Signal