Not the parent, but it reads a lot like written by AI. It has that typical breathless style that's exhausting just from reading.
Also, looking at the code, the whole project looks vibe coded, no human would write such comments. Everything in a single git commit also looks "suspicious". It's cool that LLMs can write Z80 asm now, but yeah "labour of love"... tsk tsk tsk...
When your manager gives you the task of building a complex product with a more or less vague "do what I mean" specification, and once a week shows up for 2 minutes to nudge you into a different direction, would you agree when the manager calls this his own "labour of love" when you did 99% of the actual work and thousands of micro-decisions along the way that your manager didn't even know had to be made?
So educate me then what I'm missing in the 'agentic loop' workflow, oh wise one ;)
I'm using this sort of spec-driven + feedback-loop workflow at work to pretty to good effect, and would say I'm quite familiar with the pros and cons.
IMHO the main downside is that you're simply not as familiar with the code base as before, unless you spend just as much time studying the LLM output as writing the code manually in the first place.
E.g. you have about the same distance to the actual implementation as a manager of a traditional programming team who from time to time skims over the source code to check for signals that things start to go sideways, and otherwise mainly feeds feature specification tickets into the team which are coming from a separate 'design department'.
I also would never call any of this work a 'labour of love' either. Not that this sort of soulless "specification-in-implementation-out" was much different before though, it's just how industrial software development works - essentially an assembly line for features.
> I also would never call any of this work a 'labour of love' either.
That’s a you problem. This could very well be a labour of love and nothing about any of this precludes it from being a labour of love.
> E.g. you have about the same distance to the actual implementation as a manager of a traditional programming team who from time to time skims over the source code to check for signals that things start to go sideways, and otherwise mainly feeds feature specification tickets into the team which are coming from a separate 'design department'
I guess you’re rather young or not really acquainted with the history of computer science, because that’s the exact same argument people used to make about compilers… and then GUIs…and then high-level programming languages… and then OOP… the list goes on and on and on.
Every time a new tool arrives that disrupts the way something is traditionally done, those that feel insecure about their work tend to lash out with the same “no true Scotsman” arguments.
I’m not saying AI is perfect or that it replaces programmers in any way. What I’m saying is that it’s just a different way of going about the business of programming. It’s just yet another level of abstraction.
> I guess you’re rather young or not really acquainted with the history of computer science.
Lol, thanks for the compliment. I've been programming computers since around 1984. But I learned to recognize snake oil when I see it (since around the mid-90s when the OOP hype was in full swing and I was a true believer for a while, the OOP hype did indeed have a lot in common with the current AI hype - e.g. about 10% useful, 90% snake oil, but it took the industry nearly two decades to recognize how harmful the OOP hype actually was even to the original idea of OOP itself... different topic though).
Also I think you're retconning/simplifying computing history a bit, it's not a linear evolution from low-level to high-level (e.g. when C was created, there were already much higher level programming languages common), and understanding the compiler output on CPU instruction level and the hardware it runs on is still very necessary for proper optimization work, even when working in a high level language.
E.g. you can't simply ignore the lowest level foundations even after adding new abstraction levels on top.
PS: what's up with all those throwaway accounts in the thread anyway?
j4cobgarby · · focus · HN ↗
ghusto · · focus · HN ↗
flohofwoe · · focus · HN ↗
Also, looking at the code, the whole project looks vibe coded, no human would write such comments. Everything in a single git commit also looks "suspicious". It's cool that LLMs can write Z80 asm now, but yeah "labour of love"... tsk tsk tsk...
kejdjejxjejdj · · focus · HN ↗
What precludes this from being a labour of love, exactly?
flohofwoe · · focus · HN ↗
kejdjejxjejdj · · focus · HN ↗
flohofwoe · · focus · HN ↗
I'm using this sort of spec-driven + feedback-loop workflow at work to pretty to good effect, and would say I'm quite familiar with the pros and cons.
IMHO the main downside is that you're simply not as familiar with the code base as before, unless you spend just as much time studying the LLM output as writing the code manually in the first place.
E.g. you have about the same distance to the actual implementation as a manager of a traditional programming team who from time to time skims over the source code to check for signals that things start to go sideways, and otherwise mainly feeds feature specification tickets into the team which are coming from a separate 'design department'.
I also would never call any of this work a 'labour of love' either. Not that this sort of soulless "specification-in-implementation-out" was much different before though, it's just how industrial software development works - essentially an assembly line for features.
isieidjeidj · · focus · HN ↗
> I also would never call any of this work a 'labour of love' either.
That’s a you problem. This could very well be a labour of love and nothing about any of this precludes it from being a labour of love.
> E.g. you have about the same distance to the actual implementation as a manager of a traditional programming team who from time to time skims over the source code to check for signals that things start to go sideways, and otherwise mainly feeds feature specification tickets into the team which are coming from a separate 'design department'
I guess you’re rather young or not really acquainted with the history of computer science, because that’s the exact same argument people used to make about compilers… and then GUIs…and then high-level programming languages… and then OOP… the list goes on and on and on.
Every time a new tool arrives that disrupts the way something is traditionally done, those that feel insecure about their work tend to lash out with the same “no true Scotsman” arguments.
I’m not saying AI is perfect or that it replaces programmers in any way. What I’m saying is that it’s just a different way of going about the business of programming. It’s just yet another level of abstraction.
flohofwoe · · focus · HN ↗
Lol, thanks for the compliment. I've been programming computers since around 1984. But I learned to recognize snake oil when I see it (since around the mid-90s when the OOP hype was in full swing and I was a true believer for a while, the OOP hype did indeed have a lot in common with the current AI hype - e.g. about 10% useful, 90% snake oil, but it took the industry nearly two decades to recognize how harmful the OOP hype actually was even to the original idea of OOP itself... different topic though).
Also I think you're retconning/simplifying computing history a bit, it's not a linear evolution from low-level to high-level (e.g. when C was created, there were already much higher level programming languages common), and understanding the compiler output on CPU instruction level and the hardware it runs on is still very necessary for proper optimization work, even when working in a high level language.
E.g. you can't simply ignore the lowest level foundations even after adding new abstraction levels on top.
PS: what's up with all those throwaway accounts in the thread anyway?