A Hammer Named Claude Code: Choose Your Nails Wisely

The law of the instrument: we all have our biases

It was A. Maslow (yes, that one) who formulated this cognitive bias:

If the only tool you have is a hammer, it’s tempting to treat everything as if it were a nail.

It’s the Law of the Instrument, and it’s wreaking havoc in our profession:

I’m a front-end developer, so all the logic in my applications is implemented on the front end, in the browser. That’s how I was taught in bootcamp. The back end? You mean the code that lets you talk to the database? (By the way, I got into development through front-end work, which earns me constant teasing from close friends. It’s my original sin, my cross to bear as a developer.)
As for me, my thing is the domain, modeling, and DDD. SQL, on the other hand, not so much. So for my one-to-one relationships, I query the database once; that gives me the foreign key, and then I run a second query. For one-to-many relationships, I’ll let you guess how I do it. Joins? By hand, my friend, in the domain (I’m speaking from experience, of course; I wouldn’t have come up with that on my own).
Me, on the other hand, I think SQL, I live SQL, I am SQL. SQL is everything. My dog’s name is Sequel. The domain? No problem, I’ve got it covered: stored procedures and triggers. It’s convenient: everything happens in the database. Coupling? What coupling?

And, of course, these days: “Why are you doing that by hand? Use AI!” The Law of the Instrument is experiencing an unprecedented resurgence thanks to LLMs. Claude Code and Codex are our new hammers.

TDD x LLM

At this point, let’s clear up any misunderstanding: saying this is by no means a rejection of LLMs, but rather a suggestion to use them wisely. The hammer isn’t the problem. Rejecting LLMs on principle would, in fact, be yet another bias—yet another hammer.

Let’s take the core of the system, the domain, as an example. It contains the business rules, which often makes it a critical component that cannot tolerate errors. When you implement an algorithm for executing market orders, a single error can cost hundreds of thousands of euros.

We often develop the domain using TDD (Test-Driven Development). The idea of an LLM doing TDD is appealing, since each step requires writing code with constraints that are quite distinct from those of the other steps. There’s potential to specialize several agents:

“Red” agent: write a single test, without worrying about the implementation (aside from the function signature), and verify that it fails;
“Green” agent: pass the test as quickly as possible by deliberately taking certain shortcuts;
“Refactor” agent: improve the code without adding any new functionality.

You’ll also likely create a skill to alternate the focus between each agent and ensure the domain is developed properly by effectively balancing triangulation and generalization.

You can do all of that. But that doesn’t necessarily mean you should.

The Cost of Getting It Wrong

Once the test is written, implementation is easy, because tests provide binary feedback (they either pass or fail)—any LLM can do that. The hardest and most critical part is actually writing the next test, because tests specify the expected behavior. Garbage in, garbage out. The danger is that an LLM can quickly give you the impression that everything is fine—all the tests pass—when in fact the implemented behavior is wrong!
We also know that, as fatigue sets in and we let our guard down, we tend to skim. That’s generally a bad idea, but even more so when it comes to the domain. The more critical the subject, the more it deserves our attention.
Finally, more broadly, developing certain parts of the codebase ourselves, without relying on LLMs, is necessary to maintain our skills. Hands-on practice remains essential for understanding some of the finer points of the craft, which will then allow you to better challenge the LLM (in other words: to be better reviewers).

Boilerplate code, glue code, throwaway scripts, end-to-end tests we’ll toss out tomorrow… These types of development tasks are perfect use cases for LLMs. But delegating the core domain to an AI is tantamount to outsourcing the company’s most strategic knowledge and losing the internal capacity to challenge the machine. Therefore, if you absolutely must use an LLM to develop the domain, delegate the Green and the Refactor, but please, not the Red!

More generally, the universal remedy for the law of the instrument is training. Avoid blind spots, just like with competitive exams: you don’t need to be excellent at anything in particular, but don’t skip anything. Master your architecture and your tools from A to Z.