Dave Mangot

Dave Mangot

I partner with PE portco CTOs to deliver on the investment thesis by helping them change the culture of their existing org from halting to daily delivery so they can get the race going.

Cutting-Edge AI vs. Solid Architecture: Which Will Truly Transform Your Business?

I recently stumbled across a podcast I was a guest on years ago that had gotten lost in the shuffle. The podcast was by a company that helps people with their legacy software and is called Legacy Code Rocks! The conversation we had was based on an article I’d written about how technical debt is a business problem, not a technical problem.

Listening to the episode was like climbing into a time machine. Not because the concepts were outdated, but because I heard ways of describing things that I hadn’t used in a while, that had gotten lost in the shuffle.

One of my favorites was one I’d borrowed from Dr. Nicole Fosgren (one of the authors of Accelerate): Architecture Matters, Technology Doesn’t.

Dr. Fosgren was making the point that the architecture of the system had a much higher impact than the technology itself. That is, you could be a mainframe shop and still outperform the latest startup that has all the cutting edge tools. It wasn’t the technology that mattered, it was the architecture.

Earlier this year, I worked on a project evaluating dozens of companies on their readiness to use AI both to write software and inside their product (reach out if you want to learn more) and we can talk about Architecture here from two perspectives: the architecture of the software delivery, and the architecture of the software itself.

DORA omits technology

Enterprise Environment

Though the 2025 DORA Report is a few months away, that hasn’t stopped DORA from publishing research on AI adoption.

  • Share and be transparent about AI Usage - 11.4% increase in adoption
  • Encourage AI integration - 27% more adoption
  • Take steps to alleviate developer anxieties - 125% more adoption
  • Give time to experiment with AI - 131% increase
  • Have a written AI Acceptable use Policy - 451% increase in AI adoption!

There is nothing published in the research about which coding assistant to use, or which encoding is best for RAG. They are owned by Google and they are not even pushing Gemini. It’s because architecture matters, technology doesn’t. If you want to have higher adoption of AI code tools in your organization, it’s not about Cursor vs. Windsurf. It’s about whether you have an AI Acceptable Use Policy (AUP).

The AI world is changing not only fast, but constantly. Having an AI AUP signals to the engineers that the organization takes this technology advancement seriously. They understand what the expectations are (intellectual property concerns, for example) and that the goal is not to eliminate their jobs. It’s no wonder alleviating their anxieties made the list.

The 2024 DORA Report also showed compelling advantages for teams that were able to increase AI adoption, so increasing adoption is good for the business. Having spent the last few weeks working with an AI coding assistant daily for the AI Readiness Assessment, despite what the AI vendors say, the developers are not going anywhere anytime soon. (yes, I know, it’s always 3-6 months away)

Developer Environment

Enterprise architecture is not the only place where architecture matters more than technology. The developer experience also plays a huge role.

I’ve worked with many portfolio companies where developers write code that is reviewed by the QA team. I’ve seen all kinds of efforts to “embed” QA engineers on the team to shorten the testing time. I’ve seen QA folks work in different timezones so the test results will be ready in the morning. Performance tests once a month. Security tests only once a week.

In DORA metrics terms, these are attempts to reduce Lead Time for Changes. But the most impactful way to do this is to have automated tests. The book Continuous Delivery by Humble & Farley recommends the amount of time it takes to get a cup of coffee (10-12 minutes approximately) as the amount of time you should have to wait for your tests to complete. In DevOps terms, this is shortening and amplifying feedback loops.

If we have that kind of architecture in our development environments, that’s good for AI coding assistant adoption too. One of the open secrets in software development is that Test Driven Development (TDD) works and is a huge performance increase. If I’m working with an AI assistant and I want to know if all the code that it generated does what it says it does, I can run tests! If the tests pass, then the code is probably correct enough for the job.

If I have to wait for a QA engineer to send me the results from the other side of the planet the next day, then I don’t care how good the JMeter or Selenium tests are, that technology is not going to allow me to compensate for the long feedback loop. Only good testing architecture can fix that.

Modularity brings options

In a talk I gave earlier this year for a private equity CTO conference I shared a quote from Dr. Carliss Baldwin of Harvard University.

“Unlike a rigid system where you take it or leave it, modularity allows you to mix and match the best outcomes from many experiments. This was my biggest insight… The structure’s option-rich nature has profound implications for value creation.”

The architecture of the application itself also has a big impact on the success we’ll have adopting AI.

AI coding assistants:

  • Are compliments, not substitutes for human engineers.
  • Enable projects that would have been too difficult, costly, or time-consuming.
  • Enable the flexibility to explore a path without committing upfront.
  • Provide an “option portfolio” for design and development choices.

If we have a modular software architecture, then we can run more of the experiments that Dr. Baldwin advocates. If we use AI to prototype these experiments that would have been too difficult, costly, or time-consuming previously, then we can really get to experimenting!

The hard part of writing software was never writing the software. By leveraging AI, we can write software faster, sure. But we can also spend more time modularizing the system, more time developing unit test suites, more time experimenting not only on value creation but on security enhancements, margin improvement, M&A integration.

That is, more time on the architecture of the system, not on the technologies. The better the architecture, the more option-rich the architecture, because we’re not spending our time on activities like manual QA which add no value, the faster we can go. It’s a virtuous cycle.

There are a lot of different attributions for this same quote: it’s not the big beating the small anymore, it’s the fast beating the slow.

Make a better company?

It’s the architecture that helps us go fast, not the technology. It’s the modularity of our architecture. It’s the feedback speed of our architecture. It’s the transparency and support of our architecture that creates the systems in our organizations that enable people to take advantage of these new developments.

And if it turns out that this whole AI thing is a bust? What if our developers are excited to come to work, if they are able to execute with low friction and high output, and if the business is able to grow better, cost less to run, and is more successful in the process, all without AI?

That wouldn’t be so bad either.