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

A sales rep doesn’t know how to write code. Most of them don’t even know how computers work. However, he perfectly knows how to bullshit people. That’s exactly why we need him. Because we don’t know how to bullshit people and we don’t want to learn it.

Now, two strategies lie in front of him. He can use the skill against the prospects on the market and turn them into paying customers. He can also use the same selling skill against you, the owner of the startup. Instead of selling the product to the market he can sell himself to you. He can sell the idea that even if he fails to sell the product to the customers he still deserves a decent weekly paycheck.

What do you think, which sale is easier to make? What would you do in his shoes? The answer is obvious. The customers are far away and they have no mercy. If they don’t like the offer, they simply hang up on him and that’s it. You, on the other hand, sit next to him in the same office and can’t hang up. You are the low-hanging fruit. You are the weakest prey he can reach out to.

A customer is an external obstacle that he must overcome in order to get paid, as a sales commission. You are an internal obstacle, which he may also overcome to get a fixed weekly payment. You need him to fight the external obstacle. However, he is free to choose the easiest path.

In order to make him focus on external obstacles, you should make internal ones harder to overcome. Joseph Stalin once said that “in the Soviet army it takes more courage to retreat than advance.” This war-time concept seems relevant to the sales guys you hire. It must be harder for them to talk you into paying them a fixed salary than to convince a prospect to buy your product.

Emotionally, for you it may be rather challenging to constantly push him back. Just like it’s often hard to say “No” to a vagrant begging for a dollar at the corner. Beggars, unless they are physically disabled, also, just like sales people, have two possible life strategies. Either find a job or beg at the corner. The begging strategy, for the vagrant and for the sales rep, is easier to pursue.

Programmers are not much different. They also have two strategies. They can solve technical problems by merging qualified pull requests. They can also persuade you that you must pay for their time, not their pull requests. Which obstacle is going to be harder for them to overcome depends on you.

First, you set up a formula for measuring their contribution. Second, you bind their paychecks to it: they get paid not by you, but by merged pull requests. Finally, you taboo the very possibility of discussing time-based compensation.

What you get is a technical team focused on resolving external problems. The team will advance because it will be pointless to retreat. You simply won’t pay them for their time. No matter how many times they repeat “I was working hard the entire weekend.”

Incentives shape behavior. If you reward excuses, you buy excuses. If you reward results, you get results. As a founder, your job is to eliminate the temptation for your team to sell you anything other than tangible artifacts.

When a repository is smaller you can achieve higher quality, for a number of reasons:

• You can be stricter on style. It’s easier to keep a thousand lines consistently formatted than a million. With a thousand lines, you can configure ESLint to its maximum, enabling as many rules as you can find. Stricter control over code stylistics leads to cleaner code.

• You can write deeper tests. Integration (or deep) tests are inevitably slow. In a smaller repository, a good integration test coverage doesn’t mean a slow build. In a larger repository—it does. A slow build is something a team tries to avoid, thus jeopardizing the coverage.

• You can review more pedantically. In a larger repository it may be harder to remember all the aspects of design. A pull request that affects different seemingly unrelated code parts may be a challenge to review. Even if you are the architect.

• You can write a README. Maybe you have noticed already: large open source projects have short and sketchy README files. They can’t make them much longer without them becoming as large as a book. All they can do is redirect the reader to the documentation website. The inability to explain the entire scope in a single file leads to scope creep. Contributors struggle to understand the borders of the project. This leads, among other bad things, to code duplication.

• You can release frequently. In a larger repository, frequent reintegration may be expensive, in both time and money. In a small repo, a build of a few seconds is not a dream of programmers, it’s their reality. Not only CI is cheap, but also CD. After every small change you can publish a new release, with its own version. In a monorepo, we tend to wait until a portion of changes accumulate.

• You can use AI agents effectively. It is no secret that modern LLMs have limited context windows. A million lines of code can’t fit into even the largest of them. Even ten thousand lines, let alone a million, is more than an LLM can digest. By keeping a repository small we do a big favor to our little friends: AI agents.

• You can on-board faster. Larger codebases are usually older and more chaotic, full of legacy code. It takes longer to start making meaningful contribution to such a repository. Monorepos attract long-term office-based contributors who care about job security more than about code quality.

• You can expect responsibility. In larger codebases, the very idea of code ownership is hard to maintain. Programmers can hardly feel responsible for the code written and modified by others. Smaller repositories, on the other hand, emotionally attach people to code.

• You can go open source. No matter how much your boss loves open source, you can’t put your entire enterprise monorepo on GitHub. However, if you extract a small part of it, you can. The code that is open, visible and criticized by many people, is allegedly of a higher quality.

In summary, you should look for an opportunity to extract a piece of code as a standalone package. Then, insist on making it open source. Then, promote it in the community. Then, quit your office job and join Zerocracy.