←back to thread

Has the cost of building software dropped 90%?

(martinalderson.com)
413 points martinald | 2 comments | 08 Dec 25 19:00 UTC | HN request time: 0.757s | source
Show context
tangotaylor ◴[09 Dec 25 12:42 UTC] No.46204312[source]▶
> Engineers need to really lean in to the change in my opinion.

I tried leaning in. I really tried. I'm not a web developer or game developer (more robotics, embedded systems). I tried vibe coding web apps and games. They were pretty boring. I got frustrated that I couldn't change little things. I remember getting frustrated that my game character kept getting stuck on imaginary walls and kept asking Cursor to fix it and it just made more and more of a mess. I remember making a simple front-end + backend with a database app to analyze thousands of pull request comments and it got massively slow and I didn't know why. Cursor wasn't very helpful in fixing it. I felt dumber after the whole process.

The next time I made a web app I just taught myself Flask and some basic JS and I found myself moving way more quickly. Not in the initial development, but later on when I had to tweak things.

The AI helped me a ton with looking things up: documentation, error messages, etc. It's essentially a supercharged Google search and Stack Overflow replacement, but I did not find it useful letting it take the wheel.

replies(9): >>46204550 #>>46205027 #>>46206045 #>>46206421 #>>46206931 #>>46210894 #>>46211263 #>>46211291 #>>46216142 #
r_lee ◴[09 Dec 25 13:08 UTC] No.46204550[source]▶
These posts like the one OP made is why I'm losing my mind.

Like, is there truly an agentic way to go 10x or is there some catch? At this point while I'm not thrilled about the idea of just "vibe coding" all the time, I'm fine with facing reality.

But I keep having the same experience as you, or rather leaning more on that supercharged Google/SO replacement

or just a "can you quickly make this boring func here that does xyz" "also add this" or for bash scripts etc.

And that's only when I've done most of the plumbing myself.

replies(19): >>46204630 #>>46204766 #>>46204828 #>>46204843 #>>46204925 #>>46205328 #>>46205478 #>>46205659 #>>46205781 #>>46205890 #>>46205913 #>>46205924 #>>46205931 #>>46206330 #>>46207518 #>>46209875 #>>46214153 #>>46214479 #>>46214591 #
1. csomar ◴[09 Dec 25 15:26 UTC] No.46205931[source]▶
I have been building a game (preview here: https://qpingpong.codeinput.com) as a practice to "vibe-coding". There is only one rule: I am not allowed to write a single line of code. But can prompt as much as I want.

So far I am hitting a "hard-block" on getting the AI to make changes once you have a large code base. One "unblocker" was to restructure all the elements as their own components. This makes it easier for the LLM (and you?) to reason about each component (React) in isolation.

Still, even as this "small/simple game" stage, it is not only hard for the LLM to get any change done but very easy for it to break things. The only way I can see my around it, is to structure very through tests (including E2E tests) so that any change by the LLM has to be thoroughly tested for regression.

I've been working on this for a month or so. I could have coded it faster by hand except for the design part.

replies(1): >>46211894 #
2. allochthon ◴[09 Dec 25 22:58 UTC] No.46211894[source]▶
I have a hobby project on the side involving radio digital signal processing in Rust that I've been pure vibe coding, just out of curiosity to see how far I can get. On more than one occasion the hobby project has gotten bogged down in a bug that is immensely challenging to resolve. And since the project isn't in an area I have experience with, and since I don't have a solid "theory of the program", since it's a gray box because I've been vibe coding it, I've definitely seen CC get stuck and introduce regressions in tricky issues we previously worked through.

The use of Claude Code with my day job has been quite different. In my day job, I understand the code and review it carefully, and CC has been a big help.