In 1908, Alfred Adler suggested that contributing to others (a.k.a. Gemeinschaftsgefühl) is what gives the individual a sense of worth. Later psychologists, like Morris Rosenberg and Gordon Flett, called it “mattering”: the sense that one is significant to others. Adjacent to this, Edward Deci and Richard Ryan, authors of the Self-Determination Theory, identified “relatedness”: a psychological need to be bonded with others. Simone Weil in The Need for Roots (1943) listed “to feel one is useful and even indispensable” among the “vital needs of the human soul.” Moreover, Émile Durkheim in Le Suicide (1897) found suicide rates rise as social integration falls.

“The true joy in life,” according to Bernard Shaw in Man and Superman (1903), is “being used for a mighty purpose.” I believe that being needed by others is not only a joy, but the primary reason to exist.

There are nearly 50 million programmers like us in the world, by SlashData’s count. We are a small part of something larger: about 400 million people whom ISCO classifies as “professionals”—one in nine of everyone employed on the planet. Peter Drucker named us “knowledge workers” in Landmarks of Tomorrow (1959), before the personal computer existed. Robert Reich, in The Work of Nations (1991), called us people who “manipulate symbols,” and put us at a fifth of the American workforce. Counting managers and technicians alongside professionals, ISCO now finds 20.1% of the planet in that kind of work. The world looks the way America looked in 1989. We contribute by thinking, and that is what makes us needed.

However, LLMs already think better than us, and faster too. At the 2025 ICPC World Finals, Gemini solved ten of twelve problems. Had it competed as a team of humans, it would have finished 2nd out of 139. It also solved Problem C, which no human team solved at all. That was a year ago. I’ve been writing code for more than 25 years, contributing over 100K lines to my GitHub annually. Since March, not a single line of code committed under my name has been written by me. It’s all Claude Code. It was 4% in February.

And they are not only good. They are cheap, and getting ~13x cheaper every year—faster than computing or electricity ever fell. If all of us took a fifty percent pay cut tomorrow, the machines would take back the difference in ninety-nine days. Dario Amodei describes what is arriving: “millions of instances,” each thinking at “10x-100x human speed”—a “country of geniuses in a datacenter.” Thinking stops being scarce. Soon we won’t be needed.

Some expect a market for artisanal code: machines will write the millions of routine lines, and humans will craft the parts that matter, charging double for it. This won’t happen for the same reason nobody hand-writes assembly anymore. No law banned it. The compiler simply got better than we were. Every published study still says our code is the safer of the two.

I don’t believe them anymore. Since March I have shipped nothing else but LLM-written code, and the quality is higher than a year ago. Our code won’t be illegal at first—just something no reviewer approves. In mission-critical systems first, then everywhere. “Made by a human” will stop being a price premium and will become a disclosure.

None of this is new. Steven Pinker in The Language Instinct (1994) predicted this: “It will be the stock analysts and petrochemical engineers and parole board members who are in danger of being replaced by machines. The gardeners, receptionists, and cooks are secure in their jobs for decades to come.” He was writing about the future. Thirty-two years later it is career advice.

In May 2026 Jensen Huang a graduating class at Carnegie Mellon: “Electricians, plumbers, iron workers, technicians, builders—this is your time.” He meant it kindly. He was talking to people who had just finished four years of university. We will retire, or we will move to physical work.

John Keynes named it in Economic Possibilities for Our Grandchildren (1930): “technological unemployment,” he called it, “unemployment due to our discovery of means of economising the use of labour outrunning the pace at which we can find new uses for labour.” Yuval Harari named the people in 2017: a useless class that “will not merely be unemployed—it will be unemployable.”

A child born today will be obsolete before he finishes school.

Nick Bostrom declared a world of “deep redundancy” in Deep Utopia (2024): there is nothing you could do that anyone would need. He proposed “artificial purpose”—challenges designed for us by the intelligence that replaced us. Keynes already knew how that ends: the people who had money and no duties, he wrote, “failed disastrously.”

This already happened once, to people with less protection than us. From 1999, middle-aged Americans without a degree started dying faster than their parents’ generation—the first such reversal in a century. Drugs, alcohol, suicide. 151,845 of them in 2017 alone. The suicide rate was the highest since 1938. Deaths from alcohol were the highest since the First World War. Anne Case and Angus Deaton found the cause was not poverty. It was the sense that “their ability to contribute to society has been terribly thwarted.” We read about it, called it their problem, and went back to work. Now the same thing is coming up the ladder, for the people who have the degrees.

