The real gap is coordination, not talent
A few years into the shift toward AI-assisted software work, the main obstacle for many engineering teams is no longer a shortage of skilled engineers. It is coordination: the absence of shared standards and a common language for how AI fits into everyday engineering tasks. Some teams have already moved past one-off experiments and built repeatable ways of working with AI, while others have stalled despite clear motivation. A frequent reason is that the cost of getting oriented has risen sharply. The landscape is crowded with tools and advice, and it is hard to tell what matters, where to begin, and what “good” looks like once production realities are taken into account.
The missing map
What is missing is a shared reference model — a map. Which engineering activities can AI responsibly support? What does quality mean for those outputs? What changes when part of a workflow becomes probabilistic rather than deterministic? And what guardrails keep the integration secure, observable, and accountable? Without that map, teams can mistake extensive experimentation for reliable integration, and those with the least time, budget, and local support tend to pay the highest price as the gap widens.
The same divide is now visible at the organizational level. Producing an impressive demo is easy; making AI-assisted work dependable under real constraints is far harder. That means measurable quality, controllable failure modes, explicit data limitations, clear operational ownership, and predictable cost and latency. Engineering discipline matters most precisely here: AI does not remove the need for it, it raises the cost of losing it.
A shared reference model: the AI Flower
One response to this gap is the AI Flower, a public capability architecture for AI-native engineering developed by engineering manager Juliette van der Laarse and presented at O’Reilly’s AI Codecon. It maps the core activities that make up engineering work across the main disciplines and, for each one, describes what “good” looks like in terms of practices that should already feel familiar to engineers. The aim is a shared scaffold that helps individuals, teams, and organizations adopt AI sustainably rather than through scattered, short-lived experiments.
How it is structured
The framework uses a flower metaphor: each petal represents an engineering topic, and within it sit the core engineering activities, best practices, learning resources, AI risks and considerations, and specific AI guidance for that activity. This activity-based view helps engineers see how AI can support familiar tasks, where risks are likely to arise, and how to start building practical experience — while keeping risks, trade-offs, and mitigations explicit rather than implied.
Looking beyond today’s tools
An activity map of current practice is a useful starting point but not a complete long-term model. As AI capabilities advance, many engineering activities will become more abstract, more automated, or absorbed into the infrastructure layer. Engineers will therefore need to do more than learn how to apply AI to today’s operations; they will also need to work with emerging approaches such as context engineering and agentic workflows, which are already reshaping what counts as core engineering work. A companion idea, described as a skill-fossilization model, captures how engineering and AI-related skills evolve over time and how some become less visible as work moves to higher levels of abstraction.
An open, evolving framework
The AI Flower is offered as an open and freely available framework rather than a finished standard. By design it is intended to be tested, challenged, and improved by the wider community, on the premise that a shared scaffold is only valuable if practitioners refine it against their own production realities. Organizations interested in the operational controls that complement this kind of capability model may also find this overview of enterprise AI governance systems relevant.
Limitations and what to watch
A reference model is a guide, not a guarantee. Frameworks like this describe what good practice looks like but cannot enforce it, and their value depends on teams adapting them to a specific context rather than adopting them wholesale. Because the AI landscape changes quickly, any fixed map risks dating, which is part of why the framework is positioned as community-maintained. It is best treated as shared vocabulary and a checklist for coordination, used alongside concrete measures of quality, security, and cost rather than as a substitute for them.
