Hacker News Reader

Comment by miki123211 | Hacker News Reader

I find that "vibe coders" (that is, people who do not know anything about programming, but nevertheless produce useful tools for themselves and others) are using a lot more tokens than we do as programmers.

I think this is partially because we're still attached to pre-LLM notions of architecture, good design and code quality (which are still important, but maybe less important than they once were and that we think they are), partially because their projects are in a messy state, so models have to work around the technical dept.

They're essentially trading off programmer time for LLM time (which is a good trade financially speaking).

View on HN

It's because they don't know data structures.

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." - Fred Brooks, The Mythical Man-Month (1975).

and essentially the same sentiment, three decades later:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - Linus Torvalds, git mailing list, 2006.

These things have not changed even though everything else is topsy-turvy. As-of current writing, I have yet to see an LLM make good data structure choices; they go for something that is superficially plausible but profoundly ill-considered (or rather, not considered at all), and then commonly burn tokens treating this implementation detail as a design invariant and trying to deal with the consequences by writing more code, instead of iterating directly upon the ill-fitting data at the root its problems.

If you're wondering, "does he mean the schema of let's say a db or other persistent store, or does he mean abstract/algebraic structures", the answer is yes to both, I think coding models are today shockingly weak when it comes to design reasoning in both domains.

Fortunately, their suggestibility means the same models will readily accept direction on the matter (perhaps even more so than on the structure of code), so I recommend doing just that, and (bonus!) this means your CS degree is still relevant.

Watch LLM start paying attention to data structures.

A coding model that can make genuinely well-considered data structure choices won't be a LLM, it'll be something more general.

While I agree that a coding model (such as Opus) by itself tends to act very shallowly, when it's driven by a harness like Claude Code, the combination seems to be a far more general thing than a LLM. It's capable of consistently making excellent data structure and architectural choices over large code bases. It imitates thinking about anything and it can drive itself for hours.

