←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.398s | 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. groby_b ◴[09 Dec 25 14:36 UTC] No.46205328[source]▶
You can go faster once you understand the domain reasonably well that you could have written it yourself. This allows you to write better designs, and steer LLMs in the right direction.

"Vibe coding" though is moving an ever growing pile of nonunderstanding and complexity in front of you, until you get stuck. (But it does work until you've amassed a big enough pile, so it's good for smaller tasks - and then suddenly extremely frustrating once you reach that threshold)

Can you go 10x? Depends. I haven't tried any really large project yet, but I can compress fairly large things that would've taken a week or two pre-LLM into a single lazy Sunday.

For larger projects, it's definitely useful for some tasks. ("Ingest the last 10k commits, tell me which ones are most likely to have broken this particular feature") - the trick is finding tasks where the win from the right answer is large, and the loss from the wrong one is small. It's more like running algorithmic trading on a decent edge than it is like coding :)

It definitely struggles to do successfully do fully agentic work on very large code bases. But... I've also not tried too much in that space yet, so take that with a grain of salt.

replies(1): >>46207612 #
2. rbalicki ◴[09 Dec 25 17:19 UTC] No.46207612[source]▶
A git bisect where you can't easily check whether the feature is broken (because the testing step isn't easily described as code) would be killer