←back to thread

Vibe coding as a coding veteran: from 8-bit assembly to English-as-code

(levelup.gitconnected.com)
181 points thunderbong | 3 comments | 28 Aug 25 15:55 UTC | HN request time: 0.73s | source
Show context
stavros ◴[31 Aug 25 13:49 UTC] No.45083136[source]▶
I've come to view LLMs as a consulting firm where, for each request, I have a 50% chance of getting either an expert or an intern writing my code, and there's no way to tell which.

Sometimes I accept this, and I vibe-code, when I don't care about the result. When I do care about the result, I have to read every line myself. Since reading code is harder than writing it, this takes longer, but LLMs have made me too lazy to write code now, so that's probably the only alternative that works.

I have to say, though, the best thing I've tried is Cursor's autocomplete, which writes 3-4 lines for you. That way, I can easily verify that the code does what I want, while still reaping the benefit of not having to look up all the APIs and function signatures.

replies(7): >>45083197 #>>45083541 #>>45085734 #>>45086548 #>>45087076 #>>45092938 #>>45092950 #
kaptainscarlet ◴[31 Aug 25 14:00 UTC] No.45083197[source]▶
I've also had a similar experience. I have become too lazy since I started vibe-coding. My coding has transitioned from coder to code reviewer/fixer vey quickly. Overall I feel like it's a good thing because the last few years of my life has been a repetition of frontend components and api endpoints, which to me has become too monotonous so I am happy to have AI take over that grunt work while I supervise.
replies(3): >>45083285 #>>45086478 #>>45090684 #
therein ◴[31 Aug 25 19:52 UTC] No.45086478[source]▶
The lazy reluctance you feel is atrophy in the making. LLMs induce that.
replies(1): >>45090591 #
1. kaptainscarlet ◴[01 Sep 25 08:01 UTC] No.45090591[source]▶
That's my biggest worry, atrophy. But I will cross that bridge when I get to it.
replies(1): >>45090708 #
2. latexr ◴[01 Sep 25 08:23 UTC] No.45090708[source]▶
With atrophy, by the time you get to the bridge you’ll realise it’s too deteriorated to cross and will have to spend a lot of time rebuilding and reinforcing it before you can get to the other side.
replies(1): >>45091178 #
3. Cthulhu_ ◴[01 Sep 25 09:48 UTC] No.45091178[source]▶
That's it, every line of code is an implicit requirement, based on explicit requirements; when you have a codebase that needs to be maintained or replaced, as a developer it's your job to determine which of the implicit requirements in code are explicit requirements for what the application does.

I do think that in a few years time, next generation coding LLMs will read current-generation LLM generated code to improve on it. The question is whether they're smart enough to ignore the implicit requirements in the code if they aren't necessary for the explicit ones.

(this comment makes sense in my head)

Most if not all of my professional projects have been replacing existing software. In theory, they're like-for-like, feature-for-feature rewrites. In practice, there's an MVP of must-have features which usually is only a fraction of the features (implicit or explicit) of the application it replaced, with the rewrite being used as an opportunity to re-assess what is actually needed, what is bloat over time, and of course to do a redesign and re-architecture of the application.

That is, rewriting software was an exercise in extracting explicit features from an application.