Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The 100 hour gap between a vibecoded prototype and a working product

kanfa.macbudkowski.com

Post reply on HN
Print view View original

271–280 of 362 posts

Re: The 100 hour gap between a vibecoded prototype and a working product

#271

Post by andriy_koval »

jcgrillo wrote: post #269
andriy_koval wrote: post #232

Earlier quoted context omitted.

it doesn't mean Java is optimal or close to optimal choice. Amount of extra effort they do to achieve goals could be significant.

Optimal in what sense? In the java shops I've worked at it's usually viewed as a pretty optimal situation to have everything in one language. This makes code reuse, packaging, deployment, etc much simpler. In terms of speed, memory usage, runtime characteristics... sure there are better options. But if java is good enough, or can be made good enough by writing the code correctly, why add another toolchain?

> But if java is good enough, or can be made good enough by writing the code correctly,

"writing code correctly" here means stripping 95% of lang capabilities, and writing in some other language which looks like C without structs (because they will be heap allocated with cross thread synchronization and GC overhead) and standard lib.

Its good enough for some tiny algo, but not good enough for anything serious.

Re: The 100 hour gap between a vibecoded prototype and a working product

#272

Post by shepherdjerred »

My experience is that Claude Code, when used appropriately, can produce work better than most programmers.

"when used appropriately" means:

- Setting up guardrails: use a statically typed language, linters, CLAUDE.md/skills for best practices.

- Told to do research when making technical decisions, e.g. "look online for prior art" or "do research and compare libraries for X"

- Told to prioritize quality and maintainability over speed. Saying we have no deadline, no budget, etc.

- Given extensive documentation for any libraries/APIs it is using. Usually I will do this as a pre-processing step, e.g. "look at 50 pages of docs for Y and distill it into a skill"

- Given feedback loops to check its work

- Has external systems constraining it from making shortcuts, e.g. "ratchet" checks to make sure it can't add lint suppressions, `unsafe` blocks, etc.

And, the most important things:

- An operator who knows how to write good code. You aren't going to get a good UI/app unless you can tell it what that means. E.g. telling it to prioritize native HTML/CSS over JS, avoiding complexity like Redux, adding animations but focus on usability, make sure the UI is accessible, etc.

- An operator who is steering it to produce a good plan. Not only to make sure that you are building the right thing, but also you are explaining how to test it, other properties it should have (monitoring/observability, latency, availability, etc.)

A lot of this comes down to "put the right things in the context/plan". If you aren't doing that, then of course you're going to get bad output from an LLM. Just like you would get bad output from a dev if you said "build me X" without further elaboration.

Re: The 100 hour gap between a vibecoded prototype and a working product

#273

Post by efromvt »

bauerd wrote: post #75
alexpotato wrote: post #10

I work as a DevOps/SRE and have been doing it FinTech (bank, hedge funds, startups) and Crypto (L1 chain) for almost 20 years. My thoughts on vibe coding vs production code: - vibe coding can 100% get you to a PoC/MVP probably 10x faster than pre LLMs - This is partly b/c it is good at things I'm not good at (e.g. front end design) - But then I need to go in and double check performance, correctness, information flow…

>Testing workloads that take hours to run still take hours to run with either a human or LLM testing them out (aka that is still the bottleneck) Absolutely. Tight feedback loops are essential to coding agents and you can’t run pipelines locally.

This is where I think we need better tooling around tiered validation - there's probably quite a bit you can run locally if we had the right separation; splitting the cheap validation from the expensive has compounding benefits for LLMs.

Re: The 100 hour gap between a vibecoded prototype and a working product

#274

Post by phillipclapham »

cyk21 wrote: post #254
phillipclapham wrote: post #85

[flagged]

This. Additionally, the author seems to build an app just for the sake of building an app / learning, not to solve any real serious business problem. Another "big" claim on LLM capabilities based on a solo toy project.

[flagged]

Re: The 100 hour gap between a vibecoded prototype and a working product

#275

Post by ncruces »

I built my latest side project (a Wasm to Go "transpiler") precisely as a way to push the limits of what I could do with an LLM/agent.

It sped me up (and genuinely helped with some ideas) but not 10x.

The bits I didn't design myself I definitely needed to inspect and improve before the ever eager busy beaver drove them to the ground.

That said, I'm definitely impressed by how a frontier model can "reason" about Go code that's building an AST to generate other Go code, and clearly separate what's available at generation time vs. at runtime. There's some sophistication there, and I found myself telling them often "this is the kind of code I want to generate, build the AST."

