It is Monday morning on a team that made the switch to coding agents around six months ago. While the team was asleep, the agents created a dozen pull requests. Two engineers are responsible for review this week, and each PR contains several hundred lines of code they did not write and only partially understand. By midday they have approved four, quickly looked through three, and told the others to hold. Further along the pipeline the agents remain inactive, because each cycle they complete ends with a person, and that person is occupied. This team produces more code than at any previous time. It deploys only slightly quicker than it did twelve months ago. And the two engineers handling reviews are currently the most discontented engineers in the building. If any of those details feel 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.