Transcription
Sicily is like this: when there is bad weather in Sicily, it is not the bad weather of the north where it is cold, that perhaps continuous, gloomy rain. Here come the storms, the thunderstorms, the phenomena, those, let's say, violent ones. Sicily is like this, it is always a multiplier of things. Good people are particularly good. Bad people are particularly ruthless. Desserts are sweeter, negative things are incredible, bad weather is the worst, the heat is sometimes truly incredible. And so when I went out to get... because since the schools were closed for days, my daughter with a dear friend of hers had a continuous party where they slept one night at her place, one night at mine, and they had fun. So at a certain point I went to pick them up, and everything seemed normal, let's say normal bad weather. But if one looked at the ground on the road, one saw that there were two-three cm of very fast water flowing downhill, that is, towards Catania, and every pole it encountered, a crest of a meter would rise. So everything was normal except for this detail that caught the eye, because you don't expect water to have this speed to create these crests every time there is an obstacle sufficiently difficult to overcome, and therefore it rears up in that way. Obviously, this flow speed also has the effect of destroying the asphalt, of ablation. Like a spoon digs and these holes are made, which then have to be fixed with small patches of tar that will obviously come unstuck the next time. Today is a beautiful day, I'm in short sleeves. All the technology in this car means that if there is a drop in tire pressure... since this car is all displays, right? Since I have to see the pressure drop, I can't see the outside temperature because the icon replaces the outside temperature indication. And there is a small design problem. But this is precisely what I wanted to talk to you about in this video: the fact that the software has fundamentally changed forever. I am more and more convinced of this, but now we will see that there are completely new dynamics that have emerged recently, which we have discussed several times on this channel, but it is one thing to hypothesize, to launch into a near future that has not yet fully materialized. Another thing is to be in it, so the topic must be revisited. To start with, there is this idea of automatic programming, with which I am gaining some experience and for which I will follow my usual approach: to base myself on the evidence of things I see rather than on the collective narrative made in fear of these very things. Automatic programming... when they tell you "Ah, yes, now with coding agents you do a lot of work, and then there will be junior developers to fix the misdeeds." This is one of the biggest mystifications that can be made. This is unthinkable with the current state of the art of coding agents, because they get stuck in situations where, most of the time, junior developers would not even have conceived that code, let alone made it work. There is such a profound gap between what generative artificial intelligence can do in the field of programming at the moment and what a programmer with little experience is capable of doing. The truth is that if the coding agent was followed by a mediocre programmer, it will do enormous damage, just as that mediocre programmer would have done enormous damage. And then obviously someone else will be needed to fix them, but this someone else must essentially be either another mediocre programmer with more expertise, more discipline, who slowly tries to fix these things... but anyway, the problem was that the other one who did it (or she) was bad. Because at the moment, if coding agents are used well, they get stuck in issues that are truly complicated even for human programmers in most cases. Therefore, this mystification is an absurd thing. It would create a bottleneck where all the advantages due to the fact that you can create a lot of code quickly with coding agents would then be negated by the fact that this code is completely full of bugs, and then the bottleneck would be all these juniors who have to solve these problems. So there would be no streamlining, but everything would return to the previous situation. Among other things, the world seemed to be full of buggy code: as we said, the "enshittification" that occurred in programming predates the phenomenon of automatic programming by many years. I believe, among other things, that instead of seeing a worsening of things from this point of view, we will see a clear improvement. And I'll tell you why too. Because the average company before saw, for example, when it commissioned software for the bank through a chain of commissions, that it was a continuous stream of overpaid and incapable PMs who made calls to other PMs at the next level of the company, who then scolded the bad programmers they had hired (or trying to pay them little, or recommended, or whatever you want). In the end, for reasons of time and cost, the less serious bugs were overlooked and let go: "patience, the user will deal with it, it more or less works and we can deliver it. We take this money (which 10 companies before us have already skimmed off) and that's it." Now things have changed. To begin with, many levels of Chinese boxes will be avoided, because those who take on the contracts may delegate to companies that are capable of doing more and better with automatic programming, without in turn asking this or that company to do parts. But especially if there is a quality problem in the code of a feature (this doesn't work, that doesn't work) that can be solved with a bit of prompting, it seems quite easy that these things will be resolved. So, productivity in software code has increased forever, unless there are laws or system settings that then deny the advantages because they prohibit... or like the AI Act here in Italy, or someone who tells you that for some professions at least 50% plus one of the work must be done manually, etc. If these things are not in the way, productivity has now increased tenfold, let's say by an order of magnitude, roughly. So it is clear that in any case systems will align towards doing more, just as the mechanization of agriculture has significantly reduced malnutrition. So, if you see some software defects as malnutrition... because let's be clear, bank software is an archetype for me of the least interesting thing in the world and done as badly as possible. Even the software of a large bank, and even the large bank that no longer wants people in branches because branches lose money and time, when it comes to software it's awful. So it's an archetype of the "rottenness" of global software. Even in that case, however, the increase in productivity will cause less "qualitative malnutrition" and in my opinion things will work a little better. There are features that cannot be done now due to these mechanisms I mentioned earlier, which will be done instead. For example, here's another thing about software "rottenness": never mind that everyone has given me absurd conspiracy theories about why Airbnb doesn't give you visibility, for example, on how prices have gone over the years you've used the platform if you have a house for rent. So I had to create software that extracts this useful data for myself. Never mind those who say "they don't want you to see it"; no, there's a limit because they can only produce a few lines of quality code per day, and so they decide not to do many things to avoid having other things to manage. Because Airbnb, in my opinion, is a dysfunctional company, it shows from many points of view: from the point of view of its software production, I don't want to say at a socioeconomic or political level, but even at the software production level something is wrong. All this makes me think that there will be a change. And no, it won't be junior programmers who will fix the damage of things they don't even understand, because you quickly reach a high level of complexity. I am truly touching all these things firsthand in two different contexts. One is that of Redis, in which I launched myself into doing things that were very boring and nobody wanted to do, and I made pull requests that simply improve the system. And another is this project here... apart from other open-source projects on which I have used automatic programming to improve them, to move them forward, to merge pending pull requests, to realign the code with other forks. I have made some implementations and so on. But this thing I did with Flux 2 inference, which I talked about in the last video, has opened my eyes even more. Because in reality it is hyper-specialized code, far from junior developers to do those things and optimize them! Because inference itself is a fairly simple thing, it's the kernels that do the usual multiplications. But then to make massive speed optimizations, for example for Apple Silicon backends (so what is MPS, Metal, etc.), it's a mess. Just as it's sometimes a mess to do the necessary instrumentation for debugging, to see if the tensors are exactly the same as those generated (obviously more or less some rounding error from the different floating-point stack used), but to match the official implementation and see that there are no bugs. Because these models in general... neural networks are quite robust, in the sense that compared to traditional algorithms where if there's an off-by-one error, very often everything stops working, with neural networks things are a bit different. If you make a mistake in the inference pipeline of an image generation model, just a little bit, say, you make a mistake with the scheduler... instead of using the Flux 2 Schnell scheduler. What is the scheduler? It follows each denoising level: how much further we are in the image's progress, if we are almost at the end and want the complete image, or if we are at the beginning where there is only Gaussian noise and we want the first steps to form. Flux uses a deeply non-linear scheduler because Flux 2 Schnell is a distilled model from a larger model to create the image in very few steps. In four steps you can create images, so there is a scheduler that is highly non-linear. If you get the scheduler wrong, it's not that the images don't come out; they do, you see them, they look okay enough, but they are not of the quality they should be. You risk introducing quite subtle errors that, however, if you have great instrumentation, for different pipelines you can see exactly what the difference is with the Python output. So, all this stuff is a mess to do, because you have to make a lot of tools, you spend time on it, and so on. And even in that case, it was incredible how the combination of Cloud Code with Codex, especially GPT 5.2 (or "extra high" models), for the most complicated parts, constituted a resource. I practically use Cloud Code to get 80-90% of what I need. Then I use the "freshness peaks" of Codex, where Cloud (which is that reliable worker but sometimes lacks genius) doesn't reach. Instead, there's this crazy reckless GPT 5.2, which in itself is a very aligned model, but in its agentic version it overdoes it and you don't know what it's doing, but it has these peaks of flair that manage to follow me sometimes in things the other can't do. To give you an example, another thing that can make a difference is the VAE, which is practically what slices the image into 16x16 blocks to reduce its subsampling (otherwise attention would be a mess to do pixel by pixel). So we create semantic, geometric-semantic representations of 16x16 pixel blocks and then we do attention. Which, by the way, is not the attention of language models (done only with the tokens that come before), but is done with all tokens. And there, if there's an error, you see subtle differences in the image that are very difficult to debug later. So all this stuff... but which Junior? Obviously, in the hands of those who know how to do things, this remains constant. But the fact is this: even the junior who technically remains junior, if they become better at using language models properly, if they understand the processes well, they can do better than what they did before. Now I'm going to the gym and then I'll continue. But do you know that this fringe is really ugly? Damn it, I'll get home and cut it. But where were we? Later, guys, there's monstrous heat, horrible heat, solar heat with palm trees. It's too hot, you can't stay like this: first the storm, then the heat. But what are we supposed to do? So, I made this premise about the Junior programmer because I think this puts us in the right perspective to somehow warm up, to take the right position among the arguments that will contribute to giving solidity to what I am saying now: namely, the death, the end of the small software company. If not the one that addresses a public of people who have absolutely no idea what can be done with AI; but even that will die from overpopulation of the sector, so it won't die in absolute terms, but it will die of hardship and is destined to die anyway. Why do I think the small software house is finished? Because today we are in the phase where the IT professional used to say "Okay, but what does it do? You buy this software to normalize your MP3 files?". The very first thing that comes to mind. "But you know that if you use FFMpeg from the command line, a normalize script will get them all to the same volume." I'm talking about a dynamic from 10-20 years ago, because this came to mind as a utility one might buy. But let's also take another case: Grammarly, for example. Sorry, between the sun, the shade, the effort of lifting weights I did, it came to mind... pausing Grammarly. You pay because you need it, it's useful, you can't make spelling mistakes, you don't want back-and-forth. Now that artificial intelligence is at your fingertips, probably someone still pays for Grammarly, but the problem is that replicating Grammarly for the user, for its basic features, starts to become half a day's work. Many will say "But I'll do it myself? I'll install it or just use it myself." But this obviously won't cover the majority of users. But after you make it yourself and install it, some might think: "But you know what? I'm close to being able to make a competitor." Then it takes you a month to really have a presentable product, because AI is this: instead of taking a year, it takes you a month. But to have something presentable to the user that is interesting, well-thought-out, it still takes time. But if it were 10 months, you wouldn't have done it, instead you did in those two days what you need at a minimum for yourself. Then in 15 days, a month, you've made the website and you say "But you know what? I'll start competing with them and even if I ask for a tenth of their price, it's still a side project that earns while I sleep." "Make money while you sleep." This is very much in the American mentality of creating a passive income, but not the passive income that the European/Italian thinks of (investing in bonds or renting out houses), but an entrepreneurial passive income where with minimal effort you still have an interesting passive gain. Now, if something like this starts to happen more and more on a large scale (and I am sure it will), what happens is that these types of companies are no longer sustainable. They will become companies that may still exist, but made up of individuals who have a product that at a given moment becomes more widespread than others due to "happy things coming together": word of mouth, the fact that it is well-thought-out, some fun insight that captures the human being in us. I'm turning up the air conditioning, otherwise I'll die. But essentially that type of industry is no longer sustainable. Where does this money go? Because as long as the other sectors don't implode... and it's clear that programming will be one of the first sectors to be deeply mechanized. The others not because they are not automatable, but we have always been one of the "non-professions" and that has also been our fortune. What about other professions, the lawyer is in my opinion the archetype of the replaceable who will not be replaced soon: they have much deeper ties with the state, with the laws, which will ensure that for regulatory reasons there will be strong inertia. But then when it happens, the lawyer and the female lawyer will not be ready like the programmer, because we have seen this thing being born, we are in it, perhaps we will find our way to react. But we will be among the first to be affected in this small company mode. Large companies, on the other hand, need these agents to work; large and medium-sized companies need those who have product insights, also those who know what is technologically possible and how this technological possibility can be embodied in things that the user likes and for which the user will want to pay. But as long as the rest doesn't implode (and it will take a while), there will be those who buy software, so I don't think there will be a collapse of software companies overall. So on one hand, many software companies that are currently small/medium will become single individuals or little more, or people who won't care about going towards credit, VC, investor money and that's it. It's you and your partner and you earn those 2 million euros without needing to grow, as long as this game is possible. On the other hand, it will happen that the medium-sized company risks becoming stronger. The well-positioned medium-sized company, which today cannot compete with Unicorns or Mid Caps, will grow again. With artificial intelligence they will grow again, if there isn't, on the part of large companies (which perhaps become AI monopolists), a capacity to suck the blood from medium-sized companies that increasingly need models. But I repeat, I don't believe much in LLMs being so centralized, based on what we have seen so far, and I have also given you a thermodynamic argument for why I don't believe it. Neural networks are machines that have strong equivalence across various architectures; even if some work better than others, in the long run you find the right setup, because the basic principle remains the feed-forward core and other mechanisms that were invented long ago, including attention and so on. And they are extremely flexible: the attention or convolutions that I implemented in Flux for inference are no different from the same concepts found in other neural networks. The VAE is deeply convolution-based, but then Denoising is a transformer. The same as the LLM does something completely different. That is, you see that these things are not so much about finding the exact architecture, but it's a matter of scale. Therefore, for this reason, if you don't have the magic recipe and it all depends on having a large training set and many GPUs, this thing will sooner or later become a commodity. Becoming a commodity, I don't think medium-sized companies will be drained by these costs, also because they will have a reduction in the costs of various services from people they currently use and who cost them a lot. Programmers could also be much more important in their quality for medium-sized companies, which do not need to scale like mega unicorns, the "Hyperscalers," and destroy everything. I don't think the desire for personnel will be exhausted because with artificial intelligence they can try to dominate other fields where they have remained external. But what will happen to medium-sized companies, in my opinion, is that they will partially engulf other sectors. Because you know what they used to say: "software is eating the world," but software will eat the world much more than it has so far. Airbnb is a company that uses software to eat the real estate world. PayPal is a technology company that uses software to eat the financial world. Tesla is a technology company that tries to eat the car world, and so on. And in my opinion, the dominance of software, now that software production is semi-automatic, will become increasingly strong. This is what I see. Now they are calling me... I was saying. So: a compression, a dying off of small software companies that take little time, and an engulfing by the software industry of other industries. Probably, if the big Hyperscalers succeed, we will also see their ambitions increase immeasurably. Their already hypertrophic ego will become even bigger. They will try, since they now have the bandwidth to develop more, to cover other sectors as well. But I also hope that with... Well, Google is deeply dysfunctional so I don't believe, for example, that they will innovate in email again, also because they already have a monopoly and don't need to do anything. But, for example, something that can happen is that medium-sized companies can say: "Ah, but you paralyzed key products for me for years? Well, now I feel like entering that market because since the development cost can be amortized much better..." And a sentiment of "de-googling," of distancing oneself from these mega-companies, begins to grow more and more. I exploit it, and therefore the scenario within software becomes more fluid in my opinion. But anyway, there will be plenty to see. Then I wanted to talk about AI policies that are starting to emerge in various open-source projects; I had already talked about it, but now the discussion becomes really imminent, from its utility it becomes imminent because now we all have to equip ourselves with policies. Or we have to decide, as I have decided, not to equip ourselves with AI policies. Then my company can decide otherwise, but in that case my position remains different personally, because I am convinced that quality matters and not trying to look at a pull request to find out if it was made by artificial intelligence or a human. I would distinguish between pull requests that suck and pull requests that are good, useful, opportune, well-written. Anyway, we'll see.