As we begin to explore the frontier of rebuilding our digital business to be AI-native, one thought keeps haunting me: if everyone is building their own engineering harness, what does that mean for the portability of our skills and the longevity of our systems?
I’ve worked with enough businesses that started in the 1990s to have seen a version of this movie before.
Organisations built on proprietary languages—or bespoke layers built on top of established ones—often enjoy an initial competitive advantage. In the early days, teams move quickly because they have shaped the technology directly around the product.
But as the industry reorients around mainstream standards, those proprietary choices turn into constraints. Decades later, many of those organisations are still living with the consequences.
The talent and ecosystem toll
The problem isn’t just the technology. It’s the talent model that grows around it:
- Hiring shrinks: The talent pool narrows because the required skillset is hyper-specific.
- Onboarding slows: Developers must learn not just the domain and codebase, but the idiosyncratic language itself.
- The training burden shifts: Organisations are forced to recruit heavily from graduate pools and take on the entire training overhead themselves.
- Skills atrophy: There is a hidden human cost. After years of mastering one bespoke way of building software, how transferable are those skills when engineers eventually move on?
Meanwhile, the broader ecosystem compounds the problem. When open-source tooling, frameworks, and practices rally around mainstream technologies, proprietary environments are left to recreate the basics from scratch.
What starts as a source of speed becomes an ongoing maintenance burden. Talent stagnates. Ideas develop more slowly. Eventually, the industry moves on.
The AI-native dilemma: building a vehicle or a cage
Which brings me back to AI-native software development.
As we all start constructing our own agentic loops, prompt pipelines, and developer harnesses, I’m thinking carefully about how bespoke we make them. There is an obvious temptation to optimise the harness around exactly how we want to work, and real value in doing that. I don’t want to wait for some external force to normalise the stack. I’d rather be on the track, learning by doing.
But I also don’t want to accidentally create the next proprietary programming language.
There is a subtle trap here: if your custom harness insulates your team too much, they stop learning how the rest of the engineering world is solving core problems like evaluation, context management, and guardrails. You end up optimizing for your internal bubble while the industry accelerates outside it.
Designing for disposability
The opportunity lies in a completely different mental model for infrastructure:
- Decouple edge from primitive: Build custom orchestration where it creates genuine strategic leverage, but keep underlying patterns close to mainstream standards.
- Protect skill portability: Ensure that the skills your engineers practice today are marketable tomorrow. A developer shouldn’t need a CV that reads like an instruction manual for your internal toolchain.
- Build for planned obsolescence: In traditional software, we built for longevity. In the AI era, we must build for disposability.
I want a harness we can rip down and rebuild every three months as better ideas emerge—not a platform we spend the next ten years defending.
It’s a delicate balance. But that is what makes this frontier so compelling. We’re not just learning how to build software differently; we’re learning how to build the systems that build software differently.
I’m excited to see what we learn along the way.