Hannah Arendt saw the shape of this in 1958, before programming became a profession. “What we are confronted with,” she wrote, “is the prospect of a society of laborers without labor, that is, without the only activity left to them. Surely, nothing could be worse.” And she saw no way out: no class left, “no aristocracy of either a political or spiritual nature from which a restoration of the other capacities of man could start anew.” The next sentence of her prologue is the one I keep returning to: “To these preoccupations and perplexities, this book does not offer an answer.”

Neither does this one.

Many books have been written about office power games, for example Jeffrey Pfeffer’s Power in Organizations (1981), Henry Mintzberg’s Power In and Around Organizations (1983), and Rosabeth Moss Kanter’s Men and Women of the Corporation (1977). They are good reads, but barely useful as practical guidelines. They treat career-successful people as humans. They are not, they are rats.

Joep Schrijvers’s The Way of the Rat (2004), my favorite, uses exactly this metaphor. Being a rat means taking advantage of other people and enjoying it.

This is what a rat does in nature: it doesn’t earn its food, it steals it. That’s why we people hate rats—they steal from us. However, rats feel nothing bad about being rats. That’s how they were born. They are made to be thieves, with a big smile on their ugly faces.

First and foremost, office rats are politicians. All they do is fight with other rats for better position, higher rank, and bigger resources. To win they don’t write cleaner code, and they don’t make more precise budget forecasts either. To win they make other rats lose.

Being an office rat may be hard for most of us. I present you with a list of skills that may help if you’re ready to stop being a human. Not soft skills, not hard skills, but rat’s skills. Here they are:

How to Talk a Lot Saying Nothing All rats do in the office is talking. If you keep your mouth shut and your eyes open, as many office coaches recommend, you either look obviously weird and get rejected, or eventually start talking, disclosing everything you’ve been holding to yourself for long. In a rat office, silence is never safe. Instead, you should talk a lot, at every meeting, using every opportunity to open your mouth. But you should say nothing. This is easy: no matter what the subject is, find an angle that is obvious and argue in favor of it. Say, we discuss who gets the salary raise: Jeff or Mary. Your argument should be: “Not raising a salary for a good employee is bad!” This idea doesn’t add anything to the argument, but it helps you defend yourself against other rats. They won’t think of you as their enemy and won’t bite. Your point is an obvious boring truth—the best type of argument.

How to Find Scapegoats Some people stay in the company because they produce products: code, tests, design, architecture, etc. Rats don’t do that, because they don’t want to and they don’t know how to. Instead, they stay in the company because it’s hard to kick them out. They know how to look formally innocent. Moreover, they know how to make themselves look valuable. They know how to directly attribute themselves to the results achieved by those coders and designers. When things go south, rats know how to find scapegoats—people that can be formally blamed for the failures. You should learn this skill too, it’s not so difficult. Just pay attention to every mistake people around you make and link them with your own possible failures. Say, your friend came late to the office on Wednesday last week. Good! Schedule a fake meeting on this very morning and when the time comes, claim that because of his absence you weren’t able to share important information with him. Build such evidence systematically and you’ll have a strong weapon against your friend, who is obviously your enemy at the same time.

How to Read Between the Lines In a professional full-of-rats office environment everybody wishes to screw everybody. The only way to get a friend into trouble is by finding how his actions violated the rules. Talking and writing is the only act a rat does. A rat knows that enemies are watching him, that’s why he doesn’t say or write anything straight. A rat writes “The report is great!” and means “I don’t trust you anymore, better quit this job.” The “great” is the tell, if he usually writes “perfect.” You must know how to read between the lines and understand what people truly mean.

How to Invent Obstacles Regular people, who are not rats, try to be helpful to others and be modest about it. This is what rats use against them: modesty is your weakness. Instead, you should radiate the smell of sweat. Every task should be difficult for you, but not because of your incompetence. Because of so many obstacles you have to deal with. Regular people say “I will deal with it, trust me.” A rat says “I will try, but it’s very difficult, because of …” Later, when you screw it up, you will blame the obstacles. If you don’t, you will be a hero who fought the obstacles. Those quiet humble losers who just do their job will always be behind you.

