AI Native Transformation Needs Better Software Delivery First

The story we told at AI Native DevCon London was not about handing out AI coding licenses and waiting for productivity to appear. It was about a real transformation inside Odevo, a residential property management company with a complicated operating model, many acquired businesses, many software stacks, and a very practical need to build more software faster.

Odevo manages the full value chain of residential property management. That means technology for property managers, homeowners, associations, billing, maintenance, compliance, safety, and a lot of local operational reality. In seven years, the company had grown from around 50,000 homes under management to roughly 2.5 million, and from around 1,000 employees to 14,000.

That growth matters because it explains the software problem. The company had acquired many businesses, each with its own culture, process, and technology. Some systems were modern. Some were old. Some workflows were still partly paper-based. There was no single clean environment where AI adoption could simply be switched on.

Our talk, "More software, faster: Odevo's AI Native transformation," was about how we approached that reality. The important lesson is that AI makes weak software delivery systems weaker and strong systems stronger. So the transformation had to start with the system, not with the tools.

Use This Talk As Agent Context

Tessl has turned our AI Native DevCon talk into a skill your agent can use as context. You can also watch the full recording.

What Was The Starting Point?

When the journey began in 2024, Odevo already had some AI use. Developers were using GitHub Copilot. The company had built its own internal chat solution on top of OpenAI because it works with private and sensitive data and did not want employees pasting that information into arbitrary tools.

There were also small islands of experimentation. One developer would have a Claude license. Another would try a different tool. A few people were enthusiastic, but adoption was not systematic. Around 30% of developers were using the available tools, mostly Copilot.

At the same time, the organization had already invested in improving flow, transparency, and modern delivery practices. That was important. If teams do not know how they are performing, they cannot see where AI helps or where it creates pressure. The year and a half spent improving the delivery system made the AI work much more likely to succeed.

This is one of the main points we wanted people to hear. AI adoption is not isolated from delivery health. If your CI/CD is weak, your platform is weak, your tests are poor, and your teams do not agree what good looks like, faster code generation will expose those gaps.

Discovery Came Before Training

Before training, we ran discovery. That meant understanding the current lay of the land: delivery practices, tooling, team cultures, bottlenecks, tests, coding standards, platform maturity, and the different kinds of work teams were doing.

This was not a formality. It was one of the reasons the training worked. Odevo did not want a partner to arrive with a generic syllabus and a set of assumptions. We needed to understand the company's real constraints and design the learning journey around them.

The DORA research we discussed in the talk is useful here. If you are already doing software delivery well, AI coding can accelerate the system. If you are not, making one part of the system much faster can make the whole system worse. Nobody yet knows exactly where the balance point is for every organization, so discovery matters.

The practical questions are basic but uncomfortable. Can teams ship reliably? Can agents run tests and trust the signal? Are coding standards written down? Are workflows observable? Do teams have a platform that lets them move quickly without each group inventing its own path?

Those fundamentals are not separate from AI transformation. They are part of it.

Workshops Made The Risks Speakable

We also ran in-person workshops before and around the training. The goal was not only to teach tools. It was to surface how people felt about the change.

We used liberating structures because power dynamics matter. If the loudest people dominate the room, you do not learn what a team is actually worried about. We wanted people to talk about excitement, fear, skepticism, motivation, job security, and quality concerns in a way that did not punish honesty.

One exercise used the TRIZ format. We asked people to imagine Odevo hiring 200 junior software developers who always said yes, never pushed back, never slept, and coded all day and night. How could we make that the biggest disaster possible?

People quickly named the risks: poor testing, unclear standards, weak review, bad requirements, hidden assumptions, and broken process. Then we asked the important follow-up: what do we already do that looks a bit like those bad things?

That was powerful because people across different stacks and cultures recognized the same issues. The room could see that the risk was not abstract. AI was going to amplify practices the organization already had. That reduced resistance because the conversation became practical rather than ideological.

Teach Failure Modes, Not Only Happy Paths

The training itself was deliberately spread over time. We did weekly half-day modules instead of one big training blast. People learned a concept, tried it at their desk, applied it to their own production codebase, and came back with real questions.

