A version is essentially a marker, a seal of the codebase at a specific point in time. However, code is complex, and every change involves trade-offs. Describing how a change affects the code can be tricky even with natural language. A version number alone can’t capture all the nuances of a release. That’s why we have changelogs, release notes, and commit messages to provide more context.

I see versioning as a way to communicate changes to users — a contract between the library maintainers and the users to ensure compatibility and stability during upgrades. As a user, you can’t always tell what’s changed between v2.3.4 and v2.3.5 without checking the changelog. But by looking at the numbers, you can infer that it’s a patch release meant to fix bugs, which should be safe to upgrade.

In the JavaScript ecosystem, especially for packages published on npm, we follow a convention known as Semantic Versioning, or SemVer for short. A SemVer version number consists of three parts: MAJOR.MINOR.PATCH. The rules are straightforward: MAJOR: Increment when you make incompatible API changes. MINOR: Increment when you add functionality in a backwards-compatible manner. PATCH: Increment when you make backwards-compatible bug fixes.

However, humans perceive numbers on a logarithmic scale. We tend to see v2.0 to v3.0 as a huge, groundbreaking change, while v125.0 to v126.0 seems a lot more trivial, even though both indicate incompatible API changes in SemVer. This perception can make maintainers hesitant to bump the major version for minor breaking changes, leading to the accumulation of many breaking changes in a single major release, making upgrades harder for users.

The reason I’ve stuck with v0.x.x is my own unconventional approach to versioning. I prefer to introduce necessary and minor breaking changes early on, making upgrades easier, without causing alarm that typically comes with major version jumps like v2 to v3. Some changes might be "technically" breaking but don’t impact 99.9% of users in practice.

There’s a special rule in SemVer that states when the leading major version is 0, every minor version bump is considered breaking. I am kind of abusing that rule to workaround the limitation of SemVer. With zero-major versioning, we are effectively abandoning the first number, and merge MINOR and PATCH into a single number (thanks to David Blass for pointing this out)

In an ideal world, I would wish SemVer to have 4 numbers: EPOCH.MAJOR.MINOR.PATCH. The EPOCH version is for those big announcements, while MAJOR is for technical incompatible API changes that might not be significant. This way, we can have a more granular way to communicate changes.

I am proposing a new versioning scheme called 🗿 Epoch Semantic Versioning, or Epoch SemVer for short. It’s built on top of the structure of MAJOR.MINOR.PATCH, extend the first number to be the combination of EPOCH and MAJOR

The format is as follows: {EPOCH * 1000 + MAJOR}.MINOR.PATCH EPOCH: Increment when you make significant or groundbreaking changes. MAJOR: Increment when you make minor incompatible API changes. MINOR: Increment when you add functionality in a backwards-compatible manner. PATCH: Increment when you make backwards-compatible bug fixes.

For example, UnoCSS would transition from v0.65.3 to v65.3.0 (in the case EPOCH is 0). Following SemVer, a patch release would become v65.3.1, and a feature release would be v65.4.0. If we introduced some minor incompatible changes affecting an edge case, we could bump it to v66.0.0 to alert users of potential impacts. In the event of a significant overhaul to the core, we could jump directly to v1000.0.0 to signal a new era and make a big announcement.

We shouldn’t need to bump EPOCH often. It’s mostly useful for high-level, end-user-facing libraries or frameworks. For low-level libraries, they might never need to bump EPOCH at all (ZERO-EPOCH is essentially the same as SemVer).

Andrej is an extremely talented and experienced programmer—he has no need for AI assistance at all. He’s using LLMs like this because it’s fun to try out wild new ideas, and the speed at which an LLM can produce code is an order of magnitude faster than even the most skilled human programmers. For low stakes projects and prototypes why not just let it rip? When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes.

If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development. The usage of an LLM to support that activity is immaterial.

The job of a software developer is not (just) to churn out code and features. We need to create code that demonstrably works, and can be understood by other humans (and machines), and that will support continued development in the future. We need to consider performance, accessibility, security, maintainability, cost efficiency. Software engineering is all about trade-offs—our job is to pick from dozens of potential solutions by balancing all manner of requirements, both explicit and implied.