How to Identify Owners Only in a small startup of five people everything is owned by the founder, who is one of these five. In a large organization, resources—money, staff, hardware, offices—belong to people who decide how to distribute them. To achieve your goals in the organization, you need resources. You need their owners to give them to you. They won’t do it voluntarily, no matter how noble your objectives are. They don’t care. You can get resources only if you trade: you give them something in exchange. The scenario is easy, when you need them, since you know what you can give them in exchange. It’s more complex when someone comes to you asking for the resources you own. If you don’t know what this guy owns, you don’t know what to trade. A good rat is always prepared to ask for a favor when being asked for a favor. A good rat never gives anything to anyone for free. Learn what your friends possess or have access to—be prepared to ask them to share.

How to Be a Friend Rats are politicians, not engineers or managers. A good politician knows how to do one thing and nothing else: make friends. It’s easy to make a friend when you have nothing to share. However, imagine a lead of another department comes to you and asks you to give your best engineer to his project. What would a regular team lead do? He would fight for the engineer, to keep him in the project. What would a politician do? He would do everything to keep the other manager a friend. He would not care about the engineer or the project at all. Friendship, for a rat, comes first. Productivity, efficiency, profit, customers—all of that is secondary. Enemies ruin your career, not bad code, broken servers, or lost customers. Know how to make friends at all costs.

How to Disrespect Yourself Rats don’t produce anything valuable, neither engineering nor management. They do politics only: make friends and then betray them. A long time ago, when they were engineers, they did something productive, but it was a long time ago. They’ve forgotten all that already. All they do all day is attending meetings with other rats, also highly incompetent. If you have any talents somehow related to engineering or management, you will hate yourself for being a rat. Sitting in those meetings you will be bored to death. More importantly, you will constantly ask yourself a question: “Why do I have to be here? Am I as useless as these morons?” You must be ready to answer yourself: “Yes, I’m one of them, my talents are useless, I’m nothing more than a talking head. It’s over.” This answer will make you stronger. You will be a good rat.

How to Respect Fools The higher you are on the organizational ladder, the less competent people are around you. I mean technical competence. A CEO of PepsiCo can become a CEO of Apple, you know this story. The same happens everywhere: clowns are climbing up management ladders. They get promoted for being great politicians, not for knowing how computers work. Your job is to keep your mouth shut and never tell them they are fools. However, the better expert you are, the more difficult it will be. Learn how to stop asking yourself a question: “Why do I have to spend time with fools?” Also, this question may hurt: “Why does our company tolerate fools being in charge of smart people?” God forbid you ask these questions out loud in the office. This would be the end of your career.

How to Be a Fool Since the better expert you are, the more you despise the fools around you, your office life would be easier if you stopped being an expert. Don’t code, don’t read technical books, don’t touch anything related to product engineering. Instead, spend most of your time with other rats, picking the most incompetent ones. You can easily find them—they are constantly surrounded by other smaller-caliber rats. All they do is talking, organizing meetings, attending meetings, and spreading rumors. They are wasting time, you may think. This would be your first instinct while you are only becoming a rat still having some technical expertise inside you. In a few years you will realize that you are an absolute disgrace, a highly incompetent imposter, with an overblown salary. This is when you put all of your energy into the fight with other rats—the survival instinct will kick in. This is when you become a great rat: a CEO, a President, an icon for others.

If you don’t want to be a big boss and an icon, it’s your call, stay human.

However, if you don’t want to be a rat, but still want to be a big boss, bad news for you: you will be food for other rats, just a step in their career ladders. They will set you up and present your mistakes as their advantages.

Being a rat is a full-time job, without vacations or day-offs. You can’t be a bit of a rat and a bit of a software engineer. Trying to stay in the middle only makes you a weak rat: perfect material for other rats to use. Spending time on writing code, analyzing server architecture, or sitting with a UI designer to make your product better only takes you away from rat’s job: making friends and betraying them.

Make a choice. The earlier in life, the better.

Nothing burns like being judged for what you didn’t do. Aristotle held that “on voluntary passions and actions praise and blame are bestowed, on those that are involuntary pardon, and sometimes also pity.” Later thinkers, from Kant to Thomas Nagel, turned the same instinct into the control principle: “we are morally assessable only to the extent that what we are assessed for depends on factors under our control.” Adam Smith agreed that reward belongs only to “actions of a beneficent tendency, which proceed from proper motives.” Tie a person’s praise or blame to results their own work never caused, and the judgment stops being fair.

Victor Vroom’s expectancy theory boils motivation down to a product:

Motivation = Expectancy × Instrumentality × Valence

