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

241–250 of 362 posts

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

#241

Post by dvfjsdhgfv »

withinboredom wrote: post #199
riffraff wrote: post #92

Earlier quoted context omitted.

> 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.

We were working on translations for Arabic and in the spec it said to use "Arabic numerals" for numbers. Our PM said that "according to ChatGPT that means we need to use Arabic script numbers, not Arabic numerals". It took a lot of back-and-forths with her to convince her that the numbers she uses every day are "Arabic numerals". Even the author of the spec could barely convince her -- it took a meeting with the Arab…

Man this is maddening.

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

#242

Post by matt_heimer »

FpUser wrote: post #70
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…

I am curious about what causes some to choose Java for HFT. From what I remember the amount of virgin sacrifices and dances with the wolves one must do to approach native speed in this particular area is just way too much of development time overhead.

Probably the same thing that makes most developers choice a language for a project, it's the language they know best.

It wasn't a matter of choosing Java for HFT, it was a matter of selecting a project that was a good fit for Java and my personal knowledge. I was a Java instructor for Sun for over a decade, I authored a chunk of their Java curriculum. I wrote many of the concurrency questions in the certification exams. It's in my wheelhouse :)

My C and assembly is rusty at this point so I believe I can hit my performance goals with Java sooner than if I developed in more bare metal languages.

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

#243

Post by roncesvalles »

daveguy wrote: post #229
chamomeal wrote: post #211

Earlier quoted context omitted.

I have friends (well, friends of friends) who still play the NFT lottery. People love gambling lol

I thought everyone realized by now that a digital image made available via block chain or any other mechanism, can be duplicated indefinitely. The only thing you get is a copyright on some generated image or set of bits. And what are the chances any random digital image is going to be appreciated as art? You can't hang it in a living room or sit it on a coffee table. It's beanie babies, but without even a hill of bea…

You don't have to believe in it. You just have to believe someone else will believe in it and be willing to pay a higher price.

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

#245

Post by the__alchemist »

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…

I concur on the DevSecOps aspect for a more specific reason: If you're failing a pipeline because ThirdPartyTOol69 doesn't like your code style or W/E, you can have the LLM fix it. Or get you to 100% test coverage etc. Or have it update your Cypress/Jest/SonarQube configs until the pipeline passes without losing brain cells doing it by hand. Or finds you a set of dependency versions that passes.

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

#247

Post by czhu12 »

I'd also say for a lot of applications -- most applications perhaps -- outside of "consumer" ones, the number of features is quite a bit more important than the shape of a button or the animations during a page transition.

Even pretty massive companies like databricks don't think about those things and basically have a UI template library that they then compose all their interfaces from. Nothing fancy. Its all about features, and LLM create copious amounts of features.

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

#248

Post by worik »

Aperocky wrote: post #48
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…

The magic is testing. Having locally available testing and high throughput testing with high amount of test cases now unlocks more speed. The test cases themselves becomes the foci - the LLM usually can't get them right.

> The magic is testing.

No it is not.

There os no amount of testing that can fix a flawed design

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

#249

Post by [deleted] »

sieste wrote: post #207
GeoAtreides wrote: post #193

Earlier quoted context omitted.

I'm saying this with all my love and respect: you are living in a very small bubble

That may be true. But you also have to give the average parent more credit by assuming they don't want tech companies spying on their children and forcing their toxic platforms on them. There are well attended parent evenings in our school on that topic. Thinking about it, we should turn these into vibe coding hackathons where we replace all the ad-ridden little games, learning tools, messengers we don't like with he…

[deleted]

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

#250

Post by matt_heimer »

nly wrote: post #111
FpUser wrote: post #70

Earlier quoted context omitted.

I am curious about what causes some to choose Java for HFT. From what I remember the amount of virgin sacrifices and dances with the wolves one must do to approach native speed in this particular area is just way too much of development time overhead.

"HFT" means different things to different people. I've worked at places where ~5us was considered the fast path and tails were acceptable. In my current role it's less than a microsecond packet in, packet out (excluding time to cross the bus to the NIC). But arguably it's not true HFT today unless you're using FPGA or ASIC somewhere in your stack.

Software HFT? I see people call Python code HFT sometimes so I understand what you mean. It's more in-line with low latency trading than today's true HFT.

I don't work for a firm so don't get to play with FPGAs. I'm also not co-located in an exchange and using microwave towers for networking. I might never even have access to kernel networking bypass hardware (still hopeful about this one). Hardware optimization in my case will likely top out at CPU isolation for the hot path thread and a hosting provider in close proximity to the exchanges.

The real goal is a combination of eliminating as much slippage as possible, making some lower timeframe strategies possible and also having best class back testing performance for parameter grid searching and strategy discovery. I expect to sit between industry leading firms and typical retail systematic traders.

Post reply on HN