I think vibe coding is the best tool we have to help experienced developers build that intuition as to what LLMs can and cannot do for them. I’ve published more than 80 experiments I built with vibe coding and I’ve learned so much along the way. I would encourage any other developer, no matter their skill level, to try the same.

As many have pointed out , not all code written with AI assistance is vibe code. Per the original definition , it’s code written in contexts where you “forget that the code even exists.” Or as the fairly fleshed-out Wikipedia article puts it: ”A key part of the definition of vibe coding is that the user accepts code without full understanding.”

Our AI minions are also exceptional tools for learning when you move too far towards the high-vibes-low-understanding end of the spectrum. I particularly like getting Claude to write me targeted exercises to practice new concepts when I get lost in generated functions or fail to implement something correctly sans-AI. Even though doubling-down up on engineering skills sometimes feels like learning to operate a textile loom in 1820.

with agents, you don’t have to do all the ugly toil of bidirectional copy/paste and associated prompting, which is the slow human-y part. Instead, the agent takes over and handles that for you, only returning to chat with you when it finishes or gets stuck or you run out of cash.

As fast and robust as they may be, you still need to break things down and shepherd coding agents carefully. If you give one a task that’s too big, like "Please fix all my JIRA tickets", it will hurl itself at the problem and get almost nowhere. They require careful supervision and thoughtful problem selection today. In short, they are ornery critters.

it’s not all doom and gloom ahead. Far from it! There will be a bunch of jobs in the software industry. Just not the kind that involve writing code by hand like some sort of barbarian.

But for the most part, junior developers – including (a) newly-minted devs, (b) devs still in school, and (c) devs who are still thinkin’ about school – are all picking this stuff up really fast. They grab the O’Reilly AI Engineering book, which all devs need to know cover to cover now, and they treat it as job training. They’re all using chat coding, they all use coding assistants, and I know a bunch of you junior developers out there are using coding agents already.

I believe the AI-refusers regrettably have a lot invested in the status quo, which they think, with grievous mistakenness, equates to job security. They all tell themselves that the AI has yet to prove that it’s better than they are at performing X, Y, or Z, and therefore, it’s not ready yet.

It’s not AI’s job to prove it’s better than you. It’s your job to get better using AI

Less Emphasis on Syntax, More on Problem SolvingThe fundamentals and skills themselves are evolving. Most introductory computer science courses focus on code syntax and getting programs to run, and while knowing how to read and write code is still essential, testing and debugging—which aren’t commonly part of the syllabus—now need to be taught more explicitly.

Zingaro, who coauthored a book on AI-assisted Python programming with Porter, now has his students work in groups and submit a video explaining how their code works. Through these walk-throughs, he gets a sense of how students use AI to generate code, what they struggle with, and how they approach design, testing, and teamwork.

educators are modifying their teaching strategies. “I used to have this singular focus on students writing code that they submit, and then I run test cases on the code to determine what their grade is,” says Daniel Zingaro, an associate professor of computer science at the University of Toronto Mississauga. “This is such a narrow view of what it means to be a software engineer, and I just felt that with generative AI, I’ve managed to overcome that restrictive view.”

“We need to be teaching students to be skeptical of the results and take ownership of verifying and validating them,” says Matthews.Matthews adds that generative AI “can short-circuit the learning process of students relying on it too much.” Chang agrees that this overreliance can be a pitfall and advises his fellow students to explore possible solutions to problems by themselves so they don’t lose out on that critical thinking or effective learning process. “We should be making AI a copilot—not the autopilot—for learning,” he says.

I do a pretty good job of channeling my procrastination into adjacent creative tasks which, in the end, influence, shape, and improve the chunks of work I do complete. And that looks like productivity from the outside. But trust me, from the inside, it usually just feels like avoidance and procrastination. But I’ve learned to accept that’s the cost of doing the kind of work I feel good at, so I let it be what it is.

The particularly nice thing about coding is that it offers many little “wins”: I get a function working, I figure out a piece of design

“Can’t face work? Then cultivate some side projects — and channel your work-avoidance into fun opportunities to learn” and once you’re done, you’ll 1) have something productive to show for it, and 2) be much more fit, rested, and ready to tackle that project at work. In other words: rather than fight your penchant for procrastination, work with it. It’s a judo move: don’t fight your enemy, use its momentum against it for your benefit.