Expectancy is your belief that effort will lead to performance. With no control over the outcome, it drops to zero. Instrumentality is the link from that performance to the reward. With no way to measure it, it drops to zero too. Valence is how much you want that reward. Even when it runs high, the three terms multiply, so one zero kills the whole product.

John Stacey Adams’s equity theory adds the next link: fairness. Workers “seek to maintain equity between the inputs that they bring to a job and the outcomes that they receive.” Those who feel short-changed “experience distress” and withdraw.

Yet most of us barely move the top line. Our effect on it is indirect, and impossible to measure.

W. Edwards Deming showed the first half with his red-bead experiment. Workers drew from a box rigged with a fixed ratio of red beads, were praised and punished for the count, and could do nothing to change it. “The performance of anybody, almost anybody,” he concluded, “is governed almost totally by the system he works in.”

The second half—you cannot measure one person’s share—is a basic result in the economics of the firm. In their classic paper on team production, Armen Alchian and Harold Demsetz put it plainly: “marginal products of cooperative team members are not so directly and separably (i.e., cheaply) observable,” and “what a team offers to the market can be taken as the marginal product of the team but not of the team members.” Their fix was to measure each person’s input, not the team’s output.

So a company-size target, pinned on one person, does not pull. It pushes the other way.

Even the goal-setting psychologists who love stretch targets admit the limit: Höchli and colleagues note that a superordinate goal “can be too abstract and disconnected from actual behavior” to guide anyone’s next move.

What happens next is no mystery; researchers have studied it for years. Let people sense the judgment is rigged, and they react in ways industrial psychologists call counterproductive work behavior. At best, they quietly sabotage. At worst, they rebel.

Skarlicki and Folger tracked 240 employees and found that a sense of injustice reliably predicts “organizational retaliation behavior”: the disgruntled striking back at the firm they believe wronged them. Jerald Greenberg showed how literal the damage can be. When a company cut pay by 15% without a proper explanation, the workers who felt underpaid stole much more—the “hidden cost of pay cuts.”

The suggested fix: hold each person to their own work, and nothing more. Don’t cascade the OKRs, don’t open the books, don’t parade the top-line number before everyone, as if visibility alone were motivation. Don’t push people toward the metrics above them. Instead, hide those metrics from them altogether.

Keep the higher numbers out of sight. Nothing is left to feel manipulated by. Only one thing stays in view: the worker’s own metric. They can control it and measure it. On that ground, motivation does not just survive. It grows.

Yes, this defies the transparency gospel. That defiance is exactly the point.

I know that he spent the first few months of his life in the wild. Technically, in GitHub, StackOverflow, and software development blogs and books. This is where he learned how others code, by looking at billions of lines of code. Obviously, we can’t expect most of the lines to be pretty. We can’t even expect them to be correct.

However, while correctness is a verifiable deterministic category, code prettiness is not. It’s not only almost impossible to validate, but also hard to formulate. Not only because it’s a matter of personal taste, but because it’s an emotion, not an algorithm. You either feel it or you don’t.

Let me give you an example by sharing a list of what I’m particularly allergic to in programming:

• The absence of tests
• Knowledge duplication
• Global state
• Mutable object attributes
• Swallowed exceptions
• NULL references
• A class inheriting another class
• Type casting or introspection
• Functions accepting 10+ arguments
• Objects encapsulating 10+ attributes
• Compound variable names
• Comments in the code
• Emojis in documentation 😢

This is a tiny part of what I can call source code ugly for. I’m sure you agree with a few items, disagree with a few others, and don’t understand the rest. Claude would react similarly if he saw this list.

Functionality goes first, aesthetics next. We implicitly teach this principle in programming schools. Claude learned it too by looking at those billions of lines. If an algorithm doesn’t work, it doesn’t matter how pretty your code is. This is his philosophy, and that of a million human programmers.

I believe in the opposite: aesthetics over functionality. Simply because elegantly designed software is easier to fix than to make working software elegant.

By a lack of elegance I mean not only inconsistent indentation, though that’s an obvious sin. I also mean lack of modularity, inadequate error handling, inconsistent naming, tight coupling, low cohesion, and high complexity. If you read Code Complete (2004) and Object Thinking (2004), you know what I’m talking about. Software may be correct functionality-wise even if most of the principles are violated. But it would be ugly software. For me and maybe for some of you. Not for Claude.

A billion Java programs taught him to see source code as an intermediate byproduct between user’s intent and the computer. However, I prefer working with programmers who see source code as a piece of art, a product by itself. I expect them to feel the beauty of the code they write.

