Born Against, or why hobby programming communities are against LLM usage
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Born Against, or why hobby programming communities are against LLM usage
Unofficial Hacker News client; not affiliated with Y Combinator.
alkonaut · · focus · HN ↗
1) You figure out what problem to solve.
2) You figure out HOW to solve the problem.
3) You actually implement the solution.
4) You see the solution work, for yourself.
5) You ship/deploy/publish the program. This means you see people be happy users and/or you get paid for it and so on.
If you're an entrepreneur type, you probably enjoy the first and last steps most, and you see steps 2-4 as mostly a chore. If you're a tinkerer, you don't care much for 1 and 5, and you see 2-4 as the whole point of programming. I'm a tinkerer. I'd be happy to just write code and throw it away. Coding is like solving sudokus. I could skip steps 1 and 5 forever. I don't ever need to show any code to anyone. In fact, most of the time when programming I do steps 2 and 3 and even skip 4. I don't even finish! I work weeks on something until I lose interest, and I know that in order to even run it, it would be several more weeks. A PoC is enough. Or just a half one. It's just code-to-structure-thoughts, not to create anything finished.
The 5 phases look kind of symmetric. The outermost layer (1 and 5) are the entrepreneurial steps. If you're a product owner or CEO, you might work strictly at steps 1,5. Then steps 2-4 are the managerial/architectural steps. If you're a very senior IC at a large company, you might work at this level, without actually doing much coding. Only the inner most step (3) is the manual creation of source code. Even though it's 5 different phases, it's just "3 layers" of programming.
The problem as I see it is that I enjoy step 3. And LLMs are good at step 3 almost exclusively. So they just pick the best bit of this dish, and leave me with the rest.
If you're an entrepreneurial type, the LLM appears to take the _worst_ bit of the work from you. Great.
Nextgrid · · focus · HN ↗
Having done step 2 & 3 by hand is the difference between being able to fix/extend it quickly with no further damage or fumbling around like an idiot and sometimes breaking more stuff in the process.
stackghost · · focus · HN ↗
Plenty of shitty spaghetti code has been written by human hands.
LLMs can write good, maintainable code too, but they need to be kept on a shorter leash with focused goals.
Nextgrid · · focus · HN ↗
(with human-written code I can reach out to the person who wrote it and let them deal with it, and they will have the understanding of said code, even if it is bad by quality measures. With LLMs there is nobody who understands said code, regardless of its quality)
Bewelge · · focus · HN ↗
"That code is horrible! Who the hell wrote this?!"
git blames
sees their own name
Isn't that an experience everybody makes? For me it was like a year into working professionally. And I feel it's part of being a professional to know that you're not going to remember it in the long term and therefore provide proper documentation of why you did what.
Nextgrid · · focus · HN ↗
Code might be bad by some objective/subjective measure, but if you (or the author) can understand, navigate and work on it, that's often better than good quality code that nobody understands because it was written by an agent, especially under the time pressure of an ongoing incident where you need to fix it now.
Even if the good code is easy to understand, you still need to read it and take it in, something you don't need to do because you got it implicitly by writing said code.
> to know that you're not going to remember it in the long term
From my personal experience, while I will not remember code character by character, a quick look is all it takes to refresh my memory and get the general gist of it and what the context was at the time, something I don't have if I'm reading someone else's (or an agent's) code.