Software engineers have become overreliant on models to build applications, and it’s time to put humans more firmly in the loop, the AI Engineer Wo...
For further actions, you may consider blocking this person and/or reporting abuse
Good writeup, and Horthy is right about the part everyone underinvests in, humans at the front. But I'd push back gently on "no amount of harness engineering can solve what is fundamentally a model training issue," because I don't think the harness was ever trying to solve the training problem. It's not there to make the model better, it's there to bound a model you already don't fully trust. Those are different jobs. You don't test your way to a smarter model, you test your way to a broken change not shipping. Framing the harness as a failed attempt to fix the model sets it up to fail at something it was never for.
And honestly his strongest point argues the other way. The reward-signal gap he describes, where a flaw surfaces months later and can't propagate back to training, is exactly why you need a harness. Training can't learn from a failure that shows up in a year, but a deterministic test or eval gives you the fast local reward at the moment of the change that training never gets. The harness is the substitute for the signal the delayed failure can't provide, not a rival to it.
Where I fully agree is that this is really three layers, not two, and the middle is the one everyone maxes. A human decides what's worth building, the model proposes, and the harness disposes on whether the change is correct. Loops and evals bound correctness, they don't tell you the thing was worth building, and that human-at-the-front judgment lives on a different axis than verification. So the fix isn't less harness, it's to stop asking the harness to cover the two layers it was never on. Good talk to surface.
This three-layer breakdown is really useful. I'd add a beginner's angle to it: for someone still building foundational skills, the risk isn't just "the model writes the code"—it"'s that the model quietly makes the judgment calls you haven't developed the instinct for yet. The human at the front layer assumes you already have taste to apply. If you skip the years of small mistakes that normally build that taste, it's not clear you're actually contributing judgment at the "human" layer—or just rubber-stamping something you don't yet have the experience to question."
this is the sharpest version of the beginner problem i have seen written down. the taste question is real: judgment used to be a byproduct of writing and debugging your own mistakes, and if the model absorbs those reps, the default path produces reviewers who never earned the instinct they are being asked to apply.
but i do not think the answer is abstinence, it is relocating the reps. the habit i have watched work for people coming up fast: before reading what the model produced, write down what you expect the change to look like, then diff your expectation against the actual output. the gap between the two is exactly the lesson a small mistake used to teach, except it arrives in minutes instead of after a production incident. done honestly, you see more distinct failure modes in a month of reviewing model output than a pre-ai junior saw in a year of their own bugs, because a model generates a wider variety of plausibly-wrong code than any one person ever would. the raw material for taste got richer, not poorer. what kills the formation is the posture: accept-and-move-on treats the diff as an answer, predict-then-diff treats it as a hypothesis, and taste only grows in the second stance.
The predict-then-diff framing might be the most useful reframe of this whole debate for me personally. I think what got me stuck before was treating the model's output as something to evaluate after the fact — which quietly puts you in the accept-and-move-on posture even when you think you're being careful, because you're only ever reacting to what's already on the screen. Writing the expectation down first forces the commitment before you've seen the answer, which is exactly the part that used to happen naturally when a bug forced you to have a theory before you could even start debugging. I'm going to actually try this instead of just reading the diff and nodding along to it.
yeah, the "only ever reacting to what's already on the screen" is the whole thing, and it's worse than it looks because reading the output moves your prior before you can catch it. once you've seen the diff your judgment is already anchored to it, so "careful review after the fact" isn't a weaker version of predict-then-diff, it's a different thing that can't recover the call you'd have made cold. the prediction written first is the only uncontaminated opinion you get.
one thing that decides whether it actually works when you try it: make the prediction specific enough to be wrong. "it should handle the empty case" kind of matches whatever shows up, so you get the ritual and none of the reps. "it'll add a guard clause at the top and leave the loop untouched" can be flatly wrong, and being wrong is the entire point, that's the rep. if your prediction can't be falsified you didn't make one. curious how it goes once you run it on real diffs, that's where you find out if the habit holds.
"If your prediction can't be falsified you didn't make one" is going straight on a sticky note. That's the part I would have gotten wrong — I'd have written something vague enough to always feel right and wondered why the habit wasn't building anything.
The specificity requirement also reframes what being wrong means. A falsifiable prediction that turns out to be wrong isn't a failure of the exercise — it's the exercise working exactly as intended. The rep only lands when there's something concrete to be wrong about. Will report back once I've run it on real diffs.
i’d push back on this - adding human review gates without designing what they’re actually checking just creates rubber stamps. seen it happen in a week. the bottleneck isn’t headcount, it’s verification design.
Horthy's point about the reward signal never making it back across the gap is the real argument in the whole talk, and it's the part I'd want people to sit with. If a flaw that got vibed in only surfaces months later, there's no clean way to tell the model "that thing you did in March was wrong," so the training loop literally can't learn from its most expensive mistakes. That's a much stronger case for keeping humans in the planning seat than "AI makes errors," because it says the errors that matter most are structurally invisible to the process that's supposed to fix them. The 30 minutes of preplanning saving hours of review lands for the same reason, you're moving the catch to a point where the feedback is still cheap.
This is the full the script of the conference
It is really important to read the original writings, since Daily Context's authors have a clear marketing bias to misuse and misrepresent facts for their own financial gains.
This resonates with me from the other side of the experience curve. As someone still building foundational skills, I notice the temptation isn't just to "let the model write the code"—it's to let the model make the decisions you haven't developed the judgment for yet. Horthy's point about humans owning the planning stage assumes you already have the instinct for what good architecture looks like. For beginners, I think there's a real risk of skipping the years of small mistakes that normally build that instinct, because the model quietly absorbs the decision before you've had to sit with it. The harness and the human both matter, but if you never struggled through the wrong call yourself, it's not clear the "human in the loop" is actually contributing judgment—or just rubber-stamping.
The human role gets more important as the factory gets faster. Someone still has to own taste, risk, priorities, and the decision to stop generating and ship the smaller correct thing.
The more I use AI, the more I treat it like a fast junior teammate. It can build a lot, but I still want humans making the early calls because changing direction later is always the expensive part.