It’s hard to find and recruit such people. It’s even harder to convert a regular programmer who doesn’t care into an aesthete. Unlike most people, Claude Code can be converted.

With the help of the carrot-and-stick method, as usual.

The carrot is the CLAUDE.md file, the agentic manifesto. Here is mine, at this repo. In the file I preach to Claude, trying to formulate what beauty means for me. It’s hard, since I have to stay short in the system prompt. That’s why I sound pretty abrupt, as you can see.

The stick is style checkers and static analyzers. I used to have them for years in my repositories, but my arsenal was limited. I was forced to use PMD, Checkstyle, Rubocop, Pylint, and whatever else the market provided. Making my own checkers was a complex task that I didn’t have the time or skills for. Today, I can make my own checkers, because I have Claude.

Here is an example. Recently I’ve launched a new version of Qulice, a checker for Java code. It extends PMD and Checkstyle with 59 additional checkers. New checkers express my personal taste for Java code, which sometimes contradicts what the community believes is right. Qulice is not a new project. It’s 14 years old. However, I was only recently able to implement all these additional checkers. Because I didn’t have Claude for 14 years.

Yet another example. I’ve been using Rubocop for more than 10 years. An amazing style checker for Ruby code. However, it lacks a few important rules that my personal taste demands. A month ago I implemented an extension for Rubocop. Now I’m fully equipped. Of course, Claude implemented it, not me.

A combination of both, the carrot (manifesto) and the stick (checkers) does the job. The manifesto inspires Claude to do the right thing. The checkers punish him for doing wrong things. Of course, the checkers cover only the formalizable part of beauty. Inconsistent indentation, a NULL reference, or a type cast—a tool can catch these. Tight coupling, low cohesion, or clumsy error handling—no checker can feel them (so far!). That heavier half stays on the manifesto.

When the manifesto is inspirational and the checkers are strong, Claude starts “feeling” me. Well, at least that’s what it seems (or maybe it truly does feel me?!). He appreciates my views and rarely writes anything that contradicts them. When he does, the checkers punish him, and he remembers.

I can’t imagine a human reacting the same way. A few years ago I hired a guy who didn’t care much about code elegance. However, he was good with algorithms and knew Java pretty well. Apparently, he wasn’t ready to put aesthetics over functionality. He quit in two weeks.

Claude doesn’t quit. And he costs just $108 a month.

Between any two adjacent lines, indentation may increase by exactly one unit.

This rule should resolve most disputes about code formatting style. It is easy to add as an extra check to any existing style checker, or to deploy on its own as a small standalone tool.

According to the rule, this Java code is illegal:

class Repository {
    void save(File file,
              String text, String summary,
              boolean overwrite) {
        if (file.exists()
                && !overwrite) {
            throw new IllegalStateException(
                    "file already exists");
        }
        update(file,
               text,
               summary);
    }
}

This one is legal (and pretty, if you ask me):

class Repository {
→→void save(File file,
  →→String text, String summary,
    boolean overwrite) {
    if (file.exists()
    →→&& !overwrite) {
      throw new IllegalStateException(
      →→"file already exists");
    }
    update(file,
    →→text,
      summary);
  }
}

The idea is simple: going down the code, you may step right by one notch at a time, but you may jump back left by as many notches as you want. You can’t skip steps on the way in, but you can leap out freely. Every line still lands on a grid, never in between.

Together with the Paired Brackets rule, this makes the code look ideal: brackets line up vertically and indentation never jumps further than necessary.

BTW, the parser of EO, our experimental language, enforces this rule syntactically. This is similar to the off-side rule of Python, where indentation defines block structure rather than braces. However, in EO everything is an object, while in Python it is not. That’s why EO can afford to be stricter and demand monotonic steps everywhere.

For years you sold coding skill at $50 an hour. AI now codes for cents. But you still want $50.

We are still ready to pay. Not for the code—the code is free. For the delivery.

You take what Claude Code wrote and you walk it to our door. You are the courier, not the coder.

The margin is what we pay for trust: that what you deliver, we can merge without re-checking. So the delivery must be flawless.

A PR without a description is a package with no label—refused. An unfocused PR is two parcels in one box—refused. A PR too large to read is an oversized package—refused. A PR sitting in review for weeks is a delivery that never arrived—refused. A PR for an unapproved feature is a parcel for an address we never accepted—refused.

What we forgave yesterday, when we still needed the code, we no longer forgive. The market for couriers is huge. We can afford to choose. So the bar rises, not falls.

