Live data from Hacker News

The Vibe Tax

insufferable.dev

31–40 of 137 posts

Re: The Vibe Tax

#31
post #27

Earlier quoted context omitted.

I have found what works well is to modularise the code as much as possible and get an agent to work within a very limited scope. Break everything down well using SRP with well defined interfaces and let the agent work on small problems. Then when it shits the bed, there’s a smaller blast radius and you can strip back and try again. I think seasoned developers, over time, learn how to work a code base and design compo…

I think this is the only sensible way to work with agents, if you care about code quality and reliability but still want the benefits of AI. There seem to be three camps that people more or less fall into: (a) AI is terrible/bad/evil and should never be used, (b) you should one-shot everything and be happy if it seems to "work" when you try it, (c) the middle ground, where the AI writes code which you carefully revie…

I think c is the only way it can sustainably work. The idea of b, that software is running and nobody there knows how it works, doesn’t seem like a good foundation for a business to run on.

Re: The Vibe Tax

#32
post #29

i'm not sure why people expect agents to one shot everything to perfection with just a prompt. There's a reason why we talk about software development lifecycle, design, architecture, testing ... It's because it's been the most reliable way to build and ship software. We shouldn't expect discard this and expect agents to perform well outside of this. I'm treating LLM agents as junior devs who happen to have vast know…

> i'm not sure why people expect agents to one shot everything to perfection with just a prompt.

because that's how agents are marketed.

Re: The Vibe Tax

#33

I feel like I'm living in a parallel universe when I read these types of posts. My agents have never created code that is straight-up garbage and I have never flushed a week's worth of tokens down the toilet. I just can't identify with all the constant complaints about AI-assisted coding. And my biggest project isn't some hello world app. It's a self-hosted, privacy-focused personal financial management application t…

Personal finance tracker - the TODO app of 2026.

Re: The Vibe Tax

#34

I tried, but I’m not sure I understand. The vibe tax is caused by the model trying to one-shot everything and doing so requires unnecessary tests? How are vibe coders training the model over months? Do you mean their sessions and preferences are being fed back into the RL?

I'll try to explain my experience with this. I've noticed the AI has a tendency to overengineer scaffolding. For instance, I asked it to help me with a refactor, and it erected this massive 100kloc function registry, and then caused GitHub CI to verify the contracts every single commit, which took upwards of 30 minutes (I suspect this proclivity is widespread and has contributed to their recent issues).

As if this wasn't bad enough, it also was not smart enough to regenerate the evidence in these contracts as it changed the underlying source code. So it would get in a loop where it would update code -> commit -> 15 minutes later CI would error citing the contracts weren't updated -> it would fix the contracts -> 15 minutes later CI would error because the fix was wrong -> it would fix the fix and commit -> 15 minutes later contracts would fail -> contracts were fixed again and this time maybe 30 minutes later it would pass, maybe it errors again.

This loop could go on all day every day if someone wasn't paying attention because the agent has no concept of time or wasted work. It's an AI livelock of sorts, but it will eventually converge in my experience. It'll just take 10x longer (literally like 20+ hours) than if you just intervene and tell it knock it off, so it feels like lighting money on fire (hence the tax).

That's why I feel like this vibe coding stuff has to actually be monitored, like a Tesla system -- because like a Tesla system it cannot be trusted to not crash into the proverbial code wall.

Re: The Vibe Tax

#35
You can absolutely prompt agents not to write tests, or not to write extraneous asserts, or whatever, and I find that generally quite useful for the kind of code I write. I don't think it's "months of users training it", it's more that a lot of people do want a one-shot agent, and having a good test set really helps that.

Re: The Vibe Tax

#36
post #27

Earlier quoted context omitted.

I have found what works well is to modularise the code as much as possible and get an agent to work within a very limited scope. Break everything down well using SRP with well defined interfaces and let the agent work on small problems. Then when it shits the bed, there’s a smaller blast radius and you can strip back and try again. I think seasoned developers, over time, learn how to work a code base and design compo…

I think this is the only sensible way to work with agents, if you care about code quality and reliability but still want the benefits of AI. There seem to be three camps that people more or less fall into: (a) AI is terrible/bad/evil and should never be used, (b) you should one-shot everything and be happy if it seems to "work" when you try it, (c) the middle ground, where the AI writes code which you carefully revie…

I think it must depend at least partially on the task, too. At the extreme, there are things where you won't care beyond "it seems to work" because you only needed it to run once and it got useful results.

Re: The Vibe Tax

#37
I’ve never had an agent fail to write the actual implementation. Has it done so badly, yes, but not nothing but tests. This sounds to me like a rare case that doesn’t generalize.

If the general idea is that these agents write too many tests, sure I guess? ‘Too many tests’ doesn’t sound like a failure case of engineering to me; typically software has had too few tests. Also, a lot of the power of these agents is their ability to self-verify and correct, which the test loop is a part of.

Nobody is making you pay this supposed tax. Just tell it not to write tests.

Re: The Vibe Tax

#38
post #32
post #29

i'm not sure why people expect agents to one shot everything to perfection with just a prompt. There's a reason why we talk about software development lifecycle, design, architecture, testing ... It's because it's been the most reliable way to build and ship software. We shouldn't expect discard this and expect agents to perform well outside of this. I'm treating LLM agents as junior devs who happen to have vast know…

> i'm not sure why people expect agents to one shot everything to perfection with just a prompt. because that's how agents are marketed.

I've never seen model providers marketing like that. What examples have you seen?

Re: The Vibe Tax

#39

I feel like I'm living in a parallel universe when I read these types of posts. My agents have never created code that is straight-up garbage and I have never flushed a week's worth of tokens down the toilet. I just can't identify with all the constant complaints about AI-assisted coding. And my biggest project isn't some hello world app. It's a self-hosted, privacy-focused personal financial management application t…

[deleted]

Re: The Vibe Tax

#40

I tried, but I’m not sure I understand. The vibe tax is caused by the model trying to one-shot everything and doing so requires unnecessary tests? How are vibe coders training the model over months? Do you mean their sessions and preferences are being fed back into the RL?

Forgot where i saw it discussed; If you observe recent model benchmarks over the past year; the performance is slowly climbing, but if you divide by the token count; the score per token is dropping. The current trend in state-of-art LLM coding agents is giving more output, thinking longer and checking the results more to catch mistakes. Be it an economics inventive to make users burn through their quota or show incre…

It should be expected that more tokens give diminishing returns. Minimally, there's no limit on tokens but there is on quality of output (you can't reach negative bugs, or negative execution time). The graphs I've seen show a curved "frontier" of the tradeoff, and that line has improved over model generations.

That said, the companies are incentivized to sell you tokens, and therefore to have the models use as many tokens as they think you'll let them get away with for a given task / level of performance.

Post reply on HN