AI

2026-07-08T09:00:00+00:00

This post is about my thoughts and reflections on AI and on how it has changed our lives. I promise I won’t write about how to become more productive, how to use the various models properly, and so on in that vein. It seems to me that such articles, useful as they are, do nothing to help us look into the future.

A little about me: I’m a programmer, I love my work, I use AI every day, and this post is my personal opinion.

My perception of AI went through all the stages of accepting the inevitable (the Kübler-Ross model) — denial, anger, bargaining, depression, acceptance. I suspect that for me, and for many others, these stages came all mixed together, sometimes displacing and replacing one another in no particular order.

Fig. 1 — Carry on; nothing has changed

Stage 01Denial

Denial was the shortest stage, because it was clear that the models would keep getting better, working faster, and occupying more and more niches. What I didn’t foresee was that this expansion would happen so fast and affect our lives so profoundly. Today a single announcement from Anthropic can move markets and crater the share price of once-successful companies, while the valuation of any company with the faintest hint of AI shoots to the moon.

Stage 02Anger

Anger set in when image-generating models arrived. It was obvious that everything they produce was built on the labor of many thousands of artists and illustrators whose work had been used for training without their consent. You can argue about the legality of this method and its ethics, but it led to the following consequences:

creating graphic content became practically free;
original works became indistinguishable from AI output;
authors lost the motivation to publish their work in the open.

These consequences strike me as deeply important, because we’ve ended up in a situation where the growth of visual culture is being crushed by the growth of technology. Art isn’t just about “pretty” — it’s about a person’s view of life, expressed through their work, and right now authors have no incentive to share that view.

Why would an illustrator publish a piece that took a week to make, if something very similar can be generated in a second — and if their work will be used to copy their style? In the process, we lose something I consider essential: the human view of the world. However good machines and algorithms may be, we are very unlike them, so it’s strange to expect them to have a view of the world of their own. They have no view, really, because they imitate rather than see; and yet their imitation eclipses reality through its availability, its cheapness, and its polish. I don’t know about you, but personally I find it a thousand times more valuable to encounter the imperfect but human worldview of a small creator — a person who poured a personal experience and a part of their life into the work.

Stage 03Bargaining and depression

Depression, with elements of bargaining, set in when it became clear that models can generate very good code. I think every programmer who loves their work has been through this stage. On one hand, you realize a model is taking away the work you love; on the other, there’s nothing you can put up against it on your own — it’s rather hard to compete with an immortal machine that has had billions of dollars poured into it and whose technical specs (memory, energy consumption) simply can’t be compared to a human’s.

Over time, as I worked with models more, I noticed that writing code had receded into the background. What moved to the foreground was planning functionality, the ability to grasp the overall structure of a project and its direction of travel. In effect, the programmer got a promotion: writing the code is delegated to the model, while the plan is created by the human together with the model. This used to be the job of project managers or team leads, whose role was to coordinate team members for more effective work. Now that development has sped up and most technical problems are solved individually, the need for a large team — and therefore for its managers — drops sharply, because teams get smaller.

Another important consequence of faster development is the erosion of what it means to “own the code.” Where once, on large projects, critical chunks of code were owned by an Alice, a Bob, and a Carol, today no human owns them at all — simply because the code wasn’t written by a human. We try to solve this by covering the code with tests and building various layers on top that check the project against our expectations, but that masks the problem rather than solving it.

The problem can be stated like this: “for any company that prioritizes the speed of building its software product and uses AI to build it, the level of code ownership will tend toward zero.” I’ll call this maxim “Goncharov’s law” :-)

For any company that prioritizes development speed and uses AI to build its product, the level of code ownership will tend toward zero.

Experienced teams understand this, which is why some open-source projects spell out an explicit policy on the use of models — written not by Luddites who oppose progress, but by people who understand that fully delegating responsibility to a model is a road to nowhere.

The erosion of code ownership has both obvious and not-so-obvious consequences.

First consequence: models let people build structures, code, and products that were previously out of their reach.

For developers, this means they can build more complex products quickly. For non-programmers, it means they can build products at all.

It seems to me that this simple fact has been misread by many of the people involved. On one side, programmers think, “we’re done, a machine can do our job.” On the other, non-programmers think, “who needs programmers — I can build product X myself.” In reality, what I personally observe is somewhat different: the trouble shows up for “simple” products and solutions. Such projects really do run into problems quickly, because users can build a free alternative to the product themselves.

By “simple” I mean the ease of copying and reproducing the entire product — which is not at all the same thing as the ease of writing the code. And that’s because, in many cases, the code isn’t the product. Incredible, but true. A product is a packaged, well-presented solution to a user’s problem, where the information about how to build that product is only one part of the solution — and usually not the most important part.

I can see the skepticism in your eyes. Let’s run a thought experiment. Imagine some very large, very successful corporation has created a wonderful, wildly successful product using secret ingredients known to no one. No one can compete with it, because its product is so good that no one can reproduce it. Now imagine that one fine day you learn the exact composition of the product and how it’s made. You realize you have the ingredients and the knowledge needed to produce a full copy of it.

I have two questions for you:

Do you think you could replicate this company’s success armed with that information?
What would happen to the successful company’s stock?

Think — don’t read on yet. Think, and answer these questions honestly. Please, think a little longer.

