Thomas Letan's Blog - opinions

How I Want to Use LLMs in 2026

January 25, 2026

How I Want to Use LLMs in 2026

I would like to thank Xavier Van de Woestyne for his feedback and careful review.

Agentic tools are here, and they are here to stay. I don’t think it is an overstatement to say that LLMs are completely reshaping our day-to-day life. Even if mass adoption has yet to happenWe are seeing more and more public statements from key figures of our industry like Satya Nadella or Jensen Huang trying to shed positive light on AI and pushing for more people to embrace it—probably because they don’t see the increase in active users they were hoping for. , the consequences are already here. In the software engineering industry, I already witness how they come with expectations whether we want to use them or not.

In 2025, I stayed away from the agentic hype. This month, I was made acutely aware of how transformative they can be. I don’t think there is a way back from there.

As we jump into 2026 headfirst, I consequently find myself at a crossroads. I will integrate LLMs in my workflow so that I can get the most out of what they can offer, but I want to do so consciously. Hence this article, whose tone and underlying motivation are different from my other pieces. I want to set a bar, to form a contract of sorts between me and my future self.

I want to be transparent about who—or what—produced the work I am exposing to others. I am an engineer; I can expect to generate tons of code and technical documentation using (meticulously prompted) agents. I am also publishing content online, like on this very website. The last thing I want is to trick people into thinking that I wrote something that was actually generated by a tool. Or, even worse, that they end up convinced something I genuinely wrote “the old way” has been generated.

This does not mean generated content is without value. Nor do I think there is a clear, objective line to draw between what are actually two ends of a spectrum. After all, I’ve been using ChatGPT to polish my articles for a year now, and I haven’t advertised it in the past. Still, agentic tools have become good enough: I will be in a position to describe complex tasks, fully delegate their implementation, and be confident enough to publish the result. I believe it is fair for my fellow humans to be aware of that fact when they read or review the result. Only then will they be able to calibrate their own expectations in light of this information.

As a concrete example, I have started to set up dedicated accounts for Claude Code . I am trying to come up with a reliable way to let it take over the execution of well-scoped tasks, up to responding to reviewers’ feedback on its own. That’s not an end I want to pursue unless I can be transparent about it.

I want to be deliberate about when I use or don’t use LLMs. And I have a surprising number of reasons why.

On a personal level, there are skills I don’t want to lose, craft I still wish to improve. I’m fine with never having to write a bug report directly again, but do I want to forgo authorship of my blog’s articles, for instance? Clearly not.

Besides, we are still grimly on track when it comes to climate change. Even after accepting that individual behaviors have a much less impact than what we’d like, is it really reasonable to have hours of back-and-forth with an agent every day from now on? A lot has been said and written about the impact of LLMs in that regard. I am under the impression that we recently read stories that are tragically similar to what was published about Bitcoin a few years backI had a risk management training once, and something the instructor said stuck with me: when something becomes safer, we humans tend to adapt our behavior to take more risks. Are we doing the same thing with climate change? When we manage to reduce our environmental impact, do we collectively interpret that news as a blank check to find new ways to consume more energy? .

I think one answer to this is to refuse to make the LLM the default, obvious choice. Using an agent should have weight to it. There will be times when an agent will be an enabler—achieving something outside of my immediate reachBecause it would take me too much time, because it would be extremely tedious and error-prone, or for an infinite number of valid reasons. . And there will be times when I will want to use it to write a trivial patch that I could come up with myself in a matter of minutes. I want to cultivate the discipline to make the distinction between the former and the latter, so that I avoid falling into wasteful habits.

I want to be respectful of the people who will be confronted with my use of LLMs. The matter is too complicated to approach any other way. What is acceptable for some feels like an attack on others.

Yes, agents can be powerful accelerators. No, adopting them is neither easy nor the obvious, right thing to do. We are seeing too many people being hurt by the behaviors enabled by agents’ capabilities: open-source maintainers closing their projects from external contributions, junior engineers struggling like never before to find jobs, artists witnessing in real time their art being regurgitated by models trained on their portfolios. The list goes on.

I cannot commit to never using generated art, or to close my eyes to what LLMs can bring me. But I want to be aware—and to care—about the consequences of my choices, as well as the broader context behind them. And sometimes, that needs to mean renouncing the convenience that a technology can bring, even if for just a moment.

Only time will tell how I end up using LLMs, and whether the principles I claim today as my own in this article will stand the test of time. I am rather curious to reread this piece in a year—I hope it will prompt (ah!) me to write a retrospective.

The Chaotic Debut of My Software Projects

May 29, 2023

The Chaotic Debut of My Software Projects

opinions

