Just a few years into the AI transformation, there is no longer a talent gap among engineers. This is coordination: shared standards and a shared language for how AI fits into everyday engineering tasks. Some teams are already getting real value. They have moved beyond one-off experiments and started creating repeatable ways of working with AI. Others have not done so even when the motivation was present. The reason is often simple: The cost of orientation has exploded. The landscape is filled with tools and advice, and it’s hard to know what matters, where to start, and what “good” looks like once you’ve taken care of production realities.
missing map
What is missing is a shared reference model. No other equipment. Map. What engineering activities can AI responsibly support? What does quality mean for those outputs? What changes when part of the workflow becomes probabilistic? And what guardrails keep the integration secure, observable, and accountable? Without that map, it’s easy to get lost in the newness, and confuse extensive experimentation with reliable integration. Teams with the least time, budget, and local support pay the highest prices, and the gap widens.
That difference is now visible at the organizational level. More organizations are trying to turn AI into business value, and the gap between promotion and integration is visible in practice. It’s easy to send impressive demos. It is very difficult to make AI-assisted work reliable under real-world constraints: measurable quality, controllable failure modes, explicit data limitations, operational ownership, and predictable costs and latency. This is where the engineering discipline matters most. AI does not remove the need for this; This increases the cost of losing it. The question is how we move from scattered experimentation to integrated practice without burning out cycles of tool churn. To do this at scale, we need shared scaffolding: a public model and shared language for what “good” looks like in AI-native engineering.
We’ve seen before why this kind of shared scaffolding matters. In the early Internet era, promises and noise moved faster than standards and shared practice. What made the Internet sustainable was not a single vendor or methodology but a cultural infrastructure: open knowledge sharing, global collaboration, and a shared language that made practices comparable and learnable. AI-native engineering requires the same kind of cultural infrastructure, as integration only grows when the industry can coordinate on the meaning of “good.” AI does not remove the need for careful engineering. On the contrary, it punishes its absence.
A public platform for AI-native engineering
In the second half of 2025, I started to notice a growing restlessness among engineers and friends who work in IT. There was a clear understanding that AI would profoundly change the way we work, but little clarity on what it actually meant for an individual’s roles, skills, and daily practice. There was no shortage of training, guides, blogs, or tools, but the more resources emerged, the more difficult it became to decide what was relevant, what was useful, and where to start. It seemed heavy. How do you know which topics really matter to you when suddenly everything is labeled AI? How do you move from promotion to useful integration?
I myself was feeling a lot of the same uncertainty. I was also trying to understand the change, and for some time I think I was waiting for a clear structure to emerge from somewhere. When my friends started coming to me for help and guidance I realized I might have something worthwhile to contribute. I don’t consider myself an AI expert. I, like many other engineers, am finding my way through these changes. But over the years, I have become known for my work in IT workforce development, skills and capability frameworks, and engineering excellence and enablement. I know how to help people deal with complexity in practical and sustainable ways, and I enjoy bringing clarity to chaos.
This is what inspired me to start working on AI Flower as a hobby project in early October 2025, building on frameworks and methods I already had experience with.
When I started sharing it with friends in IT to gather feedback, I saw how much of an impact it had. This helped them understand the complexity around AI, think more clearly about upgrading their own skills, and shape their own AI adoption strategies. That’s when I realized this accidental experiment held real value, and I decided I wanted to publish it so it could help empower other engineers and IT organizations the same way it had helped my friends.
With AI Flower, I am offering a public platform for AI-native engineering work: a shared reference model that helps engineers, teams, and organizations adopt and integrate AI sustainably and reliably. Its purpose is to moderate and organize the conversation around AI-assisted engineering, and invite targeted feedback on what breaks, what’s missing, and what “good” should mean in real production contexts. It doesn’t mean being perfect. It aims to be useful, freely available, open to contribution, and shaped by the strongest resource our industry has: collective intelligence.
Open knowledge sharing and collaboration cannot be optional. If AI is going to become part of how we design, build, operate, secure, and manage systems, we need more than tools and enthusiasm. Many of us work on systems that people rely on every day. When those systems fail, the impact is real. That’s why we owe it to those who rely on these systems to do so carefully, and why we won’t get there in isolation. We need the industry globally to unite on shared standards for trustworthy practice.
About AI Flowers
AI Flower maps the core activities that make up engineering work into core engineering disciplines. For each activity, it defines what good looks like, based on practices that engineers should already be familiar with. It then helps people explore how AI can support those activities in practice, provides guidance on how to start using AI in that work, shares links to useful learning resources, and outlines the main risks, trade-offs and mitigations.
But the AI landscape is changing rapidly. This activity-based approach helps engineers understand how AI can support core engineering tasks, where risks may arise, and how to begin building practical experience. But by itself, it is not sufficient as a long-term model for AI adoption.
As AI capabilities develop, many engineering activities will become more abstract, more automated, or embedded in the infrastructure layer. This means engineers will need to do more than just learn how to use AI in today’s operations. They will also need to work with emerging approaches like context engineering and agentic workflows, which are already reshaping what we consider core engineering work. A concept I call the skill fossilization model reflects that progress. This shows how both engineering skills and AI-related skills evolve over time, and as work moves to higher levels of abstraction, some of them become less visible. Together, the AI Flower and Skill Fossilization models aim to help engineers remain adaptable as the field continues to change.
The main objective of AI Flower is to help engineers find their way through these rapid changes and move forward with them. Although I provide content for each section and activity, the real value lies in the outline and structure itself. To become truly valuable, it will require the insight, care and contributions of engineers from all disciplines, perspectives and fields.
I really believe that AI Flower, as an open and freely available framework, can serve as a scaffold for that work. This is my contribution to the changing industry. But it will only be useful – it will only “bloom” – if the community tests it, challenges it, and improves it over time.
And if any industry can turn open criticism and contributions into globally shared standards, it’s ours, right?
Join me at AI CodeCon to learn more
If AI Flower resonates and you want a full walkthrough, I’ll be presenting it at O’Reilly’s upcoming AI CodeCon. (Registration is free and open to all.)
If you are concerned about how fast AI engineering patterns are evolving, that concern is legitimate. We’ve already seen the center of gravity shift from ad-hoc quick work to context engineering, increasingly agentic workflows, and there’s more to come. The main design goal of AI Flower is to remain stable in those changes by focusing on underlying capabilities rather than specific technologies. I will take a deeper look at that sustainability principle, including the skill fossilization model, in AI CodeCon.
