The Ferrari in the jungle: AI-driven software development in large enterprises

Like many people, I’ve been experimenting with AI for software development (AIFSD). It’s exciting and often dizzying — every week a new model drops, claiming to be faster, smarter and more efficient than the last; it feels like a perpetual game of catch-up.

Consequently, business expectations have shifted dramatically. Stakeholders now want work done in days, not months.

However, as I navigate large-scale transformation projects with these new tools, I’m finding that the reality isn't always as smooth as the demo videos suggest. AI is powerful, but it isn't magic. Based on my experience, the success of AI-driven development depends less on the model you use and more on two critical factors: your ways of working and your architecture complexity.

1. Ways of working: The car vs. the road

To understand why AI succeeds or fails, we need to look at the environment we put it in. Think of AI as a high-performance sports car — a Ferrari, say. It’s designed to go fast, but to do so it needs a smooth, paved road.

When AI works: The highway

AI thrives in environments where decision-making is rapid and collaborative. If you have key decision-makers - product owners, architects and developers together, AI can be a force multiplier.

For example, I’ve seen ideas converted to visual designs (like Figma) instantly using AI. If the product owner is there to validate it immediately, we can move to implementation in minutes. When business rules, technical architecture and design decisions are made and implemented in one go, a project that used to take months can arguably be done in days.

When AI struggles: The corporate jungle

Now, take that same Ferrari and drive it into a dense jungle. It doesn't matter how much horsepower the engine has; it’s not going anywhere.

This is the reality of legacy, bureaucratic environments.

• Approvals take forever: You generate code fast, but you wait weeks for sign-off.

• The alignment merry-go-round: Getting all parties aligned is a nightmare.

• The blame game over collaboration: When things go wrong, the focus shifts to liability rather than solutions.

In this corporate jungle, the speed of AI is nullified by the slowness of human process. You cannot speed up a project with AI if the bottleneck is an email waiting in an inbox for approval.

2. Architecture complexity: Context is king

The second major factor is technical architecture. There’s a common assumption that AI creates "modern" code, so it should work best with "modern" architectures. My experience suggests the opposite.

The challenge with distributed systems and complex legacy integrations

In large-scale transformation programs, we often favor distributed architectures — microservices and event-driven patterns — for scalability and security.

However, AI models struggle here. These architectures fragment the context of the application. The logic is scattered across dozens of services and repositories. An AI agent trying to implement a feature often lacks the holistic view required to connect the dots between Service A and Service B without hallucinating or breaking contracts.

Another big hurdle with leveraging AI into enterprise software development is primarily integrating with existing, often monolithic, legacy core systems. Key hurdles to integration include: Lack of clear, well-defined contracts, Absence of a comprehensive data dictionary: Business data meaning, format, and permissible values are scattered or only exist as "tribal knowledge." This ambiguity hinders AI models, which need structured api specification, leading to errors and lack of trust in AI driven software development.

The sweet spot of vibe coding: Monoliths and three tier architectures

Ironically, simpler architectural styles often yield better results with AIFSD.

Three tier Architectures and monoliths: Because application’s context is essentially located in one place with neatly defined boundaries, the AI can "read" the whole story. It understands how a change in the database schema impacts the frontend because it can see both files simultaneously.

Static sites vs. CMS: Similarly, AI performs exceptionally well with self-contained ecosystems like static corporate websites using JAMstack implementations, compared to complex, heavy Content Management Systems where logic is distributed across multiple layers.

Spec-driven development (SDD) is the key to building large complex systems 

Spec-driven development (SDD) provides the necessary structure to overcome the context fragmentation inherent in distributed architectures. By mandating the creation of explicit, machine-readable contracts (like OpenAPI/AsyncAPI specifications) before implementation begins, SDD ensures that every service has a clear, unambiguous definition of its expected inputs, outputs, and behavior. This pre-defined contract becomes the stable context that AI models desperately need to successfully generate, integrate, and maintain code across separate microservices or event streams without resorting to 'tribal knowledge' or introducing breaking changes. Explore spec-kit by Github or AI-DLC by AWS

In summary

While AI is revolutionizing software development, it’s also exposing some of the cracks in our organizations.

If you want to leverage AIFSD effectively, investing into models and tools is only the first step, you need to pave the road by streamlining your decision-making processes, and you might need to reconsider if your architectural complexity is an asset or a liability in the age of AI.

For large-scale transformation programs to effectively utilize AI in software development, it is crucial to break down distributed systems into smaller, manageable capabilities, components, or services followed by spec-driven development.

The Ferrari is ready — are the roads?