PostCSS, AutoPrefixer & Open Source at Scale with Andrey Sitnik

🎧 New Señors @ Scale Episode

This week, I spoke with Andrey Sitnik, the creator of PostCSS, AutoPrefixer, and Browserslist — tools collectively responsible for 0.7% of all npm downloads — and Lead Engineer at Evil Martians.

Andrey came to programming through Wikipedia editing and the open source ideology of free information before he wrote a single line of code. His tools weren't born from optimization exercises or career planning — they were born from frustration with real problems, in particular the way certain browsers were being systematically ignored by the tooling ecosystem. That frustration turned into a platform used by virtually every web project in existence.

In this episode, we dig into the origin story of AutoPrefixer and PostCSS, why Andrey designed Browserslist to be incapable of browser discrimination, the pledge that forced PostCSS 8 out the door, and his view of what LLM agents actually do to coordination overhead.

⚙️ Main Takeaways

1. PostCSS origin: discrimination, not optimization

The CSS vendor prefix problem was annoying. But the thing that actually drove Andrey to build AutoPrefixer — and then PostCSS — was that Opera, the most popular browser in Russia, was being ignored.

• The problem: Tools that auto-generated CSS vendor prefixes decided which browsers to support based on global market share. Opera had significant usage in Russia but low global numbers, so it was routinely excluded.
• The injustice: "It was a kind of discrimination when nobody thinks about your browser, which most of the people are using in your country." The pain was personal and specific.
• The result: AutoPrefixer came first as a direct solution. PostCSS came after as the framework underneath it — a platform for building CSS processors rather than a single tool.

2. PostCSS was designed as a platform, not a tool

AutoPrefixer was the product people wanted. PostCSS was the real play — a framework that let other developers build their own CSS processors.

• The design goal: Make it easy for others to write plugins. The ecosystem expanding PostCSS's capabilities would go far beyond what one developer could build alone.
• The marketing vehicle: AutoPrefixer was how people discovered PostCSS. Once they were using it, they could build on the platform.
• The outcome: The plugin ecosystem exploded — CSS Modules, stylelint, and eventually Tailwind all built on PostCSS, extending its reach in ways Andrey never could have planned.

3. The Sass/Less gentleman's agreement

Instead of competing destructively, Andrey and the Sass team found a way to coexist that made the whole ecosystem better.

• The format: Agreed on benchmarks that were genuinely fair across tools. Browserslist was made shared infrastructure — not a PostCSS-specific tool but a common dependency across ecosystems.
• The collaboration: Teams could combine their tools rather than being forced to choose. The Sass team eventually contributed back to PostCSS.
• The result: "In the end, it was a pretty nice collaboration." Open source doesn't require zero-sum competition even between direct alternatives.

4. The Tailwind pledge and PostCSS 8

Andrey publicly pledged that a 10,000 USD donation to the PostCSS Open Collective would trigger the PostCSS 8 release. Tailwind donated it.

• The context: Tailwind UI had just launched and Tailwind was flush with VC money. They needed PostCSS 8 for their ecosystem to work properly.
• The irony: Forcing Andrey to release also meant Tailwind had to migrate all their plugins to the new version. The donation that bought the release created significant immediate work for the donor.
• The lesson: Sometimes the right mechanism for getting yourself to ship is making a public, accountable commitment to an external party.

5. Major release strategy: three rules

Andrey follows a consistent framework for major releases that minimizes ecosystem disruption — borrowed from Ruby on Rails.

• Rule 1: Document the migration path thoroughly before announcing anything.
• Rule 2: Communicate via social media at least six months before the release. "From our social media, we start to speak about the release at least half of the year ahead. So people will have time to adopt, have time to accept this reality."
• Rule 3: Never remove APIs in the same release you deprecate them. Tick-tock cycle: deprecate in version N, remove in version N+1.
• The philosophy: Maintainers who break their ecosystem without warning are choosing their own convenience over their users' stability. The six-month runway is a form of respect.

6. LLMs and the Mythical Man-Month

More LLM agents working in parallel doesn't equal faster delivery. It creates the same coordination overhead that adding more humans does.

• The classic argument: The Mythical Man-Month says that adding more people to a late software project makes it later — because every additional person adds communication paths that scale quadratically, not linearly.
• The application to AI: "If you will add 10x more agents to your project, you will have 10x more problems of the communication between agents. LLM agents are very similar to humans in many cases."
• The implication: The bottleneck in agentic AI development isn't compute or model capability — it's coordination. Agents need to share context, resolve conflicts, and align on decisions, and that overhead grows with scale just like it does with human teams.

7. The future of information consumption

Andrey wants a new kind of RSS reader built for the LLM era — one that gives you conscious control over how you spend your attention.

• The problem: Current feeds don't distinguish between "junk food content" (short, dopamine-triggering, immediately consumable) and content that is actually useful or meaningful.
• The insight: People subscribe to junk food not because they don't know it's junk food — but because they want it sometimes. The problem is when it dominates by default.
• The solution he wants: A reader that separates the two categories and shows you how much time you're spending on each, so the choice becomes conscious rather than accidental.