I am no stranger to the exciting feeling of starting new projects. By dint of repeating this “exercise” over the years, I have come to build an intuitive process which works for me. In this write-up, I want to give a try at describing it, both for future references and in the hope that this might start interesting conversations. I am curious to know whether or not my personal “process” is shared with some of my fellow developers, though I would be surprised if it weren’t the case, since there is nothing particularly clever or revolutionary with what I am about to write.

A Story in Two Acts

In a nutshell, I can often divide the early days of my software projects into two phases: the exploration phase and the rationalization phase.

The starting point of the exploration phase is a need, and a direction I want to take to address this need. For instance, the starting point of the Compact module of data-encoding was the need to encode in bytes arbitrary values, and the direction was to do that with data-encoding. For Spatial Shell , I wanted badly to enjoy Material Shell ’s user experience without having to switch to Gnome 3 and the direction was set when I discovered sway’s RPC protocol .

The goal of the exploration phase is for me to turn the direction into a destination, so to speak. When I start, my knowledge of both the problem I want to solve and the solution I am trying to build is vague, and needs refinement. There are intuitions I need to challenge, APIs I need to learn, boilerplate I need to understand. More often than not, this phase is messy. Commits are not nice, standalone units of changes: it is way too early for that. I use Git merely as a way to throw away a dead-end, and resume exploring down another path from a reasonable save point. I put most if not all my code into one file, I don’t write comments, encapsulation and abstraction become foreign words I forget about for a while. My goal is to come up with a prototype which captures the key features I am looking for, and to learn as much as possible in the process. This exploration phase shouldn’t last too long, because it is very context sensitive. If I am interrupted long enough, I am likely to lose the mental map of my messy code, and to forget the key insights I was learning while navigating it.

I want to emphasis that the exploration phase should definitely touch to the mundane, boring things like the CLI, the decoding of configuration files, the encoding of persistent states, etc. These things tend to have a pervasive impact on the rest of a software development if they are not taken into account early. Because I am confronting myself to these forbidding parts, I am forced to understand the pain points they will bring, and to plan for them.

At some point, most of my questions have found their answers, and I am starting to tackle features which go beyond the scope of the minimal set of features I was initially after. When this time comes, friction is starting to appear because of the bad quality of the codebase. All the shortcuts are coming back to bite me and slow me down, while wild bugs enjoy the lack of invariant enforcement and multiply.

This is actually a good sign: the exploration is over, and before going any further, it is time for me to take a step back and rationalize.

The rationalization phase is the unique opportunity to “learn what I have learned,” by revisiting every line of the code you have written, challenge it, and hopefully come up with a solution for its most outstanding issues. I do that by splitting up the monolithic that came out of the exploration phase into a sane, navigable hierarchy of modules with clear, manageable APIs. This allows me to fine-tune the design, to tweak the parts of the API exposed to the users (the “boring parts” I mention for the exploration phase), and to remove any dead code I thought might be useful or needed, but actually didn't cut it to the prototype.

This second phase often feels like a sprint. The second I am throwing myself at it, the project stops working, and most of the time, it won’t even fully compile before I’m actually done. This sometimes feels a bit overwhelming, though the use of strongly typed programming language like OCaml or Rust has proven to be of tremendous help, at least as long as I stick to moving code around, and only amending it at the margin. Clearly, types and compile-time type checking are my allies during what I often experience as a long snorkeling session.

When I’m done, I get my prototype working again, except it does not feel like a prototype anymore. The feature set is the same, as is the user experience. But the developer experience is totally different. I can now enjoy a codebase where separation of concerns, encapsulation and abstraction play their rightful roles, and allow me to reason about my software project more easily. This is also the moment where I can slow down a bit, since it is no longer required for me to keep the whole project architecture in my head. To a large extent, the module hierarchy does that for me.

Random Thoughts

To me, this process feels a bit like a craft. I think I have become better at going through it after every project I successfully bring at the end of the rationalization phase. And I often feel a bit at lost when I am involved in a project which does not follow this general approach.

That being said, I have to admit it does not scale very well. If the whole process does not fit in something like a week, then I will likely run out of motivation before reaching stable grounds. For instance, the rationalization phase often one to two days, during which I am basically stuck to my computer for long hours.

Finally, this process does not leave a lot of room for collaborating with other developers. This is true both for the exploration phase (the “codebase” is still a monolithic file that is partially rewritten over and over) and for the rationalization phase (sometimes it feels like I am “discovering” the correct way to organize the codebase while I organize it). However, collaboration becomes possible (and even very rewarding) after the fact, when the codebase “makes sense.”

I guess it depends on the tradeoffs one is willing to make when starting a project, the size and scale of the project, and the software developers and entities involved.

