What enterprise AI can’t do for you (yet)

Companies are experimenting with AI to speed up development. (Image: BBD)

---

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.

The client needed a new, re-usable 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 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:

1. 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.

2. 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.

3. 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.

4. 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 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 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 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”.

• The most valuable asset isn’t the output, it’s the re-usable patterns the team builds over time.

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 that combine AI-native tooling, human engineering judgment, operational resilience, tight, cross-functional collaboration and disciplined enterprise integration.

This is the new frontier of enterprise software delivery and the teams that master it won’t just move faster, they’ll redefine what good looks like in financial systems for the next decade.

If you’d like to explore where AI could benefit your business, reach out to the team at BBD, or learn more about the work BBD is doing in the AI space here.