For decades, software engineering has operated under a deeply ingrained mental model: developers design the system, write the code, understand its internals, and remain responsible for operating and maintaining it. Even with all our talk about “raising the level of abstraction,” we have mostly continued hand‑crafting software the way mechanics hand‑build custom cars.
But today we’re standing at the edge of a transformational shift—one that requires us to rethink who maintains software, who changes it, and how those changes safely enter production. AI‑driven development is forcing us to adopt a new mindset, and to get there, we need better analogies to understand what’s changing.
From Mechanic‑Built Cars to Mass‑Produced Vehicles
When I was a kid, I built and repaired my own bicycle. I knew every bolt, every bearing, and every cable. I became a pretty good bike mechanic. I had an uncle who took that same spirit into the world of automobiles. He built his own car from a Cobra kit. He could assemble the frame, drop in a Ford Mustang engine, and wire everything end‑to‑end. It was his machine—designed by him, built by him, operated by him.
For a long time, software has worked exactly like that.
We have been the designers, the builders, and the operators of our own “custom‑built cars.” Even when we deliver software to users, the reality is: we’re the ones who turn it off and on. The users operate workflows, but developers operate the system.
But think about the difference between a mechanic‑built kit car and a Toyota. Toyota builds cars so that anyone can operate and maintain them—without being a mechanic. Owners can perform basic servicing and routine maintenance without knowing how an engine works.
This is exactly the shift software must make.
Software Must Become Maintainable by Non‑Programmers
In the world of AI‑driven development, our users will need the ability to service the software, not just use it. Maintenance won’t just mean restarting a service or changing a setting—it will include modifying configuration and, yes, even making source‑level changes.
That sentence still makes many engineers uncomfortable.
But once we accept that:
not all changes must be performed by a fully‑skilled software engineer,
then the DevOps environment itself must evolve. AI coding tools become the intermediary—allowing analysts, product owners, support personnel, and other trained team members to perform controlled, validated, safe changes.
Imagine a business analyst safely adding a value to a dropdown—without pulling a developer off higher‑value engineering work. In an AI‑augmented environment, this is not only realistic; it’s essential.
Why DevOps Must Evolve Beyond Handcrafted Code
For years, we’ve invested heavily in DevOps maturity:
- Private builds with unit and integration tests
- Integration builds producing deployment-ready artifacts
- Full system acceptance tests in deployed environments
- Pull requests with human review
- Release automation and continuous delivery pipelines
This foundation remains crucial—but insufficient.
Today, a pull request from a simple dropdown modification still requires a developer to review it. That means:
- A human becomes the bottleneck
- Developer attention becomes the scarce resource
- Productivity gains plateau
If every AI-generated change still requires a developer to review the PR, then the industry will never achieve the 10x productivity improvement that AI makes possible.
We need additional automated checks—new validation techniques—to determine:
Is a feature branch stable? Did this change unintentionally break anything?
If automated systems can answer that confidently, then humans no longer need to review every simple change.
Identifying Which Changes Should Be AI‑Driven
Not all software work is the same. Some work is:
- New architectural patterns
- Novel paradigms
- First‑time implementations
- Complex engineering decisions
These still require expert developers hand‑crafting code.
But other work—the vast majority of day‑to‑day changes—comes down to repeating well-established patterns. These repetitive, low-risk modifications are the perfect entry point for AI-driven development.
Once a pattern exists, repeating it is not engineering—it's manufacturing.
AI excels at manufacturing.
The challenge I’m proposing is simple but profound:
What must we add to our DevOps environments to let non‑programmers safely perform routine maintenance—including changes that touch source code?
Your DevOps pipeline must evolve to:
- Validate AI-generated code automatically
- Confirm functional stability with higher test coverage or new test methods
- Detect unintended side effects reliably
- Provide automated PR approvals for safe classes of changes
- Allow analysts and operators to perform controlled maintenance work
The goal is not to remove software engineers—it’s to free them.
If developers are still reviewing every tiny change, we cannot scale. If they are designing, validating, and engineering the core patterns—and AI handles the repetition—then the industry finally moves toward true software engineering maturity.
A Call for a New Mindset
As AI coding tools advance, the opportunity becomes clearer:
- Software engineers focus on engineering
- AI handles pattern-based manufacturing of code
- Non-programmers, empowered by AI, handle routine maintenance
- DevOps systems ensure everything is safe, stable, and validated
This is the mindset shift required for the next era of software.
Now the question is: What changes will you make to your DevOps environment to unlock this new model?
God bless.
Originally published on LinkedIn.
