Principal software engineer Joy Ebertz described AI-assisted programming as a split between vibe coding for non-critical tools and tightly specified, carefully validated work for essential systems. Speaking on InfoQ's Architect's Podcast with Michael Stiefel, she said code reviews look ineffective for AI output, while verification has become a heavy burden. That framing matters for business because long-term system survival now depends less on writing code and more on defining requirements.
Constrained tasks, ambiguity and legacy code
Ebertz works at Imprint, where she focuses on backend development and untangling configuration, after staff-plus roles at Harness, Split and Box. Her background includes microservice architecture, authorization frameworks, REST API standards and feature flagging. On the podcast she placed herself in an architect role despite never holding the formal title, tracing that path through domain-driven design work on breaking a monolith into microservices. The discussion connected that experience directly to AI coding practices.
AI models perform better with bounded scope, Ebertz said, when they see a limited codebase and receive a narrowly defined problem. That observation cuts into the monolith-versus-microservices debate, since smaller service boundaries give AI clearer boxes to work inside. A large monolith makes it harder to control context and judge generated changes. For companies, the architecture choice now affects how safely AI can contribute without spreading side effects.
Requirements ambiguity emerged as the central bottleneck. Architects must translate business goals for engineers and technical trade-offs for managers, and now also state goals clearly for AI agents. Tests need unambiguous formulation because vague acceptance criteria leave AI output unverified. The problem grows acute in older systems where nobody remembers the original requirements, making it difficult to decide whether to fix code incrementally or regenerate a module.
What AI coding means for engineering teams
For businesses using AI in development, two operating modes require different governance. Internal tools tolerate imperfection and suit fast vibe coding, while customer-facing or regulated systems demand detailed specification plus careful validation, effectively pair programming with AI. Small firms can move quickly on the first mode, but larger organizations need review gates, test discipline and ownership for the second. Without that separation, speed in prototypes leaks into production risk.
Limits center on verification, training and change management. Industry practice has not settled how to absorb bug reports or new requirements into AI-generated code, and repeated regeneration can discard fixes or introduce drift. Junior engineers face a narrower learning path because AI now handles routine tasks that once built foundational understanding. Buyers should ask vendors how generated code is tested, how assumptions are recorded, and how human comprehension of the system is preserved.
A practical marker to watch is whether teams publish explicit constraints and assumptions alongside AI-built components and track verification effort per release. If constraint lists, unambiguous tests and review records become standard artifacts over the next product cycles, the pair-programming model has taken hold. If they stay absent, AI output will accumulate as opaque legacy that future teams cannot safely change.
