LLMs: You’ve become a manager, whether you like it or not
What a time to be alive, my friends! With LLMs, time seems to be speeding up. Not a week goes by without a new tool or model popping up, supposedly consigning previous generations to the dustbin of history.
I can’t deny my surprise at seeing a corporate website generated in just a few prompts—what some call the “wow” effect. This market segment is a goldmine for statistical models: no business complexity, an editorial or graphic redesign every two years—in other words, disposable code. What used to cost you €5,000 now costs less than €500. It would be a shame not to take advantage of it.
So, “Coding is solved,” said Boris Cherny, creator of Claude Code. Fair enough. I, too, like a bit of provocation, so let’s move on. The fact remains, however, that if you’re building software designed to last—an insurance information system, for example—you can’t blindly trust your favorite LLM. Code quality remains a major challenge; you can’t let technical debt take root. In other words, even if implementation becomes a mere detail, the devil is still in the details…
For my part, although I’m very impressed by the new capabilities available to us, I’ve noticed that it takes time to master these tools, which, in terms of handling, are frankly more like Formula 1 cars. More specifically, my experience with LLMs reminds me of the ups and downs of a novice manager:
-
I delegate, but I delegate too much and end up getting some real scares. With an LLM, this often means that the application works fine, but the implementation has absolutely nothing to do with what you had imagined—long live the big, ugly hack. Whether it’s humans or AI, the issue is the same: what was obvious to you wasn’t obvious to the other person. You assumed skills that weren’t there and didn’t make your expectations clear enough.
-
Or maybe I don’t delegate enough, because I’m a bit—or a lot—of a control freak, and people are gently letting me know that it would be good to let go a little. In that regard, an LLM generally gives you little feedback; it’s just that you’re not taking full advantage of its capabilities.
Ideally, a balance is established with each person, because you don’t interact with an expert the same way you would with a junior. But above all, it’s a matter of time and learning. You must train your LLM just as you would train an apprentice—what’s known as an “LLM harness.” So for me, for you, for all of us, this is a learning process we must undertake. We need to learn how to delegate—how, to what extent, and over what timeframe.
Perhaps the key here is precisely gradualism: letting go little by little. To me, this learning process bears similarities to Test-Driven Development (TDD), the essence of which is to make very small changes (the famous “baby steps”) to solidify what’s been learned at each stage. What we want to avoid at all costs is writing a lot of code—optimistically—only to realize in the end that nothing works. TDD prevents such a buildup of bugs by seeking feedback frequently.
It’s the same with an LLM. You can indeed launch an entire orchestration of agents collaborating with one another. Except that, if you don’t take precautions, you risk getting a disastrous result and concluding that these tools don’t work. It’s better to start with simple, standalone tasks that will give you and the LLM the opportunity to document the codebase (CLAUDE.md files) and teach it how to proceed (SKILL.md). Only then can you begin to put the pieces of the puzzle together by parallelizing tasks with multiple agents working together to develop a feature.
Using an LLM puts us in a managerial role, and leading a team—whatever form it takes—is a skill that can be learned. Letting go is part of the equation, and it’s a sliding scale: it’s up to each person to set their own boundaries. For my part, since I’m very particular about code quality—especially since I work in an environment I know like the back of my hand—I still insist on rereading every line of code it produces. I spend a lot of time setting up Claude Code in advance to make his actions as deterministic as possible. Developing therefore remains a labor-intensive activity—or, to put it another way, let’s say that my “wow” factor is more gradual than for others. But even with this very cautious approach, I sometimes accomplish in two hours what would have taken me a whole day.
Sometimes, on the other hand, I have such a clear idea of what I want that specifying it in writing would take me longer than just doing it—with the risk that it might not turn out as well. This is especially true when I’m working at the heart of the domain, using TDD. Should I then do it myself, or invest a little time to teach it to do it for me?