I also appreciated how faster models are good enough at slightly fuzzy find and replace. Like I need to do this refactor, I did two samples of it here, can you do these other 400? I have these test cases in language X, converted 2, can you do the other 100? Even these simple things saved me a lot of time.

In return I got something that can translate SQLite compiled to Wasm into 500k lines of Go in about a month of my spare time.

https://github.com/ncruces/wasm2go

Re: The 100 hour gap between a vibecoded prototype and a working product

#276

Post by phillipclapham »

dijksterhuis wrote: post #263
AstroBen wrote: post #130

Earlier quoted context omitted.

I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.

- version 1 -- we build what we think is needed - version 2 -- we realise we're solving a completely different problem to what is needed - version 3 -- we build what is actually needed

[flagged]

Re: The 100 hour gap between a vibecoded prototype and a working product

#277

Post by jcgrillo »

andriy_koval wrote: post #271
jcgrillo wrote: post #269

Earlier quoted context omitted.

Optimal in what sense? In the java shops I've worked at it's usually viewed as a pretty optimal situation to have everything in one language. This makes code reuse, packaging, deployment, etc much simpler. In terms of speed, memory usage, runtime characteristics... sure there are better options. But if java is good enough, or can be made good enough by writing the code correctly, why add another toolchain?

> But if java is good enough, or can be made good enough by writing the code correctly, "writing code correctly" here means stripping 95% of lang capabilities, and writing in some other language which looks like C without structs (because they will be heap allocated with cross thread synchronization and GC overhead) and standard lib. Its good enough for some tiny algo, but not good enough for anything serious.

It's good enough for the folks who choose to do it that way. Many of them do things that are quite "serious"... Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java. It's not low effort, you have to be careful, get intimate with the garbage collector, and spend a lot of time profiling. It's a totally reasonable choice to make if your team has that expertise, you're already a java shop, etc. I no longer make the choice to use java for new code. I prefer rust. But neither choice is correct or incorrect.

Re: The 100 hour gap between a vibecoded prototype and a working product

#278

Post by matt_heimer »

andriy_koval wrote: post #240
matt_heimer wrote: post #238

Earlier quoted context omitted.

You program differently for this niche in any language. The hot path (number crunching) thread doesn't share objects with gateway (IO) threads. Passing data between them is off heap, you avoid object creation after warm up. There is no synchronization, even volatile is something you avoid.

> Passing data between them is off heap how exactly you are passing data? You can pass some primitives without allocating them on heap. You can use some tiny subset of Java+standard library to write high performance code, but why would you do this instead of using Rust or C++?

In some places I'm using https://github.com/aeron-io/agrona

Strangely this is one of the areas where I want to use project panama so I might re-implement some of the ring buffers constructs.

You allocate off heap memory and dump data into it. With modern Java classes like Arena, MemoryLayout, and VarHandle it's honestly a lot like C structs.

I answered "why" in another post in this thread.

Re: The 100 hour gap between a vibecoded prototype and a working product

#279

Post by pindab0ter »

shepherdjerred wrote: post #272

My experience is that Claude Code, when used appropriately, can produce work better than most programmers. "when used appropriately" means: - Setting up guardrails: use a statically typed language, linters, CLAUDE.md/skills for best practices. - Told to do research when making technical decisions, e.g. "look online for prior art" or "do research and compare libraries for X" - Told to prioritize quality and maintainab…

Where do you keep the skills it generates from docs? Does this not become a mess?

Re: The 100 hour gap between a vibecoded prototype and a working product

#280

Post by andriy_koval »

jcgrillo wrote: post #277
andriy_koval wrote: post #271

Earlier quoted context omitted.

> But if java is good enough, or can be made good enough by writing the code correctly, "writing code correctly" here means stripping 95% of lang capabilities, and writing in some other language which looks like C without structs (because they will be heap allocated with cross thread synchronization and GC overhead) and standard lib. Its good enough for some tiny algo, but not good enough for anything serious.

It's good enough for the folks who choose to do it that way. Many of them do things that are quite "serious"... Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java. It's not low effort, you have to be careful, get intimate with the garbage collector, and spend a lot of time profiling. It's a totally reasonable choice to make if your tea…

> Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java.

those have low bar of performance, also they mostly became popular because of investments from Java hype, and rust didn't exist or had weak ecosystem at that time.

Post reply on HN