←back to thread

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

(levelup.gitconnected.com)
181 points thunderbong | 1 comments | 28 Aug 25 15:55 UTC | HN request time: 0s | 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 #
stavros ◴[31 Aug 25 14:13 UTC] No.45083285[source]▶
Yeah, exactly the same for me. It's tiring writing the same CRUD endpoints a thousand times, but that's how useful products are made.
replies(1): >>45087409 #
foolserrandboy ◴[31 Aug 25 21:48 UTC] No.45087409[source]▶
I wonder why it’s not the norm to use code generation or some other form of meta programming to handle this boring repetitive work?
replies(3): >>45087465 #>>45088747 #>>45091151 #
stavros ◴[31 Aug 25 21:56 UTC] No.45087465{3}[source]▶
Because, like a carpenter doesn't always make the same table, but can be tired of always making tables, I don't always write the exact same CRUD endpoints, but am tired of always writing CRUD endpoints.
replies(1): >>45090130 #
1. js8 ◴[01 Sep 25 06:45 UTC] No.45090130{4}[source]▶
I think your analogy shows why LLMs are useful, despite being kinda bad. We need some programming tool to which we can say, "like this CRUD endpoint, but different in this and that". Our other metaprogramming tools cannot do that, but LLMs kinda can.

I think now we have identified this problem (programmers need more abstract metaprogramming tools) and a sort of practical engineering solution (train LLM on code), it's time for researchers (in the nascent field of metaprogramming, aka applied logic) to recognize this and create some useful theories, that will help to guide this.

In my opinion, it should lead to adoption of richer (more modal and more fuzzy) logics in metaprogramming (aside from just typed lambda calculus on which our current programming languages are based). That way, we will be able to express and handle uncertainty (e.g. have a model of what constitutes a CRUD endpoint in an application) in a controlled and consistent way.

This is similar how programming is evolving from imperative with crude types into something more declarative with richer types. (Roughly, types are the specification and the code is the solution.) With a good set of fuzzy type primitives, it would be possible to define a type of "CRUD endpoint", and then answer the question if the given program has that type.