8. Dark transhumanism as a genre

Andrey reads and recommends a specific sub-genre of sci-fi exploring what society looks like after brain scanning and digital consciousness become real.

• The genre: Stories set after the technological singularity that focus not on the technology itself but on the social, ethical, and psychological implications of digital consciousness.
• Key works: Permutation City by Greg Egan. The short story "Lena" — formatted as a Wikipedia article, deeply unsettling. The Quantum Thief trilogy by Hannu Rajaniemi. Blindsight by Peter Watts.
• Why it matters: These books ask questions that are becoming less hypothetical. The "Lena" story in particular has the effect of making you think differently about identity and consent in ways that stay with you.

9. PostCSS through six or seven compilers

PostCSS was written in the era when var was the only way to declare variables in JavaScript. Its git history is an accidental archive of the entire JS compilation era.

• The progression: CoffeeScript → 6to5 → Babel → native JavaScript. Each migration happened because the next tool was clearly better and the previous one was becoming a liability.
• The context: PostCSS was built before ES6, before const and let, before arrow functions, before modules. The fact that it still underpins the modern web is a testament to the stability of its core abstractions.
• The irony: A tool built to transform CSS had to be constantly transformed itself just to stay current with the JavaScript ecosystem it lived inside.

10. 0.7% of all npm downloads: "I was just lucky"

Andrey says this about the scale of his tools' reach — and he means it literally, not modestly.

• The real story: The tools were built to solve specific, painful, personal problems — Russian browser discrimination, CSS stagnation, missing tooling infrastructure. Not to be widely adopted.
• Why the scale happened: The problems were universal even if Andrey's experience of them was local. Vendor prefixes were annoying for everyone. Browserslist solved a real coordination problem across the whole ecosystem.
• The lesson: "The only book you should read is mostly about what you are doing, not how — because how is cheap right now." Build for the problem, not the audience. If the problem is real and widespread, the audience finds you.

🧠 What I Learned

• PostCSS was built because Opera was being discriminated against in browser support tools — the problem was injustice, not optimization.
• PostCSS was designed as a platform for other developers to build CSS processors, with AutoPrefixer as the marketing vehicle.
• The Sass/Less gentlemen's agreement showed that open source tools that appear to compete can share infrastructure and collaborate productively.
• The Tailwind pledge was a public commitment mechanism that forced a release — and ironically created migration work for the funder.
• Major release strategy: document migration, six months of social media communication, never remove and deprecate in the same version. Borrowed from Ruby on Rails.
• The Mythical Man-Month applies directly to LLM agents: 10x more agents means 10x more coordination problems, not 10x more output.
• The information diet problem isn't that people don't know junk food content is junk food — it's that the choice isn't conscious.
• PostCSS's git history is a complete archive of the JavaScript compilation era from CoffeeScript to native.
• 0.7% of all npm downloads came from solving real pain, not from planning for scale.
• Dark transhumanism — Permutation City, "Lena", Quantum Thief, Blindsight — is worth reading now while the questions are still hypothetical.

💬 Favorite Quotes

"It was a kind of discrimination when nobody thinks about your browser, which most of the people are using in your country."

"I was just lucky." (on 0.7% of all npm downloads)

"If you will add 10x more agents to your project, you will have 10x more problems of the communication between agents. LLM agents are very similar to humans in many cases."

"From our social media, we start to speak about the release at least half of the year ahead. So people will have time to adopt, have time to accept this reality."

"The only book you should read is mostly about what you are doing, not how — because how is cheap right now."

🎯 Also in this Episode

• Wikipedia editor before programmer — Andrey came to code through the open source ideology of free information
• The PostCSS plugin model and why JavaScript configs handle edge cases that JSON configs can't
• Browserslist: the query language was deliberately designed to prevent browser discrimination — "mobile browsers" as a query was intentionally rejected and continues to be rejected
• CoffeeScript to native: the complete history of JavaScript compilation embedded in PostCSS's git history
• Evil Martians as a product consultancy — who they work with and how Andrey's open source work fits in
• The future of CSS: the CSS Working Group moving faster with Cascade Layers, :has(), and container queries — making PostCSS less necessary than it used to be
• Dark transhumanism book recommendations: Permutation City, "Lena" (Google it), Quantum Thief trilogy, Blindsight

Resources

PostCSS ecosystem:

• PostCSS GitHub
• AutoPrefixer
• Browserslist
• Evil Martians

Dark transhumanism reading list:

• Permutation City by Greg Egan
• "Lena" — search "Lena story MMAcevski" or just Google "Lena story sci-fi wikipedia"
• The Quantum Thief by Hannu Rajaniemi (trilogy)
• Blindsight by Peter Watts

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 58 minutes on building PostCSS from real pain, open source strategy at scale, the LLM coordination problem, and dark transhumanism.

If you've ever used Tailwind, CSS Modules, or basically any modern frontend build tool — you've used PostCSS. This conversation with the person who built it is a rare look at what it actually takes to create infrastructure that the whole ecosystem ends up depending on, without planning for it.

Happy building,
Dan