Honestly, if I simply fed it a sense of presence (I would repeatedly tell it what's going on right now and ask it to react if it thinks it should), it would feel eerily like AGI.

Coding models can already make well-considered data structure choices if given all the relevant context, but a non-programmer doesn't know the context to give it or even to tell it to optimize the data structure choice.

It's not going to happen naturally, the labs first need to implement a reinforcement learning pipeline that promotes it.

Falling back on a RL pipeline to cover gaps always strikes me as a more sophisticated version of the mechanical turk. If what we had was truly AGI wouldn't they be able to derive this from the data they already have.

Why would we care wether something truly is AGI or not?

It is useful. It may be dangerous. It has an impact. I care about that.

If you frame the conversation in those terms, they will.

One of the problems is that by default, they'll avoid changing data structures or architecture that is already written down.

Like a junior dev, they're correctly cautious about breaking things, so they prefer to write more code instead.

> If you frame the conversation in those terms, they will.

Indeed I realized recently that, when we complain about LLMs producing slop, that's in part because we dont ask them to refactor.

Coding agents won't, on their own, make a big change the user did not ask for. And this is fine.

I think it's not only a matter of token efficiency. If you don't know what you are doing development will eventually crawl to a halt invariably.

It's the compound counter-probability of success, so even a 99% efficient model will in time accumulate so much error that without conscious cleanup and steering, it becomes really unlikely really fast that anything could be changed in the code without affecting something else, no matter how many tokens you throw at it. It's the collapse of a complex system under the weight of sheer uncertainty of what the system actually does.

The llm are improving though maybe a year from now they can use it to fix the code

Maybe, it'll be exciting to see, and I'm all about accessibility, but in this case I also don't think it's about model capability or intelligence, it's the low information to noise ratio in the codebase. There just won't be enough information in the code itself to know what to fix. Fix how? What should it do? I'm really not sure you can reconstruct intention from a codebase created unsupervised.

1. Implement feature and write tests for the code

2. Make sure tests pass

3. <Every now and then> Review code for quality and fix - make sure tests pass.

4. Go to #1

Overly simplistic? Yes. But I would wager that this can go a long way, even for vibe coders.

I keep seeing this but I'm not sure it is effective in the long run *if unsupervised*.

"Review quality and fix" doesn't mean a lot without context.

Does it mean to remove unused features and simplify the underlaying code? Does it mean changing the data structures to better support future development? Does it mean improving performance because of bottlenecks?

You are supposed to tell an LLM what your codebase needs, but if you just vibe code without knowing the code, "review quality and fix" will have unexpected results

It's glaring to see who's still buying the positivists AI hype and who's done actual work with it.

AI is amazing, but people need to realise meaning and intention can't exist in a vacuum.

Commit the intention as specs. If tokens/intelligence become that much cheaper over time, then "throwing away the code" to start again becomes feasible.

Yeah, but not quite. I've done this with a project of mine, wrote it in python so it's easy and quick to read and debug, saved every work item and decision, done everything through agents so there was logs to go back to, and when I tried reimplementing in elixir everything fell apart.

Even after documenting decision and specs you need somehow to replay these in the correct sequence after you've validated these specs are still updated. Imagine you spec a feature, it works well, but in an edge case while doing a separate work you see something wrong, will you stop, fix and update the related spec? You will trust the AI will do this, and you guessed right, the counter-probability of success also has effect here, so eventually you will do undocumented changed in the codebase that won't reflect in the spec.

Now imagine all this but in the hands of someone that is an expert in their field but has zero notion what we are talking about here. Just look at the state of packages in R, the programming language, you'll see that technical competency and intelligence don't translate immediately to efficiency in a programming role.

A few days ago somebody linked to their own project: https://ljtn.github.io/epiq/

I haven't had time to dive into it yet, but I think it might structure things in the way you want.

Thanks! Will look into it.

This is something I didn't think about. Have a tech illiterate friendly harness that will keep asking technical questions the mainstream user won't be aware they needed be addressed, until there is enough evidence to either start an implementation or outright reject the project with suggestions where the user might look into to better prepare for another session.

Can confirm, I'm currently using Opus 5.5 to fix some Opus 4.5 slop from around this time last year.

Fixing code is not the same as fixing a fundamentally broken architecture. The latter requires understanding that the architecture is broken in the first place and that understanding comes from experience.

And most of the time the architecture is not just broken, it's just meaningless because of so much accumulated error. If it was just broken then other comments would make sense, just throw a more capable model at it, but LLMs can't really reproduce shakespeare out of white noise just yet.

We’re at 99% for a lot of stuff today, you get a third nine from council reviews and labs have another one or two nines in the pipeline. At five nines your task length horizon extends far beyond the current frontier model release cadence. More out of distribution tasks lose a nine or two, still revolutionary. You can get an extra nine from a good set of skills around slicing and distributing work according to model capabilities.

I think this is valid now, but not guaranteed to be valid forever. For engineers, there was a period where more checks, more tests, more auto code reviews improved results quite a bit. People were consuming tokens like crazy (including me). Then things improved via better effort/thinking levels, where you could see repeated code reviews plateaued, so now people don't really do that quite as much.

There was also a period where specifically OpenAI models would always have to comment something in code review and the builders were agreeable up to listening to each nitpick. If you'd have a loop of build->review->build->review, it would take maybe 5-7 rounds for it to 'settle' and not find the smallest nitpicks to argue about. Tried it this week with Astra reviewer and it's about 0-2 review loops (never had a LLM accept a change without nitpicking first try before Astra).

There was also a period where you'd have to give quite specific instructions for agents to keep iterating, but now agent are pretty proactive and try to finish tasks you give them unsurprisingly most of the time.

So, while there's a shortcoming of LLM+harness and engineers observe more tokens improve things even logarithmicly, you'll see more tokens seemingly abused by engineers.

I’m seeing hundreds of review loops before settling, with Astra/Sol

Could come down to the different nature of the work you guys do.

Astra is less nitpicky IME than Fable.

> you'd have a loop of build->review->build->review, it would take maybe 5-7 rounds for it to 'settle' and not find the smallest nitpicks to argue about.

You sure that wasn't just working at Microsoft?

For my normal work I take ownership of the code, and end up with the exact code I want. I still have it go off and do a good amount of work a lot of the time, still queue up multiple tasks at the same time a lot of the time. Sometimes I throw it all away and re-prompt once it's time to commit to it, sometimes edit what it made, sometimes have it edit what it made etc.

For all of my side projects I'm full-on vibe. Well, almost: I do have opinions on what kinds of code it should write and set up my projects to get that. But I don't LOOK at the code.

I use a LOT more tokens on my side projects. I can have it working more or less constantly and it doesn't take up that much of my attention, but it is FAR less token efficient.

Because that "vibe coders" didn't know and go through the fundamentals, thus they're wasting tokens with probably continuing the AI hallucination suggestions.

I've seen bunch of persons like this and that's kinda stupid because they're just blindly following AI's "suggestions" while they actually don't know what they're doing, then results on terrible code and architecture with "if it works, it works" mentality.

I (a programmer) just did a pretty large task with Opus 5.5 that was a perfect fit for a big token eating task. It ate into my weekly budget in a way that made me have to use anthropics one-off "reset" they offer now.

Long story: we have a big legacy desktop app. It uses a big legacy UI component (a grid control), which we had a license for in an old version. Fast forward 20 years, and to be able to move to a new runtime for our app, we need to update the component. Someone had bought the company making the component and now charges north of $1k per developer per year. So instead of doing this, we had just lived with the very old version.

We had long thought of writing our own control to replace the proprietary, but it was always going to be a man-year of work we thought. But I thought I'd give it a try with AI now. I told Opus: look at our uses of that control (tens of thousands of lines of code, it has over 100 instances across our User Interface). Write a new control that would compile with the exact same app syntax. First just make a dummy implementation that throws on every call. Then start implementing. Make a test suite that can run both with our new control and the proprietary control, and test everything, every function that can be called in its public interface and every state that can be inspected from the public API. Verify that everything behaves exactly the same, and lock it in with thousands of tests. Finally, check that the control _looks_ exactly the same as the proprietary one. Render to bitmaps, figure out the rendering logic from observation, such as arithmetic for padding, font sizes, and so on. Compare pixels until it's exactly the same.

Basically: it was a mammoth coding task, but it was so extremely well specified that an LLM could easily just do it. It's a clean-room implementation of something with no tests, but we had a test double that could provide 100% of the expected behavior. The description was extremely short. "Make a new thing that works like the old thing, and prove that it does". Opus 5.5 finished this in a number of hours. 500 source files, several thousand unit tests, and html reports with image diffs from the reimplementation and the original control. It did not use any disassembly or such "cheating". Only observation of the public API and the behavior. Do we need to deeply understand the implementation? Does the architecture matter? Not much in this case I'd argue. It was a black box to begin with and it remains a black box. If we notice a bug, we can always point it to the original proprietary control and say "there's a behavioral difference when doing X" and it will fix it, and lock it down with tests.

As a programmer it's kind of chilling. I had recreated for a few tens of dollars something that would cost $1000 per year to buy. Obviously it's not a complete implementation only the parts of the API we use. It likely still has some bugs. We don't get support, we get to maintain it ourselves. But the rate of reverse engineering this thing "black box" was frightening. It hasn't created anything novel. But we must realize that as programmers some times we have man-years of work that just isn't novel. And in the past, we didn't do this work at all.

I wonder if those who write and sell libraries like this will start having explicit no-reverse-engineering EULAs soon? Perhaps even explicitly mentioning AI/LLM use in analysis and reimplementation?_ Obviously the library we reimplemented was from 2005 so didn't mention AI... (It doesn't mention reverse-engineering either, luckily).

