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

231–240 of 362 posts

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

#231

Post by GorbachevyChase »

kjksf wrote: post #105
kami23 wrote: post #47

Earlier quoted context omitted.

And some people do, both things can be true. I'd rather make a tool just for me that breaks when I introduce a new requirement and I just add into it and keep going.

The statement wasn't: "no one ever vibe codes an alternative to product X" It was: "With sufficiently advanced vibe coding the need for certain type of product just vanishes." If a product has 100 thousand users and 1% of them vibe codes an alternative for themselves, the product / business doesn't vanish. They still have 99 thousand of users. That was the rebuttal, even if not presented as persuasively and intellige…

At some point there will be market consequences for that kind of behavior. So where market dynamics are not dominated by bullshit (politics, friendships forged on Little St James, state intervention, cartel behavior, etc.) if my company provides the same service as another, but I replaced all of the low quality software as a service products my competitor uses with low quality vibe coded products, my overhead cost will be lower and that will give me an advantage.

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

#232

Post by andriy_koval »

not_kurt_godel wrote: post #219
grim_io wrote: post #73

Earlier quoted context omitted.

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

I personally know of an HFT firm that used Java approximately a decade ago. My guess would be they're still using it today given Java performance has only improved since then.

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

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

#233

Post by andriy_koval »

jodleif wrote: post #104
grim_io wrote: post #73

Earlier quoted context omitted.

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

As long as you tune the JVM right it can be faster. But its a big if with the tune, and you need to write performant code

Java has significant overhead, that most/every object is allocated on heap, synchronized and has extra overhead of memory and performance to be GC controlled. Its very hard/not possible to tune this part.

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

#234

Post by andriy_koval »

tyingq wrote: post #88
grim_io wrote: post #73

Earlier quoted context omitted.

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

Depends. Many reasons, but one is that Java has a much richer set of 3rd party libraries to do things versus rolling your own. And often (not always) third party libraries that have been extensively optimized, real world proven, etc. Then things like the jit, by default, doing run time profiling and adaptation.

Java has huge ecosystem in enterprise dev, but very unlikely it has ecosystem edge in high performance/real time compute.

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

#235

Post by roncesvalles »

riffraff wrote: post #92
mtrovo wrote: post #56

Earlier quoted context omitted.

I think the main issue is treating LLM as a unrestrained black box, there's a reason nobody outside tech trust so blindly on LLMs. The only way to make LLMs useful for now is to restrain their hallucinations as much as possible with evals, and these evals need to be very clear about what are the goal you're optimizing for. See karpathy's work on the autoresearch agent and how it carry experiments, it might be useful…

> there's a reason nobody outside tech trust so blindly on LLMs. Man, I wish this was true. I know a bunch of non tech people who just trusts random shit that chatgpt made up. I had an architect tell me "ask chatgpt" when I asked her the difference between two industrial standard measures :) We had politicians share LLM crap, researchers doing papers with hallucinated citations.. It's not just tech people.

And the worst part is, these people don't even use the flagship thinking models, they use the default fast ones.

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

#236

Post by matt_heimer »

grim_io wrote: post #73
matt_heimer wrote: post #45

Earlier quoted context omitted.

I'm building a Java HFT engine and the amount of things AI gets wrong is eye opening. If I didn't benchmark everything I'd end up with much less optimized solution. Examples: AI really wants to use Project Panama (FFM) and while that can be significantly faster than traditional OO approaches it is almost never the best. And I'm not taking about using deprecated Unsafe calls, I'm talking about using primative arrays b…

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

You can achieve optimized C/C++ speeds, you just can't program the same way you always have. Step 1, switch your data layout from Array of Structures to Structure of Arrays. Step 2, after initial startup switch to (near) zero object creation. It's a very different way to program Java.

You have to optimize your memory usage patterns to fit in CPU cache as much as possible which is something typical Java develops don't consider. I have a background in assembly and C.

I'd say it's slightly harder since there is a little bit of abstraction but most of the time the JIT will produce code as good as C compilers. It's also an niche that often considers any application running on a general purpose CPU to be slow. If you want industry leading speed you start building custom FPGAs.

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

#237

Post by roncesvalles »

grim_io wrote: post #73
matt_heimer wrote: post #45

Earlier quoted context omitted.

I'm building a Java HFT engine and the amount of things AI gets wrong is eye opening. If I didn't benchmark everything I'd end up with much less optimized solution. Examples: AI really wants to use Project Panama (FFM) and while that can be significantly faster than traditional OO approaches it is almost never the best. And I'm not taking about using deprecated Unsafe calls, I'm talking about using primative arrays b…

Wouldn't Java always lose in terms of latency against a similarly optimized native code in, let's say, C(++)?

There are actually cases when Java (the HotSpot JVM) runs faster than the same logic written in C/C++ because the JVM is doing dynamic analysis and selective JIT compilation to machine code.

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

#238

Post by matt_heimer »

andriy_koval wrote: post #233
jodleif wrote: post #104

Earlier quoted context omitted.

As long as you tune the JVM right it can be faster. But its a big if with the tune, and you need to write performant code

Java has significant overhead, that most/every object is allocated on heap, synchronized and has extra overhead of memory and performance to be GC controlled. Its very hard/not possible to tune this part.

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.

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

#239

Post by roncesvalles »

Aurornis wrote: post #98
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…

There’s a big gap between reality and the influencer posts about LLMs. I agree with you that LLMs do provide some significant acceleration, but the influencers have tried to exaggerate this into unbelievable numbers. Even non-influencers are trying to exaggerate their LLM skills as a way to get hired or raise their status on LinkedIn. I rarely read the LinkedIn social feed but when I check mine it’s now filled with c…

>Many of these posts come from people who were all in on crypto companies a few years ago.

This is ditto my observation. There seems to be a certain "type" of people like this. And it's not just people looking for work.

My guess is either they have super low critical thinking, a very cynical view of the world where lies and exaggeration are the only way to make it, or something more pathological (narcissism etc).

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

#240

Post by andriy_koval »

matt_heimer wrote: post #238
andriy_koval wrote: post #233

Earlier quoted context omitted.

Java has significant overhead, that most/every object is allocated on heap, synchronized and has extra overhead of memory and performance to be GC controlled. Its very hard/not possible to tune this part.

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++?

Post reply on HN