generative AI automation

Decouple intent from code to let engineering creativity thrive.

Pull requests were never designed for AI-generated code, yet they're still the gatekeeper.

3 min readInfoQ
Decouple intent from code to let engineering creativity thrive.

The shift toward write-only software is one of the most honest descriptions of modern engineering we've seen in a long time. Phillip Mortimer's argument cuts through the noise: when AI generates the bulk of code, the traditional pull request becomes a bottleneck built for a different era. You're no longer reviewing a human's logic line by line; you're scanning a diff that might as well have been written by a very fast, very literal intern. That's not a failure of discipline. It's a mismatch of tools. And it's why Mortimer's call to decouple intent from implementation feels less like a best practice and more like a survival strategy.

This resonates beyond the engineering org chart. The same tension between human oversight and machine output is playing out in data management, where Atlassian Automates Root Cause Analysis by Correlating Metrics, Logs and Traces shows how teams are using automation to handle what humans can no longer track manually. If you can let AI own the "how" of incident response, you free your people to focus on the "why." That's the same principle Mortimer applies to code reviews: stop policing syntax and start evaluating outcomes. The hard part, as he rightly notes, is building the self-healing architecture that makes this trust possible. You can't decouple intent from implementation if your system falls apart the moment a model makes a questionable call.

What we find compelling here is the emphasis on creativity, not as a luxury but as a byproduct of good architecture. When your codebase is self-healing and your reviews are automated, you give developers the mental space to design better systems. That's a far more practical take than the usual "AI will replace us" panic. It also connects to a broader trend we're tracking: the move toward interfaces that anticipate needs rather than waiting for commands. The The Death Of The Button: Why The Best Interface Is No Interface article makes a similar case for UX, and we think the two ideas are two sides of the same coin. In both cases, the goal is to reduce friction so that human judgment is applied where it matters most.

Our take? Mortimer is right that pull requests are broken, but we'd push further. The real challenge isn't just automating reviews; it's redefining what "review" even means when the codebase is partly a living artifact of AI decisions. That requires a cultural shift, not just a tooling upgrade. We'd tell any engineering leader to start small: pick one service, automate its review process, and measure whether your team's time on debugging drops. If it does, you'll have the evidence you need to scale the approach. The specific detail to watch is how your team reacts to the first AI-generated bug that slips through. That moment will tell you more about your readiness than any roadmap.

From InfoQ

Phillip Mortimer discusses the shift toward write-only software driven by AI code generation. He explains why traditional pull requests are broken and shares how engineering leaders can manage complexity by decoupling intent from implementation, automating code reviews, and building self-healing architecture to unleash developer creativity across senior engineering and architecture teams.

Read the original at InfoQ