Your AI Platform Will Inherit Your Engineering Culture
AI adoption in software engineering has become one of the most active conversations in many organisations. The vocabulary changes from one discussion to another, but the ambition is usually recognisable: coding assistants, agent catalogues, AI marketplaces, prompt libraries, MCP server registries, internal developer platforms, orchestration layers, and governance structures meant to make all of this safe enough for enterprise use.
The ambition is understandable. Software delivery is difficult, and organisations are under pressure to move faster while improving quality, reducing repetitive work, documenting more consistently, testing more effectively, and keeping systems architecturally coherent as business expectations continue to change.
The problem is not the interest in AI. The problem is where the conversation often starts.
Too often, it starts with the visible artifacts — platforms, agents, marketplaces, productivity dashboards, governance boards — before the organisation has understood the engineering system those artifacts are meant to improve. The result is a familiar inversion: capabilities are catalogued before use cases are understood, governance is added after adoption has already started, and productivity is discussed without a clear picture of where time, quality, and ownership are actually lost.
That sequencing matters.
AI agents are not a shortcut around engineering discipline. They can amplify good engineering culture, but they cannot replace it.
The platform inherits the culture
There is a familiar echo of Conway’s Law in this topic.
Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
The idea is usually applied to software architecture: system boundaries often reflect team boundaries, communication paths, ownership models, and organisational structure.
AI platforms are no exception.
An AI platform does not arrive in a vacuum. It inherits the organisation’s communication patterns, decision-making habits, ownership model, incentives, standards, and blind spots. If the engineering culture is coherent, the platform can help reinforce that coherence. If the engineering culture is fragmented, the platform may simply make that fragmentation easier to reproduce.
This is why AI adoption in software engineering is not primarily a tooling question. It is an engineering culture question.
A company with unclear requirements, weak ownership, accidental architecture, inconsistent standards, shallow testing practices, poor feedback loops, and little agreement on what “good” looks like should not expect an AI platform to discover engineering discipline on its behalf. The platform will inherit what already exists.
That inheritance can be valuable. Where there are clear engineering standards, explicit architectural principles, known quality gates, healthy review practices, and a delivery model people understand, AI can make those practices easier to apply. It can reduce repetitive work, support new joiners, improve documentation workflows, assist with test design, and help teams preserve architectural consistency.
Where those foundations are missing, however, AI is more likely to create more output than more clarity.
More output is not better engineering
One of the easiest traps in AI adoption is confusing artifact generation with engineering improvement.
AI can generate stories, code, tests, diagrams, summaries, documentation, and review comments. Much of this can be useful. But a generated test suite is not automatically a good test suite, a generated architecture diagram is not automatically an architectural decision, and a generated implementation is not automatically the right solution to the right problem.
Software engineering is not merely the production of artifacts. It is the practice of making decisions under constraints: business goals, user needs, architecture, security, compliance, operability, maintainability, team capability, cost, delivery risk, and time. AI can support those decisions, but it does not remove the need to make them.
The signal should be visible in the engineering system itself: clearer requirements, earlier feedback, more relevant tests, less rework, better documentation, and more consistent architectural decisions. If those outcomes do not improve, the organisation may have adopted AI activity rather than AI-enabled engineering improvement.
This is also why the simplistic productivity narrative around developers is incomplete. Developers are not always slow because they cannot write code fast enough. Often they are slowed down by unclear requirements, changing priorities, missing product decisions, unstable architecture, inconsistent standards, fragile environments, and late feedback.
At the same time, developers should not be treated as passive victims of the system. They can also contribute to failure when they optimise locally, over-focus on technology, introduce unnecessary complexity, or lose the connection between the solution and the problem it is supposed to solve.
The better goal is not to make developers type faster. It is to improve the engineering system around them while helping them work more consistently within that system.
The photograph determines the camera
A good photographer does not start by randomly buying lenses and hoping that a meaningful image will eventually appear.
The intended photograph determines the lens, the camera body, the location, the timing, the light, and the setup. A portrait, a landscape, a sports photograph, and a night shot require different preparation. The equipment matters, but it matters because of the image the photographer wants to create.
AI adoption should work the same way.
The engineering outcome should determine the AI capability, not the other way around. Better requirements, stronger test design, more consistent documentation, and improved architectural compliance each imply different practices, different integrations, different constraints, and different measures of success.
Starting with a catalogue of agents and then searching for problems is the reverse of that process. It is like starting with a bag of camera equipment and hoping the photograph will define itself.
This does not mean platforms are unimportant. Integration, identity, security, cost control, observability, and developer experience all matter. But they should serve an engineering direction, not become a substitute for one.
Standards before scale
AI does not remove the need for engineering standards. It increases the return on having them.
This is one of the most important changes brought by AI-assisted development. Written engineering standards are no longer only for humans; they are also context for AI systems.
AI assistants are like junior developers with infinite energy but zero context.
Coding conventions, architectural principles, testing strategies, documentation expectations, pull request guidelines, security requirements, deployment rules, and operational practices all become more valuable when AI tools can use them. If a company has explicit architecture principles, AI can help review decisions against them. If test expectations are documented, AI can help generate more relevant test cases. If pull request quality criteria are clear, AI can help reviewers focus attention.
But if expectations are implicit, inconsistent, or purely tribal, AI has little stable ground to stand on.
This does not mean every organisation needs a heavy rulebook. Engineering standards should not become bureaucracy for its own sake. The goal is to make important expectations explicit enough to be taught, reused, checked, and improved.
AI adoption makes this more important because AI needs context. It needs to know what good looks like in this organisation, in this domain, in this architecture, under these constraints. A generic answer may be useful for exploration. Production engineering requires more than generic answers.
A marketplace is not a strategy
One common symptom of immature AI adoption is the tendency to place every AI-related asset onto one shelf.
A skill, an MCP server, and an agent may all appear in the same marketplace, but they are not the same kind of thing. A skill is a reusable capability. An MCP server is an integration point between AI-enabled tooling and external systems. An agent is a runtime that can plan, coordinate steps, call tools or skills, and work toward a goal.
These belong to different levels of the architecture. Flattening them into one undifferentiated catalogue creates confusion because ownership, risk, access, observability, cost, and governance are not the same for each of them.
A marketplace can be useful, but only when it is curated and connected to real engineering work. Without taxonomy, certification, ownership, and context, it can easily become another place where people have to guess what the organisation actually expects.
The useful question is not how many AI assets are available. It is whether those assets support meaningful engineering activities, reinforce agreed standards, have clear ownership, and can be measured against outcomes that matter.
Without those answers, a catalogue may look mature while still being operationally vague.
Start smaller, measure better
Many AI adoption initiatives begin with a broad promise of productivity improvement. That sounds reasonable until someone asks where productivity is actually lost.
The answer may be requirements churn, delayed architecture decisions, slow reviews, fragile test environments, manual releases, unclear ownership, repeated security findings, or missing documentation. These are different problems, and they do not all need the same AI intervention.
A coding assistant may help with implementation speed, but it will not fix unclear product direction. A documentation assistant may reduce writing effort, but it will not decide which knowledge should be documented. An architecture review agent may improve consistency, but only if the architecture principles are explicit. A test-generation skill may help create tests, but only if the organisation knows what kind of test coverage matters.
AI adoption without bottleneck analysis is solution-first architecture.
There is also a certain irony in some enterprise AI adoption programmes. They are often planned in the most non-iterative way possible: a large platform that will eventually serve everyone, include agents for many roles, integrate with many systems, and support a broad catalogue of capabilities.
Maybe one day it will.
But that is a risky starting point.
A better approach is more modest and more disciplined: define engineering standards, measure current bottlenecks, choose a few high-value use cases, run controlled pilots, measure quality outcomes rather than usage alone, and scale what works.
This is not a lack of ambition. It is a better path to ambition.
AI adoption usually matures from individual experimentation, through approved tool adoption, toward use-case alignment, standards-aware assistance, and measured engineering improvement. The important shift is from “Do we have AI?” to “Is AI improving the way we build software?”
Before creating an AI agent marketplace, an organisation should be able to answer a few basic questions:
- Which engineering bottleneck are we addressing?
- What standard should this AI capability reinforce?
- What does good output look like?
- Who owns and certifies the asset?
- Which systems and data may it access?
- How will quality be measured?
- Where must human judgement remain mandatory?
- What happens when the AI is wrong?
These questions are not meant to slow adoption down. They are meant to prevent shallow adoption from creating the illusion of progress.
The optimistic view
None of this is an argument against AI in software engineering.
Quite the opposite.
AI can make software engineering better. It can reduce repetitive work, help developers understand unfamiliar code, support better documentation, assist with test design, improve review workflows, make architectural knowledge easier to access, and help teams apply standards more consistently.
But the organisations that benefit most will not necessarily be the ones with the largest agent catalogue or the most ambitious platform diagram. They will be the ones that know how they want to build software, can express their engineering standards clearly, understand their bottlenecks honestly, and introduce AI capabilities where those capabilities reinforce better habits.
The platform is only the visible layer. The engineering culture underneath gives it direction.
AI agents are not a substitute for engineering discipline. They are most valuable when they help an organisation express, apply, and improve the discipline it has deliberately chosen to practice.
Used resources
- Melvin Conway
- DORA
- Martin Fowler
- Broken Robot