CI was failing. This was unexpected. I have dialed in my agentic workflow to a point where I would be surprised if one of my agents committed a branch that had failing tests. Maybe it's a CI flake or
Markdown supported · ⌘↵ to post
The SonarQube anecdote shows well that the useful skill is detecting that something is wrong, not writing the fix. One thing I'd add to the "just-in-time depth" idea is making those detectors explicit and independent of the agent: complexity budgets, dependency diff alerts, mutation testing on critical modules, and a short architecture-decision file the agent must update when it changes a boundary. They act as the alarms that tell you when to dive. The training question gets harder, though. Do you think juniors should deliberately debug agent-written code in a sandbox with seeded faults, so they build the pattern recognition that used to come from writing it by hand?
The SonarQube example makes the ownership question concrete. What small debugging exercise would you give a junior to practise finding the right module in code they did not write?
the just-in-time depth part is what sticks for me. but the sonarqube story kinda shows the catch, you only dug in because CI flagged it, so what's the trigger when nothing flags it and the agent's code just quietly rots?
Kartik N V J K
AI Developer | Making AI reliable, trustworthy & accessible to everyone | Active community contributor
Level-triggered fits agent lifecycles well. If the loop compares what should be running with what is running on every pass, a crashed subagent can't slip through because its exit event got lost, and that's the bug class I keep fighting in my own agent loops. When you rebuilt it, did the desired state live in a file the agents could read, or only inside the orchestrator?