Caring for LLMs

I read an article saying that code has become cheap. What used to take weeks can now be generated in hours. Impeccable documentation, well-organized code, complete READMEs: anyone can produce them. The value, the author says, now lies in the ability to articulate problems, not in writing syntax.

I agree, but I think it falls short. Code was always the easy part. The difficulties of software were never mainly in the writing.

What has changed

At Dcycle we've been working intensively with Claude Code and similar tools for months. The changes are real and deep.

We've lowered the barrier to code. Many more people contribute. Teams that could only request things before can now solve them themselves. Response capacity has multiplied. Autonomy has grown.

The obvious capabilities are there: exploring code, fixing bugs, generating documentation, writing tests. But there's also a less visible dimension, almost emotional. You know you can always expand your perspective. That there's a dialogue available that enriches you and pushes you to think better. That changes how you face problems.

The funnel has shifted

For decades, the bottleneck was in code production. Few people knew how to write it, and those people were the scarce resource.

That bottleneck has moved. Now the narrow part of the funnel is elsewhere: in pull requests, in review, in the ability to integrate new code with what already exists. Writing code is easier; merging it well is still hard.

Dan Shapiro calls it technical deflation: the cost of technical work is going down. Technical debt doesn't weigh the same because fixing it will be cheaper tomorrow than today. What used to be a painful decision—cleaning code, refactoring, improving architecture—now has a decreasing cost. But that doesn't mean it disappears; it only changes the calculation.

We've also seen something we didn't expect: new contributors force you to improve your foundations. If you want more people to contribute, you need better local environments, better documentation on how to set things up, better ways to test that code works before merging it. LLMs don't eliminate that need; they amplify it.

What hasn't changed

The difficulties of software remain the same. Information is still precarious. Problems are still poorly defined. Uncertainty is still constitutive, not accidental.

I've written before about why software-based products are so difficult. Black boxes are still black boxes. Software still dissolves our aspirations for control. What we can't see is still more than what we can see.

LLMs are, in fact, the black box taken to the extreme. No one can explain exactly what happens between input and output. Using them well requires the same skills we've always needed to work with software: representing the problem space, making assumptions explicit, resisting the temptation of premature certainties.

Caring for LLMs

There's something about the expression "using LLMs" that I don't like. It suggests extraction, exploitation. I prefer to think about caring for them.

Caring for them means creating the conditions for them to work well. Feeding them good documentation. Giving them enough context. Maintaining codebases they can understand. Writing for them just as we write for the people who will come after.

It's the same thing we always knew we should do, only now there's an immediate reason to do it. LLMs give back what you give them. If you give them disorder, they return disorder. If you give them clarity, they multiply that clarity.

The same story

The internet was always about bringing more people into these kinds of capabilities. We all started that way. Some in Visual Basic, others in PHP, others in JavaScript. Each generation of tools lowered the barrier to entry and allowed more people to participate in building.

LLMs are a continuation of that story, not a break. Another turn of the screw in the democratization of software. More people will be able to contribute. More teams will be able to solve their own problems. Code will be cheaper.

But the hard questions will remain hard. What to build. For whom. How to know if it works. How to live with the uncertainty of not knowing for sure.

Code was the easy part. It always was.