Most products do in fact have an anti-reverse engineering clause in their EULA, to be fair, it's been a standard EULA term for a long while. It's just that no one cares anymore...

Yes, and usually in the form "You may not reverse engineer, decompile, or disassemble the SOFTWARE or any of its constituents, except and only to the extent that applicable law expressly permits". (This is the concrete example from this software). And as far as I understand, this means that so long as you stay short of decompilation - you can reimplement as much as you want.

The law that covers this (in the EU) is EU Directive 2009/24/EC, where Article 5 is the reverse-engineering-without-decompilation.

> The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

This is pretty difficult to parse, but luckily there is a ruling from the European Court of Justice on this: SAS Institute Inc. v World Programming Ltd (Case C-406/10), delivered on May 2, 2012.

SAS Institute claimed that World Programming Ltd (WPL) infringed its copyright by studying the behavior of the SAS software system and writing a competing program (the World Programming System) that emulated its exact functionality and used the same data file formats. WPL did not have access to SAS's source code and did not copy any of its literal text or internal structural design.

CJEU:

> "It must therefore be held that the copyright in a computer program cannot be infringed where, as in the present case, the lawful acquirer of the license did not have access to the source code of the computer program to which that license relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program".

Which is a good find. But this is where I wonder if LLM-based reverse engineering is going to creep into either law (via lobbying) and/or EULA's, because this "observe every single state of the program for every single mutation" was simply not a viable mode of reverse engineering in the past. Or, it was at least always cheaper than just buying the software! Not so any more.

