AI Amplifies Organizational Strengths and Weaknesses.
What years of building a unified enterprise platform taught me about the real foundations of AI productivity.
One of the more interesting things I’ve learned about AI is that its effectiveness has surprisingly little to do with how quickly an organization adopts it.
AI is an amplifier. It makes strong engineering practices more powerful and weak ones more expensive. It accelerates consistency where consistency exists, and multiplies fragmentation where it doesn’t.
I didn’t arrive at this conclusion through an AI transformation initiative. I arrived at it through years of work solving a very different problem: bringing multiple enterprise consoles together into one consistent customer experience.
Like many enterprise software companies, we had accumulated different consoles over time. Each served a purpose. Each had evolved with its own design patterns, technology decisions, services, and delivery practices. Individually, many of those decisions made sense. Collectively, they created an experience where customers had to navigate the boundaries of our internal organization structure in the product to get their work done.
A customer shouldn’t have to understand which team built a feature, which backend powers it, or why two workflows in the same product behave differently.
That became our starting point.
We wanted to build a unified experience that was intuitive and consistent, but also one that could evolve as the business grew. And we quickly learned that unifying the user experience required much more than unifying the interface.
Consistency is much harder than it looks
We began by investing in a design system.
Design systems are often confused with component libraries. Build a reusable button, a table, a modal, publish them somewhere, and suddenly everyone has a design system.
A good friend and former design system design lead would often remind me that a design system is much more than that.
It begins with design principles and UX research. Those principles translate into design foundations and tokens, then into atoms, molecules, and organisms that form reusable experience patterns. But the components are only one part of the system.
There is code, of course, but also specifications, guidelines, dos and don’ts, accessibility standards, and documentation that serves as a single source of truth for both designers and engineers, and now agents. And there is telemetry — understanding how components are actually used so the system can continue to evolve based on evidence rather than assumptions.
The real objective was to create a shared language for designing and building experiences.
When teams share that language, consistency becomes a property of the system rather than something that has to be negotiated with every new feature.
But we also discovered that a consistent interface sitting on top of inconsistent engineering foundations could only take us so far.
But a consistent user experience couldn’t be achieved through a design system alone. We needed an equally consistent engineering foundation behind it, with clear layers of abstraction that allowed teams to build features without repeatedly solving the same underlying problems.
At the service and data layer, we introduced common services and canonical object models that abstracted the differences across disparate backend systems. Instead of every feature having to understand different APIs, data structures, authentication mechanisms, and error-handling conventions, the platform provided consistent contracts for accessing and manipulating resources. This allowed the user experience to remain consistent even when the underlying systems weren’t.
At the application layer, we standardized the frontend framework, application shell, navigation, routing, state management, and shared UI patterns. A common content management system provided a consistent way to manage contextual help, documentation, and other content across experiences. Teams could focus on building customer-facing workflows rather than assembling the foundational pieces of an application every time.
At the infrastructure and developer platform layer, we established shared environments, infrastructure provisioning patterns, build tooling, dependency management, observability, and deployment conventions. This reduced the number of technology choices individual teams had to make and created a predictable path from local development to production.
At the delivery and quality layer, common CI/CD pipelines and automated testing frameworks standardized how changes were built, validated, and released. Unit, integration, accessibility, and end-to-end testing could be incorporated into shared quality gates, making it easier to detect regressions early and maintain consistent expectations for performance, reliability, and security.
These weren’t simply technology choices. Together, they formed an operating model that made the right way to build software the easiest way to build it. Teams could reuse proven foundations, inherit quality and operational practices, and concentrate their effort on solving customer problems.
And that distinction became particularly important when AI arrived. We hadn’t just standardized the components engineers used. We had standardized the contracts, patterns, workflows, and guardrails that defined how software was built. AI could now operate within those same boundaries instead of inventing its own implementation decisions for every feature.
This was as much an operating model transformation as a platform transformation.
We were establishing how teams would build, test, deploy, and support software without having to solve the same underlying problems repeatedly.
None of this happened overnight. Standardization takes time, particularly when teams have legitimate reasons for the decisions they’ve made independently. It requires making the shared path easier than creating another local solution.
But the payoff was important.
Teams could spend less time rebuilding foundations and more time solving customer problems. And customers could experience the product as one coherent system instead of a reflection of how we happened to be organized internally.
At that point, AI wasn’t the reason we were doing any of this.
We were simply trying to build a better product and a more effective engineering organization.
Then AI arrived at exactly the right time
By the time AI coding tools became reliable enough for meaningful engineering workflows, we were preparing to rebuild features built over fifteen years onto the new platform with the new platform.
It was a significant migration, with a great deal of repetitive implementation work.
And suddenly, the foundations we’d spent years building had an entirely new consumer.
AI.
What made this interesting wasn’t simply that AI could generate code. It was that AI had very little reason to guess.
We already had documented design patterns, reusable components, specifications, accessibility guidelines, established engineering conventions, and testing frameworks.
For every component, there was a source of truth.
The AI skills files we began using were essentially another expression of specifications we’d already developed for humans. They made our existing conventions explicit and consumable by AI.
We weren’t teaching AI to invent our product. We were giving it the context to implement our established product patterns predictably.
This distinction matters more than it might initially appear.
When an engineer joins a well-run platform organization, they benefit from documentation, conventions, shared services, and examples of how things should be done. They don’t have to rediscover every architectural decision.
AI benefits from exactly the same foundations.
The difference is that AI can consume and apply those patterns across a much larger volume of repetitive work.
Our investment in consistency had suddenly acquired a multiplier.
And that led me to a realization: the organizations best positioned to benefit from AI may not be the ones investing most aggressively in AI itself. They may be the ones that have already invested in making their engineering practices consistent, explicit, and repeatable.
Because the opposite is equally true.
Imagine introducing AI into an organization where every team uses different frameworks, maintains its own components, follows different testing conventions, and relies on undocumented decisions.
AI will still generate code.
But which patterns should it follow? Which implementation is correct? Which conventions are authoritative?
Without clear answers, AI has to infer or invent them. The resulting code may look reasonable while introducing yet another variation that someone will eventually have to maintain.
The more inconsistent the environment, the less predictable the output.
AI doesn’t resolve that fragmentation simply by producing code faster. It can reproduce it at a scale that makes the underlying problem harder to manage.
Our experience with the platform showed us how much consistency could improve AI’s effectiveness.
But it also exposed a weakness we hadn’t fully addressed.
We had standardized how to build. Had we standardized how to think about what to build?
As we began using AI more extensively, we discovered that even the strongest engineering foundations couldn’t compensate for an unclear problem statement.
We had requirements documents that sometimes looked more like blueprints for wireframes than descriptions of customer problems.
They explained which screens to build, what fields to display, and where buttons should go.
But they didn’t always explain what the customer was trying to accomplish, why the existing experience was insufficient, or what a successful outcome should look like.
Humans had been compensating for this ambiguity for years.
Get Ayesha Mahmood’s stories in your inbox
Join Medium for free to get updates from this writer.
Engineers would ask questions, make assumptions, consult colleagues, and use their understanding of the product to fill in the gaps. Sometimes those assumptions were correct. Sometimes we discovered much later that we’d solved the wrong problem.
AI made this weakness impossible to ignore.
Give AI a precise implementation specification and it can produce an implementation remarkably quickly. But give it a poorly understood customer problem disguised as a set of UI instructions, and it can just as efficiently build something that misses the point.
A perfectly implemented feature is still the wrong feature if it doesn’t solve the customer’s problem.
We had spent years creating a single source of truth for how software should be built. Now we needed to be equally disciplined about defining why it should be built and what outcome it needed to achieve.
That required more investment upfront.
Clearer problem statements. Better context. More thoughtful requirements. Explicit acceptance criteria.
And this is where our expectations of AI productivity encountered reality.
Faster code didn’t immediately mean faster delivery
Like many teams adopting AI coding tools, we initially measured how much code AI generated and how much of it was committed.
It was an easy metric to capture, and the numbers could be impressive.
But we quickly realized that lines of code were telling us very little about whether we were becoming more productive.
We had never defined engineering success by the volume of code written. Why would we start now?
The metrics that mattered hadn’t changed.
Quality and velocity.
Quality meant performance, regressions, defects, and production incidents. Velocity meant how quickly we could deliver valuable capabilities to customers.
If AI was truly transformative, the aspiration should be simple: ship high-quality software at machine speed.
But when we looked at our delivery velocity, something surprising emerged.
It hadn’t dramatically increased.
The time AI saved during implementation was being absorbed by work we hadn’t always done thoroughly before: defining the problem, clarifying requirements, and making expectations explicit.
In other words, AI made us confront the cost of ambiguity earlier in the development lifecycle.
At first, that might sound like a disappointing productivity outcome. AI could generate code much faster, yet the overall delivery timeline hadn’t changed substantially.
But there was another side to the story.
The time we spent fixing broken things in production was decreasing.
And that changed how we thought about productivity.
When teams rush into implementation with incomplete requirements, the missing work doesn’t disappear. It shows up later as rework, defects, regressions, and production incidents.
We had become accustomed to treating much of that effort as a normal part of software development.
AI was forcing us to move some of that effort earlier, when problems were cheaper to identify and correct.
So while initial delivery velocity remained relatively stable, the total cost of delivering and sustaining a feature was improving.
Less rework. Fewer downstream fixes. More predictable quality.
Over the full lifecycle, that translates into a net gain in velocity.
It also raises a more fundamental question: what exactly should we be measuring when we talk about AI productivity?
If an engineer generates thousands of lines of code in minutes but spends days correcting the implementation, what did we gain?
If another engineer spends more time clarifying the problem, uses AI to implement a well-defined solution, and ships it with fewer defects and less production support, which one was more productive?
The answer seems obvious when framed this way.
Yet much of the conversation about AI productivity still focuses on how quickly we can produce artifacts rather than how effectively we can deliver outcomes.
AI is changing the cost of implementation. It shouldn’t change our definition of engineering success.
The real advantage was built before AI.
Looking back, what stands out to me isn’t how much we changed our engineering operating model to accommodate AI.
It’s how much of that operating model was already in place.
We had invested in design principles, shared components, consistent services, common infrastructure, automated testing, and documentation because they helped humans build better software.
Those investments reduced duplication, improved quality, and made it easier for teams to deliver a consistent customer experience.
AI arrived and amplified their value.
At the same time, it exposed the places where we had relied too heavily on implicit knowledge, incomplete requirements, and assumptions that experienced engineers could work around.
It amplified those weaknesses too.
And I think this is the part of the AI conversation that deserves more attention from enterprise leaders.
We’re asking how quickly organizations can adopt AI, how many developers are using it, how much code it generates, and how many hours it saves.
But perhaps the more important question is what AI is being asked to amplify.
If your architecture is fragmented, AI can generate fragmentation faster.
If your engineering practices are inconsistent, AI can reproduce that inconsistency at scale.
If your requirements are unclear, AI can accelerate the delivery of the wrong solution.
And if your productivity metrics reward output rather than customer outcomes, AI can make those metrics look extraordinary without creating equivalent value.
But when the foundations are strong — when design intent is documented, architectural decisions are explicit, engineering practices are consistent, and customer problems are clearly understood — AI can turn those foundations into extraordinary leverage.
The lesson for me wasn’t that every organization needs to rebuild its platform before adopting AI.
It was that AI makes the quality of your existing operating model matter more, not less.
The best AI strategy may begin with some very familiar engineering and product questions.
Are we building consistently? Do our teams have a reliable source of truth? Are we solving clearly understood customer problems? Can we measure the quality and value of what we ship?
These were important questions before AI.
Now the consequences of getting them right, or wrong, are multiplied.
We began our journey trying to prevent customers from having to navigate our organizational complexity.
We ended up building a foundation that allowed AI to navigate our engineering complexity with far greater predictability.
That wasn’t the original plan.
But perhaps that’s the most useful lesson of all.
AI doesn’t create organizational excellence. It reveals it, amplifies it, and makes the absence of it increasingly difficult to hide.
I didn’t include the people leadership part of the problem in this article because that is a whole separate article on how AI amplified misalignemnt, egos, conflict of interest, and why constructive incentive structures matter in an organization’s culture.