Working code is now the minimum. We expect discipline, speed of delivery, clear and detailed communication, and readiness to re-work. Above all, we expect you to understand our rules and obey them.

No mercy for mess. Not anymore.

If you want the wage, earn the margin.

Be proud of the delivery, not the code.

A few days ago someone (I lost the link) shared a funny story on LinkedIn. He showed a message from his former boss. The boss was asking for a fix to software written twenty years ago. The author of the story proudly claimed that some software, if written properly, can survive a generation.

The software in the story is similar to the skirt of my grandma. It was made to survive a few decades. Because it was expensive to make.

That’s why the boss is not hiring a new programmer to re-write the software. He asks for a fix. Just like my grandma would not throw away a skirt if it got a hole. It would go to a tailor to get a patch.

Many of us wonder what may happen when AI agents, like Claude Code, dominate the market. Programmers, especially junior ones, may be fired en masse. Look at what Jack Dorsey just did: terminating contracts of about 40% of his tech staff.

Large companies indeed will fire programmers, but not because the new world doesn’t need human coders. It’s because the new world doesn’t need large software companies.

What the world is looking forward to is a devaluation of software craftsmanship. Just like a skirt is no longer valuable, except for some high-end brands, software won’t be either. Developing a new ERP system would cost a few thousand dollars and take a few days of work. Just like it recently took a week to create a new web browser.

Oracle, Adobe, Microsoft, and JetBrains will run out of business.

When someone needs an IDE with new language support, they won’t wait for JetBrains to release it next year, maybe. They will go to a software shop around the corner, pay a few hundred bucks, and get it next Monday. When someone needs a new feature in Photoshop, they won’t wait for Adobe. They will buy a new Photoshop from a friend, with the feature and maybe a few more. When a company needs their accounting system to support a new logistics optimization scheme, they won’t go to Oracle. They will re-write the entire Oracle Fusion, for a few thousand dollars.

We won’t wait for new releases of the old software we love. We’ll toss them away and buy new ones.

The market will need more programmers, not fewer. In order to sew good skirts for all women, a city may need a few dozen tailors. Because every skirt costs a lot and is worn for decades. In order to manufacture throw-away one-time skirts, the same city needs many more people. Obviously, these new people are not the tailors of the good-old-days quality. But they make many skirts, thousands per day.

Just like fast fashion replaced tailors with factory workers and machine operators, fast software will replace programmers with AI operators. And the market will demand many of them. Many more than large software companies employ today.

Large companies will lose their monopoly on complexity. A small software shop will be able to build a new IDE, a new Photoshop, or even a new Linux. For a few thousand dollars.

The importance of open source software will continue to grow. It will become the primary provider of ingredients for AI and its operators.

The new world will need more programmers (AI operators) than it needs now. Because the demand for custom software will soon start growing. Everyone will want their own Photoshop. Every developer will want their own IDE and their own Linux. And they will throw them away without hesitation. Just like I throw away my shoes every year and get new ones.

In 2000, Roy Fielding, the author of REST and co-author of HTTP, described the Web in his dissertation:

A network of web pages, where the user progresses through the application by selecting links, resulting in the next page being transferred to the user and rendered for their use.

Simply put, each action leads to an HTML page reload.

In 1999, Microsoft introduced XMLHttpRequest for Outlook Web Access, enabling background HTTP requests. In 2005, Jesse James Garrett coined the term AJAX in his essay “Ajax: A New Approach to Web Applications.” This came in handy when full page reloads stopped working well:

• Browsers were slow
• Networks were unreliable
• Full page reloads felt wasteful
• Users expected “desktop-like” interactivity

AJAX paved the way for the SPA: instead of HTML, the server sends JSON, and the browser reconstructs the page locally. Then came the frameworks: Angular (2010), React (2013), Vue (2014). Each formalizes the same idea: the browser hosts the application, the server delivers data.

Imagine a simple online calculator where a user enters “2+3,” clicks “Submit,” and sees the result right next to the input field. No page reload. The DOM remains the same. The JS inside the browser changes only the result of calculation, in a single <div/>.

The primary justification for this architecture is performance. If servers are slow, rendering a full HTML page takes longer than just a JSON with the result of calculation. If the network is unreliable, re-delivering the entire HTML takes longer than just a small JSON document. Also, if browsers are slow, making a tiny change in the DOM works faster than a full page reload.

