3 lies of LLMs

It's been a while since I wrote about LLMs; let's have a new entry.

Billionaire solopreneur

Let's be honest with this one because this log was written a few months ago, so let's talk about Matthew Gallagher.

We can argue, for instance, that he is not a billionaire, even though it is planned to be one soon, not to forget his business will be valued for a billion.

We can also argue that he didn't build his product alone, even though there were only a handful of permanent people working on it, but for the sake of the argument, let's say it is halfway there.

I have a hard time thinking of it as a positive thing, even putting moral considerations aside.

For instance, if you have a critical part of your process that is relying solely on the existence and the good health of one person, you're at risk.

In modern software engineering practices, we call it the bus factor.

We most often talk about it regarding the internal staff of our company or of the team.

For example, there is only one person who is knowledgeable about this technical piece of your whole system.

In FOSS, you can fork the repository and maintain it yourself; I did it along those years.

Here, we are talking about an entire company; you can't just fork it.

You would have to redo it if it is even possible.

LLMs are harmful

Everyone should be concerned with the recent vulnerabilities discovered or at least spread over the Internet regarding security and LLMs (here and here).

To be honest, it's a bit of a disappointment because, for instance, the security and software have been really intertwined for the last eighty years.

Software has never been neutral, and it was always subject to the benevolence of its creators.

For example, IBM sold some tools that were used during the Holocaust, e.g., facilitating the regime's Jews census.

Note: even though it's not really comparable, and you could perfectly argue that if you were to face this kind of existential threat, you would be on the right side of history; in my previous experiences, I had strong arguments with my managers or CEOs who wanted to add, for example, some tracking mechanisms or something that were either against the law or against the moral statement of their products.

Beyond this, software is not immune to bugs, and even with the strongest investment in quality and zone support, there are always holes that are now far cheaper to exploit. Consequently, it is not that elements are more harmful than they were existing previously; LLMs put them in plain sight.

LLMs will replace developers

This one makes me laugh so hard each time I'm thinking of it.

Of course you can say that generally we are spending as a developer, or even better, as a software engineer, is dedicated to writing code.

Most of my time is spent talking to people, aligning with stakeholders, and trying to fix bugs, even though LLMs can now do it. Believe it or not, but most of our work is being able to find the consensus of what are the most relevant things to work on and how things should be and not only how things are.

When this milestone is finally reached, I have to produce code, ensure that it puts the nonfunctional properties we decided on as a team; then I have to make sure it is being deployed, and then I have to make sure it is used, or if not, find out why it stands, gather the feedback, and so on and so forth.

So my scope as a software engineer is much broader than just writing a lot of code and just pushing it through the wall.

Not to mention that for the last four or five months, every single week I get proposals on LinkedIn from people who are asking me to rework their vibecoded “products” which are barely working, which are barely deployable, and who they are basing their hopes on.

Of course, I don't know the future; I don't know what it will be made of, and probably these promises will be fulfilled in the near or long future; but as of today, my conclusion from the fact I am gathering is that we are far from this.