AI Loves to Write It From Scratch

The token argument

Let’s say we are doing some validation. An LLM could gleefully start spitting out something like this…

if (typeof data.email !== 'string') {
  errors.email = 'Email is required';
} else if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(data.email)) {
  errors.email = 'Invalid email';
}

…instead of reaching for a validation library like zod, even if it was available.

This is just an example, and the models have been getting increasingly good at looking around the codebase for context and existing patterns. Still, I constantly see this same effect occur in some capacity, especially with bigger refactors.

From the point of view of the model, implementing things from scratch is often the sensible and token-efficient thing to do. When a model uses a library, it pays a cost that has nothing to do with the actual logic. It has to surface the right package, read documentation, figure out the API shape, and whatever else it’s unsure about. This burns a whole bunch of tokens before a single line of code is ever written.

Straight up writing the logic skips all of this. The implementation is pulled directly from the model’s weights, so there is no uncertainty present. The model knows how to write the comparator (yes, that’s the actual name), the regex, and a few closures just fine. Fewer tokens, lower risk. The model has every incentive to skip the library, as it would have to pay the price right now, on this one call, whereas a team of engineers pays it once and then reaps the benefits for the foreseeable future.

Also before anyone gets mad: yes, the model would gladly reach for whatever library is necessary if I command it, but sometimes I forget to do so, because it seems obvious that is what should happen to begin with.

Is this a bad thing?

Not always. I generally dislike dependencies that could have been reasonably avoided (super hot take), and regularly find myself hand-rolling even moderately large functionalities if it means I don’t have to add a library.

The question, I think, is more about QA (another insanely hot take). The model will implement, but you need to be the one that looks at the code, and decides if what was written is readable and correct.

Thirty lines of clear, obvious validation logic is probably fine. A hundred lines reimplementing timezone math that a datetime library would’ve done for you in three is not. You need to be aware that the build-vs-import decision is getting made for you on the basis of what is convenient for the model, not what is beneficial for the continued wellbeing of your codebase.