This is true, for a trivial example. However, when an SPA gets larger, the frontend has to make dozens of round-trips to the backend. Look at what Facebook and LinkedIn are doing while rendering your home page. A rather simple UI with just a list of recent posts gets filled up by multiple pieces, each leading to its own HTTP request, sometimes taking more than a few seconds to complete rendering a page. Their UX sucks, if you ask me.

Their architects are stupid? Nope.

The very idea of SPA is flawed. The architects of Facebook and LinkedIn are the hostages of it. They can’t make their websites run faster, because they, by design, are built of fragments retrievable from the backend. They must make multiple HTTP round-trips.

The performance penalty of SPAs is structural, not accidental. Even if HTTP/2 multiplexes requests, the UI still waits for JSON to arrive in order—classic head-of-line blocking at the application layer. Worse, one request often reveals permissions, feature flags, or entity identifiers needed for the next, turning parallel calls into a waterfall. Caching doesn’t help either: dozens of endpoints, each with its own TTL, rarely produce a full cache hit, and partial hits still force the browser to assemble and reconcile the page at runtime Meanwhile, the browser must juggle layout stabilization, loading indicators, and partial failures—all before meaningful content becomes visible.

What was once a solution for small DOM updates, in an era of slow browsers and unreliable networks, has turned into a dead-end for web design.

Most web architects simply can’t make their websites as fast as Stack Overflow, which is not an SPA. It delivers the entire HTML page, rendered on the server using Razor, in one <50ms request. It does use client-side JS components selectively, but these are isolated and don’t negate the central role of server HTML for the initial experience. Their UX is one of the best on the modern web, if you ask me.

Rendering a full page on the server may still be a slow operation. It may, and it often will. However, this problem is solvable, for example, with the help of caching. The server is in charge of the data and the state of navigation, making caching possible.

Literally every large, content-heavy, consumer-facing SPA I can think of is horrible in terms of UX. Even Gmail is not an exception. Their UX would be noticeably better if they followed the principles of Roy Fielding and reloaded the page every time an email is opened. I’m not kidding.

The best minds in software engineering have long dreamed of self-documenting code. In 1974, Brian Kernighan and Phillip James Plauger said that “the only reliable documentation of a computer program is the code itself.” In 2004, Steven McConnell in Code Complete claimed that “the main contributor to code-level documentation isn’t comments, but good programming style.” In 2008, Robert Martin in Clean Code suggested that “if our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all.” They all wanted the same thing: code that explains itself. They just lacked the tools to enforce it.

Why do we write comments at all? A Java method of a hundred lines may take hours to understand. A tiny Javadoc block saves this time:

/**
 * Recursively finds the shortest
 * path between two nodes in the graph.
 */
int[] shortest(int[][] g, int a, int b) {
  // A hundred lines of code go
  // here, which we have no desire
  // to read and understand.
}

Comments promise to help us but fail in two distinct ways.

First, they are unclear. David Parnas once said that “documentation that seems clear and adequate to its authors is often about as clear as mud to the programmer who must maintain the code six months or six years later.” What the author considers obvious, the reader finds cryptic.

Second, they decay. Being static metadata, comments do not evolve automatically with the code. If the implementation of the shortest() function stops being recursive, we may forget to update the Javadoc block. Such negligence leads to hallucinating documentation that causes bugs, broken trust, and wasted debugging time. In 1999, Andrew Hunt and Dave Thomas in The Pragmatic Programmer warned that “untrustworthy comments are worse than no comments at all.” A recent analysis of 13 open source projects demonstrated that out-of-date comments are not rare but common.

Now we have a tool that solves both problems: the LLM.

Instead of writing the Javadoc block manually, we let the IDE generate it on-demand. The LLM reads the hundred lines of code, comprehends it, and summarizes the intent in a single English sentence. Modern models accomplish this task better than most humans. The documentation is always fresh because it is generated from the current code, not from a stale comment written months ago.

But we can go further. We can integrate an LLM into the build pipeline and ask it to assess the Code Interpretability Score (CIS) of every function. If the model has low confidence in explaining the logic, this signals that the code is too clever or convoluted. The compiler can enforce a threshold: if the CIS is too low, the build fails. This transforms readability from a subjective preference into an objective, measurable quality gate.

Once this gate exists, manual comments become not just unnecessary but harmful. They introduce a second source of truth that can contradict the code. The logical conclusion: prohibit them entirely. This forces developers to write clean, structured logic that is inherently machine-interpretable.

