It is Monday morning on a team that switched to coding agents about six months ago. While everyone slept, the agents opened a dozen pull requests. Two engineers are on review duty this week, and each PR is a few hundred lines they did not write and only half understand. By lunch they have approved four, skimmed three, and asked the rest to wait. Out in the pipeline the agents sit idle, because every loop they run ends at a person, and the person is busy. This team writes more code than it ever has. It ships barely faster than it did last year. And the two people on review duty are quietly the unhappiest engineers in the building. If any of that sounds familiar, this post is for you.

Table of Contents

Nobody is coming to plan your career for you. The industry will happily let you drift: take the next role that opens up, learn whatever tool lands in front of you, stay in the city you happened to grow up in, and find out at the annual review whether any of it moved you forward. Drift can look like progress for years, because the job keeps getting renamed around you, analyst, then data scientist, then machine learning engineer, now AI engineer, and a new title feels like movement. It is not. Looking at the people who have genuinely accelerated, in data, ML, AI, or traditional software, the acceleration never came from the titles. It came from a handful of deliberate choices that most people never consciously make, and that is what this post is about.

Table of Contents

Anthropic recently deleted more than 80% of Claude Code’s system prompt for its Claude 5 generation of models. Their coding evaluations did not get worse. They did not get better either. Four fifths of the instructions that a frontier lab had built up around its own flagship product turned out to be doing nothing at all. The obvious question is how they were able to cut so much. The more useful question is why the rest of us have not, because the same kind of instruction is still sitting in your CLAUDE.md, in your agent’s system prompt, and in the sentences you type out of habit.

Two models forecast daily demand for a bakery. Model A has the better RMSE. Model B makes the bakery more money, every single week. If that sentence sounds impossible, this post is for you: the evaluation metric you pick is not a scorecard bolted on after training, it is the specification your whole modelling effort ends up satisfying. Kaggle grandmasters internalise this to the point that studying the competition metric is their first act in any competition, and the habit transfers directly to real projects, where the difference between a metric that encodes what the business actually loses and one that merely sounds standard can make or break the use case.