In Part 1, I wrote about the uncomfortable part of AI-assisted engineering: the tools are becoming remarkably good at producing things, while the h...
For further actions, you may consider blocking this person and/or reporting abuse
The useful dividing line is between instructions and gates. Once a requirement is mechanically checkable, it should live outside the prompt. The harder question is defining what evidence allows the workflow to resume after a gate fails.
That's a really good point. Defining what happens when a gate fails is just as important as defining the gate itself. Otherwise, we risk automating the failure without actually improving the process.
I'd make the failure path explicit too: hard policy violations block the workflow, fixable issues get a bounded repair loop, and ambiguous cases go to a human with the evidence attached. Otherwise, a gate is just a red light - people eventually find a way around it instead of improving the process.
the six components land. section 2 is the one i would push on.
a gate needs someone accountable for checking it. automate the check and that person only ever sees the gates that went red, so every gate they see is already a failure. the green ones carry no name. that is exactly where a wrong-but-passing result travels, and in observability it does not look like a gap, it looks like green.
so: when a check is automated, does a named owner stay on the passing path too, or does ownership move to the check itself? and if a green check still produced the wrong outcome, what artefact tells you the gate failed rather than the agent?
I like this distinction between a green check and a correct outcome. Passing checks can give us confidence, but they don't automatically mean we've got it right. I think this is where we need to keep improving what we verify and how we know it's enough.
this is the part i want to pin down, because "know it is enough" is the whole question. the cheap move i keep coming back to: every automated gate needs a known-bad input it is required to fail on, run on the same schedule as the real checks. if that fixture ever comes back green, the gate is broken, not the code behind it. without it a green check can only tell you what it happened to look at, never what it missed. do you keep anything like that aimed at your own gates, or does it only show up when something gets through?
The bottleneck moving from production to leftover decisions is exactly what I see. Which checks can actually be a gate is something you only learn after a few mistakes. What the harness doesn't reduce, for me, is how many of those leftover decisions remain. Autonomous loops make it cheap to run several units of work at once, and there are mora and more decisions to make. That's decision-fatigue, not review-fatigue.
I hadn't thought about it quite that way, but you're right. Making each unit of work cheaper doesn't necessarily make the decisions around it cheaper. We might end up moving the bottleneck from reviewing work to deciding what to do next, especially when multiple agents are working in parallel.
That's the queue I keep hitting. Three units all passed their checks, and the remaining work is picking which one is allowed to continue. Reviewing the diffs got cheap. Ranking the next move did not, because that ranking still sits with a person, and it doesn't get cheaper when the units do...
AI Engineering is the most complex thing to do as of today.
The distinction between an instruction and a gate is crucial. If a step can be skipped without becoming visible, it isn’t truly part of the workflow.