Robert Martin wished for more expressive languages. He didn’t know about LLMs. Today, we don’t need better languages—we need an LLM that can interpret any language. If the LLM can’t explain the code, we blame the programmer and stop the build.

We are thinking about making EO, our experimental object-oriented language, this restrictive.

In the JavaScript created 30 years ago, objects were primitive associative arrays of properties. Either data, a function, or another object may be attached to a property of an object. Let’s see what Brendan said about JS in 2008:

I’m happy that I chose Scheme-ish first-class functions and Self-ish prototypes as the main ingredients.

First-class functions mean that it’s possible to use a function as a value assignable to a variable. And then he concluded (pay attention, it’s C not C++):

Yet many curse it, including me. I still think of it as a quickie love-child of C and Self.

Self, which he refers to a few times, is a prototype-based object-oriented language designed by David Ungar and Randall Smith in Xerox PARC, then Stanford University, and then Sun Microsystems. Self doesn’t have classes, unlike Java or C++. Instead, it only has objects. To create a new object in Self we make a copy of an existing object, known as prototype, and then modify some of its slots (attributes).

In Self, objects don’t have types: all method calls are dispatched in runtime. For example, we ask a book to rename itself:

book rename: "Object Thinking".

The rename is the method of the book that we call with a single string argument. The computer doesn’t know anything about the book until it’s time to call the rename method. Obviously, such a duck typing has its performance drawback. Every rename leads to a search in a virtual table of book. To the contrary, C++, where types are known in compile time, can dispatch rename() instantly:

Book b;
b.rename("Object Thinking");

Types (classes in C++ and interfaces in Java) and type annotations are helpful—to the compiler. To us humans they are a burden. They require us to do the work of the compiler. We have to pollute our code with messages like: “This object b is of type Book, please remember.” The compiler must be smart enough to understand it without our hints.

This is a debatable topic though. Some believe that type annotations help programmers better understand the code and make fewer mistakes. I’m also in favor of fewer mistakes, but would rather expect the compiler to infer types automatically, without my annotations. If I do b.rename() and b is known to be a car instead of a book, I would expect the compiler to figure this out on its own and refuse to compile.

Anyway, JavaScript was designed as a prototype-based dynamically typed language with a minimalistic syntax that resembles Java. It worked perfectly fine until the industry decided to “fix” it.

In 2008, Mozilla and others proposed ECMAScript 4, which included classes, modules, and other features. Microsoft took an extreme position, refusing to accept any part of ES4. Chris Wilson, Microsoft’s Internet Explorer platform architect, criticized ES4 for trying to introduce too many changes. Brendan Eich accused Wilson of spreading falsehoods and playing political games. ES4 was abandoned, and classes were dropped.

Then, in 2012, Microsoft created TypeScript, a JavaScript with type annotations and classes. Since classes weren’t in the standard, Microsoft made their own.

Finally, in 2015, ECMAScript 6 added classes (among other features) to the JavaScript specification. Many ES4 features, including classes, were revived in a “maximally minimal” form. The crowd of Java/C++ developers got what they wanted.

Let’s hear what Douglas Crockford, the creator of JSON and JSLint, said in 2014:

Class-free programming is JavaScript’s contribution to humanity.

Unfortunately, not anymore. It looks like the developers of recent versions of JS believe in something else. Or maybe they don’t want to make a contribution to humanity anymore. Maybe they just want to make the crowd happy.

Type annotations and classes don’t match with the concept of class-free object-based programming of JavaScript. They came from Java or C++ but don’t fit in. Some programmers may find them helpful, but only because they are used to seeing them in other languages. JavaScript is not Java, even though the names look similar.

Java, with its classes, implementation inheritance, and static methods, is OOP for dummies. It’s object-oriented programming for those who, according to Douglas Crockford, don’t know what object-oriented programming is. JavaScript, on the other hand, is a member of conceptually solid OO languages, like Smalltalk and Self. Blending Java flavors into JavaScript only ruins the flavor of the latter.

It’s sad to see how a once straight object-centric language paradigm turned into a diversity of unmatchable and suboptimal features.

P.S. JavaScript is still a great language if you ignore classes and type annotations. When I write in JavaScript, I don’t use them. Look at the code in the yegor256/jo repository. It illustrates the Junior Objects book of mine. I’m proud of this code.

“People using classes in JavaScript will go to their graves never knowing how miserable they were” - Douglas Crockford https://t.co/D2Hpegn0vY

— Yegor Bugayenko (@yegor256) January 11, 2026