Or alternatively, that programs stop having so many observable states, making more things public. But for libraries as in this case, the whole product IS the public API. Without a rich public API, the library can't be sold. And with it, I can observe it and copy it - because it's internal workings are "too simple" not to be deduced from the public API. In short: a UI control is a ton of hard-to-write but easy to copy boilerplate code. And selling this has been an industry, but I wonder if it will be for very long.

"And as far as I understand, this means that so long as you stay short of decompilation - you can reimplement as much as you want."

Yes, but my point is that.... go on github, you'll find tons of decomps. And many more done just privately too. One of the No Man's Sky devtalks start with "yeah we decompiled the terrain generation from this other game, implemented it in our prototype, it didn't work okay, here's how we've learnt from it to make something better". This was in 2016. More recently, this has been going on way more openly, even full AI-assisted decomps thrown up onto GitHub casually. It might be the letter of law or included in Terms of Service but no one cares really.

That and some have bridged the gap with tooling. starter projects+ Strick typing + dead code detection, linting rules and today's models can get you pretty far, especially if you plan out some basic architectural patterns with your starter kit.

It's not perfect but any means but it helps manage ones sanity.

Plenty of vibe coders who know a lot about programming producing useful tools and using tokens too.

Indeed, I've been coding for ~25 years (competitively and in open source for many of them) and I max out at least two subscriptions' worth of tokens every week across a half dozen active projects.