Patch Dependencies for Stacked Git

January 26, 2023

Patch Dependencies for Stacked Git

git opinions

Every time I catch myself thinking about dependencies between changeset of a software project, the fascinating field of patch theories comes to my mind.

A “patch theory” usually refers to the mathematical foundation behind the data model of so-called Patch-based DVCS like Darcs and Pijul. More precisely, a patch theory is an encoding of the state of a repository, equipped with operations (gathered in so-called patches, not to be confused with GNU diff patches) one can do to this state. For instance, my rough understanding of Pijul’s patch theory is that a repository is an oriented graph of lines, and a patch is a set of operations onto this graph.

An interesting aspect of patch theory is that it requires a partial order for its patches, from which a Patch-based DVCS derives a dependency graph. In a nutshell, a patch $P$ depends on the patches which are responsible for the presence of the lines that $P$ modifies.

I have always found this idea of a dependency graph for the patches of a repository fascinating, because I though it would be a very valuable tool in the context of software development.

I wanted to slightly change the definition of what a patch dependency is, though. See, the partial order of Darcs and Pijul focus on syntactic dependencies: the relation between lines in text files. They need that to reconstruct these text files in the file system of their users. As a software developers writing these text files, I quickly realized these dependencies were of little interest to me, though. What I wanted to be able to express was that a feature introduced by a patch $P$ relied on a fix introduced by a patch $P'$ .

I have experimented with Darcs and Pijul quite a bit, with this idea stuck in the back of my mind. At the end of this journey, I convinced myselfI am not trying to convince you, per say. This is a very personal and subjective feedback, it does not mean someone else couldn't reach a different conclusion. (1) this beautiful idea I had simply could not scale, and (2) neither I nor our industry is ready to give up on the extensive ecosystem that has been built on top of git just yet. As a consequence, my interest in Patch-based DVCS decreased sensibly.

Until very recently, that is. I got reminded of the appeal of a dependency graph for changesets when I started adopted a Gitlab workflow centered around Stacked Git and smaller, sometimes interdependent MRs.

A manually curated graph dependency for a whole repository is not practical, but what about my local queue of patches, patiently waiting to be integrated into the upstream repository I am contributing too? Not only does it look like a more approachable task, it could make synchronizing my stacked MRs a lot easier.

The workflow I have in mind would proceed as follows.

Stacked Git’s new and edit commands could be extended to let developers declare dependencies between their patches. It would be the commands’ responsibility to enforce the wellfoundness of the dependency graph (e.g., prevent the introduction of cycles in the graph, and maybe diamonds tooAt least in a first version. There is definitely value in being able to work with two independent patches in conjunction with a third one that needs them both. That being said, our goal here is to organize our work locally, and if it is made easier by declaring artificial dependency, this is a pragmatic sacrifice I am personally willing to make. ).
The series command could be improved to display the resulting dependency graph.
push and pop would automatically take care (pushing or popping) of the selected patch(es) dependencies.
Ideally, Stacked Git would get a new command prepare <PATCH NAME> which would pop every patches applied, then only only push <PATCH NAME> and its dependencies (in the reverse order). Developers could fix conflicts if need be. That is, Stacked Git would not be responsible for the consistency or correctness of the dependency graph.
Stacked Git could get commands to detect potential issues with the dependency graph specified by the developer (mostly consisting in dry-run of prepare to check if it would lead to conflicts).

Because what we want is semantic dependencies, not syntactic dependencies between patches, I really think it makes a lot of sense to completely delegate the dependencies declaration to the developerFurther versions of Stacked Git could explore computing the dependency graph automatically, similarly to what Git does. But I think that if Darcs and Pijul told us anything, it's that this computation is far from being trivial. . The very mundane example that convinced me is the CHANGELOG file any mature software project ends up maintaining. If the contribution guidelines require to modify the CHANGELOG file in the same commit as a feature is introduced, then the patches to two independent features will systematically conflict. This does not mean, from my patch queue perspective, I should be forced to pop the first commit before starting to work on the second one. It just means that when I call stg prepare, I can have to fix a conflict, but fixing Git conflicts is part of the job after allAnd we have tools to help us. I wonder to which extends git rerere could save the day in some cases, for instance. . If for some reasons solving a conflict proves to be too cumbersome, I can always acknowledge that, and declare a new dependency to the appropriate patch. It only means I and my reviewers will be constrained a bit more than expected when dealing with my stack of MRs.

I am under the impression that this model extends quite nicely the current way Stacked Git is working. To its core, it extends its data model to constraint a bit push and pop, and empowers developers to organize a bit its local mess.