Programming as the new basic literacy

"Programming has become the new basic literacy. Like books 500 years ago, after the printing press"

For the past few years I have been putting AI into my own companies in live operation. We have an engineering holding in the real sector — production sites, contracts, tenders, Kazakhstan regulations, foreign trade, accounting. I am not an AI theorist and not an industry evangelist — I am a founder who sits in the IDE himself and throws tasks at it, and the team behind me does the same. And over the last few months an observation has formed that, to my mind, deserves an article of its own.

Programming is ceasing to be a profession. It is turning into a skill. There is a fundamental difference between those two statuses, and it is changing the labour market more than many people currently imagine.

The parallel I hold in my head as the most accurate one is Gutenberg's printing press in 1450s Europe. Before it, literate people made up less than 10% of the population even in the cities. In the 50 years after the first press appeared, Europe published more literature than in the thousand years before that. The cost of a single book fell roughly a hundredfold. Over the next few centuries literacy grew to 70% of the world's population.

A disclaimer — this article has a short shelf life. I am writing it in May 2026. Six months ago half the tools described here did not exist. Six months from now the picture will be sharper in its details, and I may be wrong on specifics.

Where the programmers' wall came from

Programming started out as a profession and is turning into a skill

Programming took shape as a separate profession in the 1950s and 1960s. The FORTRAN and COBOL generation were engineers with a mathematical education writing for IBM mainframes. The profession was rare, expensive, and concentrated in large corporations and defence.

Every subsequent wave of technology lowered the barrier to entry at one point, but raised the width of the stack overall. In the 80s personal computers gave access to BASIC and Pascal. In the 90s came the web with Perl, PHP, Java. In the 2000s — enterprise platforms, Java EE, .NET. In the 2010s — mobile (iOS, Android), then cloud (AWS, GCP). In the 2020s — aggregate stacks on React, Kubernetes, microservices.

The paradox is that the barrier to entry into any single technology got lower, while the overall wall between "knows some language" and "able to ship a working product" only grew. A professional programmer in 2024 had to hold in their head several languages, frameworks, patterns, DevOps, CI/CD, testing, security, architecture and five kinds of database. Picking all that up over a couple of evenings became impossible.

That is what became the wall. On one side stood the holders of domain competence — financiers, lawyers, doctors, process engineers, buyers, product people. On the other side stood the programmers, who turned the ideas of the domain experts into working code. Between them lay a huge industry of intermediaries: product managers, business analysts, scrum masters, technical writers. Their main job was not even implementation — it was translation between business logic and code.

What AI changed

The barrier was never the ability to write code. The barrier was the ability to describe the task precisely — and that people could always do

By 2024 a class of tools appeared which for brevity I call agentic IDEs — Cursor, Claude Code, Antigravity, Codeium, and a dozen more of the same kind. They have one thing in common. The holder of the expertise opens the editor, describes the task in their own language (what goes in, what comes out, what the rules are), and the agent writes the code. If it does not work, it iterates. If it works, it commits.

In my experience, the fundamental shift here is not really that "AI writes code". AI has been writing code for several years. The shift that matters is that you no longer need a translator. Previously the domain expert described the task to a business analyst, who formulated the specification, a programmer implemented it, a tester checked it, and the product shipped. Between "I have an idea in my head" and "working code" there was anything from two weeks to six months, and five to seven people.

Now the idea gets from author to code in an evening, with no intermediaries. And that is not because "AI got smart". It is because the ability to describe the task precisely is the only real ability needed to produce a product. Coding was the mechanics of translation, and that mechanics has now been automated.

I am convinced of this because I see it on my own team. Our holding has more than ten in-house software products — a home-made ERP, automation skills, analyst agents, format converters, tools for the specifics of our processes. There are no programmers on staff. None outsourced either. All of it is written by the holders of competence, who know what their system is supposed to do.

Whose competence gets capitalised now

The advantage belongs to those who have dug into their niche for 15 years — now they have a shovel

Look, when the programmers' wall disappeared, the value in producing software moved. It used to sit with the programmers, because only they could turn an idea into a product. Now it sits with those who hold deep domain expertise, because only the holder of that expertise can describe the task for an agent.

A financier who has spent 15 years building financial and economic models and knows every quirk of accounting in the real sector will work out the logic of a financial module better than any external developer. Not because their code will be prettier — but because only they know what the rules there should be, what the edge cases are, what the exceptions are, how it integrates with tax reporting. A programmer we might bring in from outside will spend three months just understanding the subject area, and will still build the wrong thing.