The syllabus started with fundamentals: context management, maximum effective context windows, hallucination, prompt biasing, tool execution, MCP, spec-driven development, multi-agent workflows, and the psychological jump from autocomplete inside an IDE to a terminal-based coding agent that chooses what to show you.

One of the most useful teaching techniques was asking, "What did we just do?" after an exercise. If someone installed Claude Code, where did the prompt go? How did the model decide which tool to call? Where did the tool execute? What context did the model actually have? Drawing that flow made the system visible.

We did not need to spend most of the time showing happy paths. When these tools work, they often feel obvious. The training value is in failure modes: when the model loses context, when instructions conflict, when tests are not meaningful, when an agent overreaches, or when a team cannot tell whether output is good.

That is why in-person training mattered. People were not half-listening while doing other work. They could see each other, ask awkward questions, and build shared vocabulary.

Measure Adoption, But Watch Boldness

After the core training finished, the adoption numbers moved. Around 94% of developers reported using AI in at least three of their last ten PRs, and around 60% reported using it in all ten. Only about 6% had not used it in that recent window, and that became a research question rather than a judgement.

The throughput metrics improved too. Time to market improved, PR throughput increased, and dashboards made work more transparent across teams and repositories. Those measures matter, but they were not the most interesting outcome.

The deeper change was boldness.

People started trying work that would have felt unrealistic before. One platform that had been built over eight years was rewritten to feature parity in about three weeks with support from an external expert. A mobile app was attempted in three days. Not every experiment worked, but the organization was doing more ambitious experiments.

That is a better sign of transformation than token usage. If people only use AI to do the same work slightly faster, the organization has not changed much. When teams start rethinking what work is possible, the operating model is changing.

One Team Redesigned The SDLC

One team took the next step and asked whether their software delivery process still made sense.

They had learned to use coding agents individually, but they realized that working story by story through a conventional process was becoming the bottleneck. So they spent two weeks on product requirements, talking with stakeholders, recording conversations, transcribing them, and turning that material into a product requirements document.

They then pushed the work through a higher-level planning process. Agents helped split the work into epics and tasks. Developers picked up tasks in their preferred way, using different tools and styles, but the team stopped treating human code review as the central quality gate. They used repeated agentic review passes before opening PRs, then self-merged through the process they designed.

The point was not that every team should copy that exact process. The point was that once code generation gets faster, scrum, Kanban, review, and planning habits may need to be re-examined. Otherwise the bottleneck simply moves.

The People Stories Matter

The transformation was not only a tooling story.

One developer came into the training as an AI skeptic. He had tried chat-based coding before and found it unconvincing. With the chance to use current agentic tools on real work, he changed his view. The difference was not a better demo. It was seeing the current state of the tools inside a realistic workflow.

Another developer on the internal developer experience team stopped writing code directly and started building the tools that made other developers more effective. A third became part of the train-the-trainer effort, taking the learning back into other companies and teams inside Odevo. That mattered because internal practitioners make the message more credible than outside consultants alone.

We also talked about a caution. Some developers said they could not turn it off. The feedback loop is compelling. People were still working at 6 p.m., 7 p.m., or 1 a.m. because the tool kept making progress feel available. AI transformation needs to include sustainable pace, not just delivery speed.

Everyone Becoming A Builder

The next bottleneck is product. Once engineering moves faster, product managers, designers, analysts, and business experts need new ways to shape work. Odevo started shifting the training toward product colleagues and then toward the wider organization.

The larger ambition is that everyone becomes more of a builder. Not that software developers disappear, but that business users can solve more of their own problems with support from the technology organization. In the past, a local business process could be changed with a paper form. Then software centralized that power inside engineering teams. AI gives us a chance to give some of that agency back.

That is exciting and uncomfortable. More people can build more bespoke software for local problems, but the organization still needs standards, support, governance, and education.

For us, the practical lesson is clear: AI-native transformation starts with software delivery maturity, human adoption, shared learning, and the courage to redesign the system around the new constraints.

The full version of this case study was presented at AI Native DevCon London. To go deeper, watch the full recording.