Why engineering discipline still determines whether AI projects succeed, and what we learnt from a recent accelerated delivery programme.
AI promised to rewrite the rules of software delivery, but the reality is more complicated.
Across the industry, organisations are experimenting with AI to speed up development. Some are seeing remarkable gains, compressing months of work into weeks. Others are discovering that acceleration without discipline simply creates bad code, bad assumptions, and bigger problems later.
For executives, the real question is no longer whether AI can accelerate delivery, but whether it can do so reliably, repeatedly and at enterprise scale.
A recent project we delivered with a major financial institution offered a real-world look at the truth behind the hype. It showed us what AI can accelerate, what it can’t, and why foundational engineering thinking matters now more than ever.
A real example: Eight months of work delivered in three weeks
The client needed a new, reusable payments component, something relative in size that normally takes an engineering squad eight months to design and deliver due to complex requirements, heavy integration with national infrastructure, and cross-functional review cycles.
Together, we proposed an experiment: Could we deliver the full set of artefacts — architecture, design, interfaces, test plans, automation scripts, and engineering boards — using AI across the entire SDLC?
In under three weeks, the answer was yes.
In a month, the project was nearing development completeness and ready for operationalisation aspects to commence.
AI didn’t just speed up coding; it accelerated the thinking work.
But acceleration alone doesn’t equal readiness, and that became very clear very quickly.
The magic and mess of using AI across the SDLC
The headline gains came from:
- AI-assisted architecture using structured prompting to turn a standard BRS into a technical specs ready for engineers
- Design, sequence flows and integration patterns drafted in minutes rather than days
- Test plans and automation scaffolding generated rapidly once constraints were properly defined
- Parallelised collaboration where product, engineering, testing and architecture prompted the AI simultaneously; once we realised each needed its own context-specific thread
But the hard lessons were equally important:
- AI only gives you what you ask for — not what you should have asked
Where a senior architect instinctively considers scale, patterns, domain realities, and future constraints, AI only reflects the input it receives. The result: impressive drafts with critical gaps.
- Prompt engineering becomes a specialist skill
Our senior Scrum Master and BA quickly became power users. Our juniors picked it up fastest although they couldn’t always distinguish the gold from the nonsense. Basically, experience still matters.
- Verification took us from 20% accuracy to ~80%
Most outputs weren’t wrong, they were incomplete. We had to teach the AI to consider edge cases, regulatory context, architectural constraints and volume projections. We could not teach AI any client-specific context.
- AI accelerates creation. Humans still prevent disaster.
Building the thing was quick. Integrating it into the enterprise (billing, security, observability, failover, deployment patterns) is where AI still can’t be trusted.
AI can definitely help you move faster, but it can also help you make bigger mistakes faster if senior oversight isn’t in place.
The uncomfortable truth: AI gets you the first 80% fast… and the last 20% is still 80% of the work…
The component was “built” in a month. It will still take roughly five more to turn it into a production-ready service used across the business. Why? Because enterprise engineering is more than code.
- Governance
- Integration
- Security
- Observability
- Billing
- Deployment
- Maintainability
- Rollout
- Training
- Ownership models
AI will help with some of this, but it won’t replace engineers who know how to design for scale in context of the organisation, testers who know how to break things creatively, or architects who understand what “sixfold volume growth” actually means for a system.
The constraints of real financial environments with compliance, risk, oversight, stability and risk at the forefront of importance simply cannot be shortcut with automation.
The delivery model that actually works
The biggest breakthrough wasn’t the AI. It was the JAM sessions: getting every accountable stakeholder (product, engineering, business, testing, architecture) in one room, full-time, for days.
It eliminated:
- slow handovers
- misaligned expectations
- repeated reviews
- design drift
- context loss
Add AI into that environment, and you get a force multiplier.
The future: AI-native, enterprise-literate engineering teams
The project sparked other similar initiatives inside the organisation. Not because the AI was impressive, but because the process was.
We learnt that:
- AI-native delivery is a skill
- Engineering thinking matters more, not less
- The biggest risk isn’t hallucination — it’s overconfidence
- The winners will be teams who know how to prompt and when to override
- Juniors will accelerate fast, but they need seniors who can separate “possible” from “foolish”
- And the most valuable asset isn’t the output, it’s the reusable patterns the team builds over time
AI won’t replace engineers. It will replace slow delivery.
The promise of enterprise AI is real. But without the right architecture, the right delivery model, and the right people, it just creates faster fragmentation.
The organisations that will win aren’t the ones generating the most code. They’re the ones who combine AI-native tooling, human engineering judgement, operational resilience, tight, cross-functional collaboration, and disciplined enterprise integration.
This is the new frontier of enterprise software delivery and the teams who master it won’t just move faster; they’ll redefine what good looks like in financial systems for the next decade.
Explore more about BBD’s AI services.
