The Director and the Agent: Why Experienced Engineers Are the Real Engine of AI-Assisted Software Development
There is a persistent misconception that AI-assisted software development is about handing over a specification and waiting for code to compile. There’s a common story that engineering roles are shrinking into passive prompt engineering. At OpenArc, where our engineers build complex systems alongside AI agents daily, we see a very different reality.
An AI agent is a powerful execution engine, but it lacks contextual intuition, domain awareness, and real-world grounding. The engineer’s role hasn’t shrunk – it has shifted from writing the code to deciding what the code should even be doing. The real value happens in the loop: directing, challenging, and asking the right questions.
Broadening the Horizon When the AI Settles Too Early
AI agents are eager to please, often settling on narrow options generated within their immediate context. When crt.sh suffered a 32-hour outage, an agent proposed three basic paths (wait it out, pay $50/mo, or use a specific free tier). Instead of accepting a constrained choice, the engineer pushed back: “Did you look through the options here: https://letsencrypt.org/docs/monitoring-options/ as well?” By forcing the agent to evaluate an authoritative reference list, the engineer redirected the solution space toward a better architecture before issuing the direct instruction to implement a CertIndex CT source flag.
Reframing Scope for Business Reality
Agents build to maximum technical limits rather than practical business constraints. While an agent was deep in the weeds designing pagination for an API ceiling of 200 items per page, the engineer stepped in unprompted: “I think the top 10-20 domains per hospital domain would likely be sufficient, maybe even top 8 to 10.” This mid-build reframe eliminated unnecessary complexity. Similarly, on embedded hardware projects, when the agent attempted complex floating-point comparisons in Spin for dew point calculations, the engineer directed a simple integer truncation, streamlining calculations across the entire codebase.
Challenging Assumptions Against Reality
AI agents operate with high confidence, even when relying on flawed premises or broken delivery loops. It surprised even us how easily an agent will build an entire feature on a fantasy spec: it designed our rate-limiting logic around an officially documented limit of 100 requests/hour, completely unaware until we caught a live 429 response body that the real ceiling was 10. And when an agent claimed work was delivered despite a surface error, the engineer’s skeptical pushback – “Did you actually update Discover.TS in my working directory? getting: [404 error]” – came from a place of real-time debugging friction, forcing a verification that uncovered an endpoint bug. On the hardware bench, when relative humidity readings spiked while temperatures stayed flat, the engineer spotted swapped physical sensor inputs that the AI was blind to.
Exposing Design Gaps and Edge Cases
Agents naturally focus on the happy path, overlooking what happens during long waits or sudden crashes. A single pointed question from the engineer,“Will it pick up where it left off if it crashes or I stop it?”, exposed a major design gap, triggering a full --watch/ct-retry-only architectural rework. Other times, the intervention is born of sheer annoyance: when an unhandled backoff sleep caused a script to freeze silently, the engineer’s feedback, “Oddly, the script is just hanging now” – came from the familiar frustration of staring at a completely silent terminal for three minutes with zero feedback. That observation prompted visible logging and hard backoff caps. From redirecting countdown timing displays directly onto Propeller microcontrollers to dynamically scaling tachometer gauges in 100 RPM increments during fan overrun, engineering intuition prevents subtle regressions.
Software engineering is not just about writing syntax; it is about navigating business trade-offs, edge cases, and system realities. AI agents accelerate implementation, but catching flawed assumptions, setting clear boundaries, and redirecting the approach keep projects on track. The agents are fast. The judgment still has to come from the person who understands the hospital domains, the physical sensors, and the business constraints.