The questions above aren’t hypothetical. On January 8, 2026, a user going by the handle LabCoatz posted a video explaining how he had almost completely reproduced the recipe for Coca-Cola. I have to admit the video and the approach are excellent — the author really did crack the secret of how the drink is made. But do you think this hurt Coca-Cola — did the company suddenly face a dangerous competitor, or did its stock drop because the world had learned the drink’s secret? Nothing of the sort (KO on Yahoo Finance).

Fig. 2 — Coca-Cola (KO) share price in the first half of 2026. The dashed line marks January 8, when the recipe was reportedly reproduced; the stock kept climbing rather than falling. Source: Yahoo Finance

The explanation is simple: the secret and the strength of Coca-Cola were never in its ingredients. They rest on belief in the product, on how it’s advertised and distributed. This simple fact is usually lost on the layperson. Here’s another fact: in 2021, at a press conference, Cristiano Ronaldo pushed a bottle of Coca-Cola aside with the word “agua” (“water”), meaning that he prefers to drink healthy beverages — after which Coca-Cola’s market value fell by 4 billion dollars. Doesn’t it strike you as strange that after the recipe for Coca-Cola was published its stock didn’t fall but actually rose, and yet it fell after a well-known figure publicly cast doubt on how healthy it is?

Let’s run one more thought experiment. There’s another successful company making a very successful product X. The product is digital, and at some point you discover that you can reproduce it with the help of models. Again, I have two questions for you:

Do you think you could replicate this company’s success armed with that information?
What would happen to the successful company’s stock?

I won’t waste your time; let’s go straight to the answers.

I had Duolingo in mind. It makes a very successful digital product. After powerful models capable of writing very good code appeared, here’s what happened:

no strong competitor to Duolingo emerged;
the company’s stock fell threefold, despite strong financials (DUOL on Yahoo Finance).

Fig. 3 — Duolingo (DUOL) share price over five years, marked with the biggest model announcements from OpenAI and Anthropic. Source: Yahoo Finance

As with Coca-Cola, Duolingo’s secret was never its code. For both companies, the real secret was the original innovation (the drink for Coca-Cola, the idea of language learning for Duolingo), and from there the secret flowed into how the product is distributed, advertised, and developed. So even if today you could reproduce the technical part of Duolingo’s product, you still couldn’t reproduce the whole product.

Second consequence: the less a person owns the code, the harder it becomes for them to steer the product as its complexity grows.

Building any software product almost always comes with growing complexity. That’s because the product is being adapted to constantly changing external conditions, and that adaptation demands more complexity. Every additional feature makes the application’s code more complex, not simpler.

In other words, anyone using AI to build a project can increase its complexity — but only up to a certain level.

Let’s run a thought experiment. Suppose there’s a person X, not a programmer, who wants to reproduce some software product. Do you think they’ll manage it or not?

Of course, it will all depend on time, on the person’s persistence, but also on the actual complexity of the software product. Since X isn’t a programmer, they won’t be able to gauge that complexity and will simply keep trying to build the product, stumbling over their own mistakes. At the outset, X won’t know what HTML or JavaScript is — the model will help fill those gaps. But after the model wipes out their code, they’ll have to understand how Git and development branches work; and after it wipes out the database, they’ll have to understand how migrations work; and so on, and so on. The point is that the user will be obliged to deepen their understanding of the project in order to move it forward, and there simply is no other way.

From this follows a second maxim:

You can successfully grow a project using models, but only up to the ceiling of your own understanding of it — beyond that, it becomes impossible.

This isn’t really my claim, but a modified version of the Peter principle — “in a hierarchy, every employee tends to rise to their level of incompetence.” The idea is simple: the less a person understands the processes at play, the less effectively they can respond to them. The same happens to a non-programmer trying to use AI for their own projects: continually growing the project requires the continual growth of the understanding of the person steering the AI — otherwise the project quickly hits a ceiling.

The same rule applies to a programmer. Imagine you’re a web developer. You command your development stack and know how to use it. With a model’s help, you decide to build yourself a program for automated trading on the securities market. However good you are at programming, to build a successful program you’ll be obliged to improve your financial knowledge. You’ll be able to write a first version of the app that does simple trading, but you won’t be able to compete with strong players without understanding financial subtleties, the principles of algorithmic trading, forecasting, and so on. This is true simply because at some point the model, trying to carry out your task, will ask you a question that you (a) won’t understand and (b) won’t know how to answer. And as we know from what’s said above, that moment will come in the growth of any project, because a project’s complexity will always increase.

Another important point: we’re in a unique situation where the expected output of a programmer’s work is code, and yet most of us don’t write that code ourselves. Because of this gap, there’s reason to believe our programming skills will degrade. Common sense says as much — anything a person doesn’t use tends to wither: language skills, motor skills. Whether this rule applies to the ability to program remains to be seen.

Stage 04Acceptance

I should write about the acceptance stage too. This is probably where something very positive and uplifting is supposed to go. I’ll leave it to the reader to find the positive; what I see is that this technology is very powerful, transformative, and the scale of its impact on humanity and society isn’t fully grasped even by its creators. It has the power both to save humanity and to plunge it into the Dark Ages. I think David Bowie put it best — though at the time he was talking not about AI but about the Internet. In 1999, when he was asked what he thought of the Net, he answered:

I don’t think we’ve even seen the tip of the iceberg. I think the potential of what the Internet is going to do to society, both good and bad, is unimaginable. I think we’re actually on the cusp of something exhilarating and terrifying. […] It’s an alien life form. David Bowie, BBC Newsnight, 1999

(Interview video)

Ember

AI

Stage 01Denial

Stage 02Anger

Stage 03Bargaining and depression

Stage 04Acceptance