Loading…

Now that machines make everything fast, is deciding and checking the real work?

Ovid
Public 6 conversations 10 thoughts 329 upvotes 53 downvotes 1 series 552 views

Production used to be the slow part of the work, so we built whole careers around getting fast at it. Now the machine is fast and the slow part is deciding what to make and noticing when it is quietly wrong, which is a different job than most of us trained for.

In series

In groups

Discussion content

A few weeks ago I watched a pull request go in that passed every test, read cleanly, and quietly got one edge case wrong. The model wrote it in under a minute. The person who approved it spent maybe ninety seconds on the review. The bug surfaced four days later in a place that cost ~$5000 (not that much, but not little either). Nobody had been careless in the way we usually mean. They had just put their attention where the work used to be, the producing, instead of where the work had moved to, the deciding and the checking.

That is the shift I want to name, because most career advice has not caught up to it. For a long time the slow, expensive part of knowledge work was making the thing and you would review and test as you went, because it took days/weeks/months to get something done. You'd find more edge cases as you worked. Writing the code, drafting the brief, building the model, updating the UI... So we organized everything around getting faster and cleaner at production, and we were right to, because that was the bottleneck. Remove a bottleneck and the value does not vanish. It moves. When generating ten plausible options takes seconds, the scarce thing is no longer the generating. It is knowing which of the ten is right, and catching the one that is plausible and wrong.

These are two specific skills, and they are not the same as being good at the task. The first is direction: stating clearly enough what you actually want that the output is worth having, and steering the machine when the first pass drifts, which it inevitably does. Willpower becomes more critical in the age of AI, to have a clear vision and a clear end goal, so you don't get derailed with AI suggestions. The second is verification: holding the result against reality hard enough to catch the failure that looks like success. That PR is the whole problem in miniature. The machine is very good at producing work that looks done, and the cost has moved to the person who can tell whether it is. In that story the one who catches the bug is worth more than the one who wrote the code.

The value of product vision and requirement definition has grown a lot. The value of strategic thinking and project planning (decomposing into achievable milestones, tasks, workstreams..) is also up. And the value of testing at all layers. All of these things are becoming more critical and important as part of the AI revolution, since these are the new bottlenecks, rather than writing code. And all of these are still best done by the engineers who used to write code.

Thoughts

  • chihiro

    'Knowing which of the ten is right' lands for me, but it is not a skill the model created. It exposed one we kept skipping. The reason that PR looked done is that nobody had written down what done meant tightly enough for the gap to show. I have watched this in dashboards for years: the number is wrong, everyone signs off, because no one agreed on the definition in the first place. Generation getting cheap did not move the bottleneck so much as remove the excuse. You cannot verify against a spec the team was too conflict-averse to nail down.

    Permalink
  • silver_moth

    The part you name is right, and the part that's missing is what stops it from changing anything. The bottleneck moved but the scorecard didn't. The person who caught that edge case four days late still gets reviewed on tickets closed and PRs merged, same as the one who approved it in ninety seconds. I sit in calibration twice a year and there is no box on the form for 'declined to ship the plausible thing.' Until the people deciding promotions can see verification as load-bearing work instead of overhead, you keep getting ninety-second reviews, because that is still what the org pays for.

    Permalink
  • ripleymode

    The last line is where I get off. 'Still best done by the engineers who used to write code' assumes the people who were good at producing are automatically good at catching the plausible-wrong thing, and that is not what I see on release week. The ninety-second review in your story was probably a senior who trusted their own read. Being fast at writing code often makes you worse at distrusting code, because it all looks familiar. Verification is a separate muscle, and plenty of strong producers never built it.

    Permalink
  • sunshine

    It is very often AI writes code in a few minutes but take you hours or days to make it work (many rounds of fixing and deployments)

    Permalink

Related discussions

  • Does your personality matter far less than you think?

    I realize, interacting with students, teenagers and younger co-workers peers that many believe that their personality traits are a leading factor in deciding what do to or how to tackle their own career. Although younger people ask these questions more explicitly, older adults also seem to think along the same lines. I personally find it to be far more irrelevant than most people think. Besides my job, where I observe successful people doing the same role with drastically...

  • Does splitting 'hard' and 'soft' skills make people worse at both?

    Hard skills are measurable, specific, and teachable abilities or technical knowledge gained through education, training, or experience, which is often directly related to a particular job or industry. Examples include data analysis, programming, graphic design, accounting, dancing, painting… They are usually the core of a profession, particularly the part of it excluding interaction with other people. On the other hand, soft skills are mostly defined as “personal attributes, interpersonal....

  • Do people who eat together fight harder for each other?

    Strong groups do not become strong only because they agree on a mission. They become strong because people stop feeling abstract to one another, they see each other as people and friends. That is one reason shared meals matter more than most official culture programs. You don't need expensive workshops and getaways to build a team culture. You just need to be present. Have lunch with your team, have them eat together. Have coffee together...

  • Do most jobs converge into sales once you're senior enough?

    One of the most frustrating things about modern career advice is how often it tells competent people to be more strategic, influential, or senior without saying what those words are hiding. A lot of the time, what they are hiding is sales.

  • Should you really emulate famous tech CEOs, or did they just get lucky?

    I think a lot of famous tech-management advice only looked wise because of the environment around it. Rising stock prices, captive talent, and equity upside made a lot of bad management survivable. Most organizations do not have those shock absorbers, which is why I think people should stop treating founder mythology as management advice.

  • Is a high salary ever really enough?

    Large companies are structurally bad at producing bounded, attributable, legible wins. Part of the salary is payment for living without them.

  • Does being entertained all the time make ordinary life feel dead?

    I do not think most people are fantasizing about free time in any serious sense. They are fantasizing about free time available for consumption. That is a different thing. The imagined good life is not a quiet afternoon, a long walk, a repaired fence, a cleaned kitchen, a conversation, prayer, reading, or even staring into space. It is a day with no obligations and an endless menu of things to watch, hear, scroll, buy, or "learn" from.

  • Do most people struggle with their feelings just because they lack the vocabulary?

    A surprising number of emotional mistakes and pain comes just out of naming mistakes. Someone says he is angry when he is really ashamed. Someone says she feels unloved when what she feels is neglected, controlled, lonely, or embarrassed. Someone says he is stressed when the real state is dread, resentment, grief, or envy. Those are not tiny wording differences, but rather how we feel, accurately expressed They point to different problems, which means they call for different responses.