The same goes for a buyer who has been through a couple of hundred tenders. They see patterns an external developer never will — which codes in a technical specification conceal a competitor's positions, how the wording of a specification narrows the field of suppliers, which contracts smell of a competition lost before it started. In a day they can describe to an agent a tool that downloads every tender for a period, classifies them by type, and finds suspicious patterns. A programmer will spend a month on the same task — and miss half the subtleties, because they do not know the market.

Lawyers, accountants, economists, product people, process engineers, doctors, engineers — these are the new stars. Each of them carries hundreds of niche details in their head which no interview or specification can extract. Their expertise, accumulated over 10–20 years, now converts into working code directly. And the faster the holder of that competence picks up this skill, the faster their own market value grows.

The financial module of our AI-native ERP was written by a plant director

A personal example is the best illustration

We have our own home-made AI-native ERP — a system designed from the start around agentic work by AI models. It is not "a normal ERP with an AI feature bolted on". It is a different architecture: data exchange between modules is built on natural language.

The financial module of that ERP was written by the director of MEMBRANECO — our plant producing filtering elements, reverse osmosis membranes. He is not a programmer. He is a financier and a company head. He carries several years of work with financial models in the real sector, an understanding of SEZ tax regimes, special investment contracts, depreciation methods for specialised equipment, the accounting of foreign trade operations.

He sat down in the IDE, described to the agent how the logic should work — and got a working module. Not in a day, of course. Over several weeks of iterations, with errors, rewrites and checks. But he got it.

Had we built that module the traditional way, it would have cost close to a million dollars, taken 4–6 months, and required a team of five to seven people: a business analyst, a product manager, developers, a tester. And it would have come out worse. Because the director who wrote his own model caught dozens of nuances in it that would never have made it into a specification.

By the end of summer everyone in the company will be programming

This is natural technological evolution, not a corporate requirement handed down from above

Right now around 40% of our team actively uses agentic IDEs for their tasks. By the end of the summer of 2026, by my estimate, that figure will be 100%. Not because I make them, and not because we decided so in a strategy document. Because without it they will not cope with the growing volume of work.

Where the domain expert should start

Just open the IDE from a position of laziness and curiosity

For those working with specific expertise and wondering "how do I apply this at home" — a few practical pointers.

Install an IDE with an agent mode. I work in VS Code with the Claude Code extension; at the time of writing it is the best in agent mode, but Gemini and Codex are right there alongside. If you have no subscription, Google's Antigravity is free and its limits are enough to try. Cursor has a good free tier. Inside the editor there is a chat panel — you can describe the task there in your own language.

Pick one working task. Not "I need to automate all the analytics", but one specific operation you do regularly by hand. Consolidating data from three spreadsheets into one report. Checking contracts for ten particular conditions. Calculating a specific financial model to a template. The key thing is that the task should be repeatable and inside your zone of expertise.

Describe the task to the agent in your own language. Do not try to imitate a technical specification or to think like a programmer. Describe it the way you would explain it to a colleague: what comes in, what the data is, what the rules are, what the result should be, what the edge cases are. Add examples if you have them. Do not be afraid of a long description — the more precise, the better.

Iterate. The agent's first answer will almost certainly work only partly. Show it the errors, tell it what is wrong. After three to five iterations you usually end up with a working tool.

Do not try to "learn to program" in the academic sense. You do not need to learn a language, syntax, patterns. You need to learn to describe your tasks precisely to an agent. That is the new literacy. Programming as a craft is for those who do it professionally. Programming as a skill is for everyone else.

The capitalisation of competence

Programming is now travelling the same road literacy travelled 500 years ago

I also expect a large number of cross-disciplinary specialists to appear. One person who is simultaneously an engineer and a designer, or an engineer, a product manager and a data scientist. Part of the work is done for them by an agent, so one person can cover a role that used to need a team of four. In essence it is the same thought: value shifts towards what is in a person's head, not towards narrow specialisation at one point in the stack.

Programmers will not disappear in the process. Their role will shift — they will build the infrastructure on which everyone else writes their code. Frameworks, runtimes, agent platforms, data buses, security. That is high-level work, and it will remain. But "a programmer as the person who writes business logic for a subject area" — that role is going into the history books.

Programming is now travelling the same road literacy travelled 500 years ago — from a speciality it is becoming a baseline. That is not a devaluation. It is the opposite, because ten times as many people now hold the skill, and a hundred times as many products get made.

And my sincere conviction is that the task right now is to make use of this narrow window of opportunity. In two years it will no longer be an advantage, it will be the norm, and whoever has not picked it up will be in the position of someone who in 1995 saw no point in learning email.

One option is to pick up the skill through the AI mastermind format, or through AI mentoring — write me a couple of lines about your goals and tasks and we will work something out.