I still code "by hand" sometimes (mostly Ruby/Rails, C#, and random languages for code golf) but just for fun at this point. Serious projects started being 95-100% AI over a year ago.

What are your half dozen active projects? And did AI use make you more ambitious about what those projects could be?

Architecture is essential for anything complex. With bad architecture, complexity quickly outruns any model.

I’ve noticed some people re-prompt big tasks from scratch rather than iterating. This burns tokens very fast.

I mean, they're trading off the time to learn to program for LLM time. Which might make sense! Locally.

But, in my experience, the projects where I have a constant pulse on the core design and abstractions in the code end up moving much faster than the ones where I don't. And I've been working on one of each at work recently, so I have a decent point of comparison.

If you have well-specified tasks, you can easily reach 10 simultaneous agents working on disjoint parts of the code in worktrees. That consumes tokens pretty quickly!

Are they also telling each other what to do? Because I for one can't assign and keep track of 10 things at once.

I create large hierarchical plans, and have a coordinator agent divvy up the work. It's extremely effective.

I created an orchestration skill for myself (using herdr but any persistent mechanism works). So I then only interact with a front session and it will triage and dispatch each request to the relevant spaces (each of them can have multiple worktrees of the same project), summarize movements and pending decisions for me all at once. I do not directly interact with a multiplexer or any dashboard.

This seems complex and expensive, and I suppose the only reason to do this is because you want to generate code faster? Do you really have so much code to write that a single LLM is too slow?

And then on top of that you need another agent to manage merging all of the subagent code together?

I don't do this at my day job (coworkers would be pretty mad). This is for software ideas that come up weekly that I need to execute to at least MVP before I ever need branching/merging

Not complex at all, only one extra session other than the ones doing work and it's on a dumb model and can be thrown away & restarted because it only dispatches work, not doing anything.

I do everything in there, collecting requirements, kick off research, branching, merging, not one other agent on top. I considered making that orchestration command llm-powered but it's not justified at my current use.

It's not more expensive, in fact I could have just chugged along with the slow and manual session by session work but I have a claude subscription and another GLM one (the most low cost basic tier, not even much), that just sit there collecting dust if I don't put them to use in a more efficient way.

And doing session by session would face your problem when context switching too much become unscalable.

Personally, it takes me longer to write the specifications than it takes the model to implement them (and it takes me much longer to review the resulting code, although maybe that makes me old-fashioned). Consequently I do not have enough tasks to run more than one agent at a time.

I'm exactly in this situation, and at the same time I get so many jumpscares when reviewing the code that I'm not going to stop anytime soon.

Exactly. I don't understand how so many developers seem to have a long tail of well written task specifications ready to submit to the LLM. Who produces them?

LLMs are good at cleaning up tech debt. Give them lots of small refactorings or dig out those crusty old P4 tickets. There's a lot of easy stuff for them that requires very little specification and very high probability they'll get it right the first time, especially if you can point them at an example done right.

You don't need to have well written specifications. Just need to point it in the right direction and to know what you are doing so you can ask it to generate a plan, review and then ask it to implement.

I have conversations with a smart model, and then the model writes the spec. I review and approve the spec, and it dispatches.

For a concrete example, check out this random plan [0]. A detailed spec followed by the exact implementation tasks that will be executed by the subagents.

[0]: https://github.com/bensyverson/woodcase/blob/main/project/20...

Not sure why I'm being downvoted for stating the obvious. To the parallel agent skeptics: I was also a skeptic until a month or two ago. I would run one agent, watch it carefully, and check its work. However the models got good enough that it was more efficient to do more work in parallel, then have a single agent integrate the changes with a critical eye, then run a code quality pass, and then I would take a look a it and kick the tires behaviorally.

It does involve letting go and not micromanaging every code convention and implementation detail, but that is the same skill you need when leading engineering teams.

I am actually going to go out on a limb and guess the opposite of this is true, and that on average vibecoders burn tokens less readily than veteran software engineers. I could list several reasons why I think this would be likely. No idea which of us is empirically right, though.

(With exceptions for what I can only call the "manic vibecoders" with like 10 simultaneous weird slopprojects they're spewing out at once. Generally with each project itself being something related to vibecoding. Steve Yegge being an example of a "manic vibecoder-actual programmer" hybrid.)

I’d think this matches my hypothesis. I’d say that I spend more tokens rewriting and fixing things, so that contributes more.

Also, I’d imagine the token-maxed user is a programmer that lives in chat. I’ll admit to having asked the LLM to move a method up/down in a file, and watched it burn tokens for a minute thinking and executing a menial task.

Same. I spend tokens on so much more than just the initial implementation of a feature I have an idea for.

This I don't understand. I'm faster at moving the method then at prompting the LLM to do so

Sometimes I don’t have the text editor/IDE open, and I’m just looking at the code in a PR or similar UI.

"Sometimes"? I and I think many other people have been doing exactly this for most of 2026, assuming they look at the diff/PR at all and aren't all-in on dark factories.

Sure, if it's right there in front of you in the editor. But if have to locate the file and the location within the file, it's easier to just type out what I want and have the LLM do it.

I would be faster than Claude or Gemma if I did it.

That's a big if though and the blank page syndrome was already getting worse long before AI.

With age, it becomes easier and easier to get angry at someone or something until they work as expected than it is to actually do it.

I think this is why we've been seeing the genius coders from two generations ago embracing vibe coding even before it was cool or any good.

LLMs are sometimes stupid and get confused when you change the files without them knowing. So asking them to do even simple things keeps the context in sync.

Plus you get a bonus random line "methods are all on the top" in the commit message that makes no sense to anybody.

>"but maybe less important than they once were"

On browser based front ends it seems to be the case for me even though I still impose certain guidelines. On my C++ backends, no fucking way. Even the best models produce working but absolutely disastrous non scalable (performance wise and design wise) code unless watched over like a hen. Having said that - the value I get in either case is enormous.

LLMs these days write better architected and produced code than most programmers, so the fallacy that LLMs produce slop code is increasingly false.

Every new generation of model goes and cleans up the slop of its predecessor in my code bases, and it has turned out to be quite effective.

Last year I held off on implementing a few features knowing that a model like Opus 5.5 was around the corner. I'm now implementing them in a much more efficient and quality manner than I could have fall of 2025.

Indeed. Maybe people down voting me don't like to admit it but when models train on the entirety of human input you can assume they'd be better than the average human.

This is probably why web development and scripts are much more effective domains while anyone working on anything even slightly off the track is either tearing their hair out or writing a new layer of software to write the software.

Reply on news.ycombinator.com