lessvibes: a plugin for making sure I do not become a fucking moron any faster than time already requires

I have been thinking a lot about AI coding tools lately.

Not in the fake moral-panic way. Not in the “real programmers type every character by hand in a dark room lit only by vim” way. I use the tools. The tools are useful. Anyone pretending otherwise is either lying or writing Java for fun.

The problem is not that AI coding tools are bad.

The problem is that they are too convenient in exactly the wrong place.

They make it dangerously easy to end up with code in your repo that you did not really read, did not really trace, and do not really understand. A giant slab of output appears, you skim it, rename two variables, maybe run the tests, and now congratulations: you are responsible for a system you technically approved but do not actually know.

This seems bad.

So I have been working on a plugin idea called lessvibes.

The basic goal is simple: I want something in the editor that pushes back, at least a little, against the smooth-brained workflow of sitting there like a fucking lemming waiting to click Accept.

Because let’s be honest, something has to.

If nothing pushes back on that loop, a lot of us are going to get dumber. Not overnight. Not in some dramatic sci-fi way. Just slowly, comfortably, one magical completion at a time, until our main skill is recognizing when the machine produced something that looks plausible.

That is not a great direction for software development, or for my own brain, it never got much exercise to begin with.

What lessvibes is supposed to do

The core idea behind lessvibes is that the IDE should notice when a coding session has turned into something passive.

Not “evil.” Not “fraudulent.” Just passive.

If a giant block of code lands in the editor faster than any human would normally type it, that should be treated as a moment worth paying attention to. Not because generated code is automatically wrong, but because that is the exact moment where understanding tends to quietly fall off a cliff.

So the plugin would try to estimate how a session is actually happening.

Not with fake certainty. Not with some creepy fantasy that it can prove who “really authored” every line. More like a transparent, best-effort read based on signals such as:

• manual typing and editing
• paste events and bulk insertions
• accepted AI completions when the IDE exposes them
• edits that arrive much faster than a human would normally type
• file opens, tab focus, scrolling, dwell time, follow-up edits
• whether the files that got changed were ever actually opened and manually touched afterward

The point is not to solve philosophy.

The point is to notice when the workflow has quietly become:

accept output, skim it badly, and emotionally hope for the best

That is a real workflow now. A lot of people are doing it. Some of them are doing it successfully, which honestly makes it even more dangerous.

The part I actually care about

The feature I like most is the code-flow view.

If the plugin decides a change was probably AI-generated, heavily pasted, or otherwise suspiciously vibey, it should open a bounded left-to-right execution path through the code.

Up to five panes.

The leftmost pane starts at the main entry point. Then each pane to the right shows the next relevant file in the flow. Not the whole dependency graph. Not one of those giant architecture diagrams that looks like a serial killer’s wall. Just the important path, bounded on purpose, so a normal human can actually follow it.

That boundedness matters.

A lot of developer tools confuse “more complete” with “more useful.” I do not want a giant spiderweb of boxes and arrows that makes me want to close my laptop and go lie on the floor. I want something that says:

hey idiot, it starts here, then goes here, then here, then here. maybe read these before you pretend you understand the feature

That is the product.

And if the project uses containers, the leftmost pane should be split horizontally. Top half: the main code entry point. Bottom half: the Dockerfile or Compose file. Because a surprising amount of confusion in modern software is not just “what does this code do?” It is “what the hell is the runtime context?” The app starts in one place, the environment is defined somewhere else, and both are easy to ignore when the code arrived in your editor in a burst of machine confidence 30 seconds ago.

So the plugin is not just about surfacing generated code. It is about surfacing execution and context together, in a way that is fast enough that I might actually use it instead of admiring it once and forgetting it exists.

The real workflow I want

What I want the plugin to encourage is an older and healthier loop:

open -> read -> edit

Not:

accept -> vibe -> move on

So lessvibes should care about things like:

• which generated files were never opened
• which generated files were opened but never manually edited
• which inserted blocks later got revised by hand
• whether the important files in a generated path ever saw real follow-up edits
• whether I spent time reading and navigating, or just waved the code through customs

To me, those are more meaningful metrics than some bullshit chart about lines added.

I do not care how many lines “I wrote” if a glorified autocomplete snowblower dumped them into my repo and I never looked back. The meaningful question is whether I actually went into the code after it appeared.

That is what matters.

Not purity. Not virtue. Not pretending I am above the tools. Just evidence that my brain stayed in the loop.

What this is not

This is not an anti-AI project.

It is also not a surveillance tool, and if it turns into one the whole thing should be thrown in the trash.

It should not block AI. It should not shame people for using AI. It should not send sensitive code off-machine by default. It should not pretend it always knows exactly what happened. And it definitely should not become one of those dead-eyed enterprise dashboards where some manager decides Steve was only 63% hands-on this sprint and therefore needs a meeting.

Absolutely not.

If this idea works at all, it only works if users trust it.

So the defaults should be:

• local-first
• clear about what signals are being tracked
• no hidden scoring
• opt-in nudges
• exportable or resettable session history

Basically: helpful, not narc shit.

Why I think this matters

AI coding tools are very good at helping code appear.

They are much worse at helping you metabolize what just happened.

That is the gap.

Right now the ecosystem is mostly optimized around speed, convenience, and the pleasant little dopamine hit of watching the diff get bigger. But “the diff got bigger” and “I understand the system better” are very much not the same thing. In fact, they may now be moving in opposite directions.

And I do not think the answer is fake purity where everyone pretends to reject the tools and return to some mythological golden age of hand-crafted software. The tools are here. They are useful. I am going to use them. Most people are.

What I want is some counter-pressure.

Something that makes it a little harder to drift into a state where I am technically present for the coding session but functionally just acting as a biological approval button.

Because that is the real failure mode here.

Not evil AI. Not the end of programming. Just a slow humiliating slide into becoming the guy who watches the machine cook and occasionally says, “yeah that looks right.”

I would rather avoid that outcome if possible.

So yeah

That is lessvibes.

A plugin for making sure I do not become a fucking moron any faster than time already requires.

If AI is going to stay in the editor, then the editor should do more than help me accept code. It should help me understand what just landed, where it flows, what I have actually looked at, and whether I touched the important parts with my own brain before I ship some haunted Kotlin side project into the world.

That seems like a worthwhile improvement.