What your engineer shipped this week is not the question worth asking

A Hacker News post titled "'Code was never the hard part' is an insult to all programmers" drew 932 points and 575 comments after going up on 8 August 2026. ^source The post rebuts the claim in its own title: the author argues that writing good code has always been a real craft, demanding skill and judgment, and that the danger now is handing that craft over to AI along with the typing. ^source Read alongside the thread, a narrower and more practical version of that warning holds: AI has flooded the one artifact managers could point to and ask about, the code, while the part of the job that decides whether that code is any good has never had an artifact at all.

That is not a debate about whether AI-assisted engineers are still doing real work. It is a description of what a 1:1 question is actually measuring now.

"What did you ship" was built for a different artifact

The question has always stood in for something else: not the code itself, but the thinking behind it. When writing code was the effortful part of the job, asking what got shipped was a reasonable proxy for what got decided, investigated, and ruled out along the way. The volume of code someone produced tracked, roughly, the volume of judgment that went into it.

That proxy breaks when code stops being scarce. An engineer can now ship a large, clean-looking diff in an afternoon with an AI assistant doing most of the typing. Asking what they shipped still gets an answer, but it is an answer about the artifact, not about the judgment that decided which parts of the AI's output to keep, which to throw out, and which to go investigate before trusting. That judgment is exactly what the Hacker News thread says has no artifact to point back to. Ask a manager to reconstruct it from a diff and a stand-up update, and they mostly can't.

The fix is not a better dashboard

It is tempting to read that gap as a tooling problem: track more, log more, make the invisible visible with better analytics on top of the commits. That does not work, because the thing missing is not data about the code. It is a comparable record of what was decided against.

The fix has to change the question, not the dashboard behind it. Instead of asking what got shipped, a manager can ask what got cut, what got investigated and abandoned, and what got kept even though the AI suggested otherwise, then ask the same shape of question next time with the previous answer already on the table. The value is not in any single answer. It is in whether "what did you decide not to build" gets sharper and more specific across three or four sessions in a row, because each session can reference what was said in the last one instead of restarting the question cold.

Carrying judgment forward across a recurring series

That is the part a single conversation cannot do on its own: neither person can be expected to remember, unprompted, what got ruled out four sessions back well enough to notice whether the pattern is repeating. 1on1 reads the recurring history of a manager-report pair, prior sessions and the action items that closed or slipped, so a session can pick up from what was actually discussed last time instead of both people reconstructing it from memory. Action items carry forward the same way, so a decision made against a shortcut two sessions ago is still on the record when it comes up again. ^source That is a memory difference, not a productivity claim: the tool does not evaluate whether the judgment was good, and it does not score or automate anything about performance. It keeps the record so the question about judgment has something to reference besides the diff.

Try it before you take our word for it

Run one manager and one direct report through 1on1's pilot for four sessions. Skip "what did you ship" this time and open with "what did you decide not to build, and why." Look back at session one's answer when you ask again in session four. If the answer has gotten more specific, that is the judgment showing up where the diff never could. ^source