4 ms·

I see AI-accelerated codegen as doing all of the boring shit I hated: do while error == true; Write code Run code Read error Attempt to fix error Run code

I see AI-accelerated codegen as doing all of the boring shit I hated: do while error == true; Write code Run code Read error Attempt to fix error Run code Read error Search Google for error Attempt to fix error Run code Read error done --- Claude does all of this for me now, allowing me to concentrate on the end goal, not the minutiae. It hasn't at all changed my workflow; it just does all of the horribly mundane parts of it for me. I like it and I recommend it to those who are willing to admit that their jobs aren't all sunshine and roses until the product is shipped and we can sit back and get to work on the next nightmare.

righthand 1y ago
If you enjoy being a custodian no one is going to chastise you for that. As you have stated there are many nightmares to clean up and all teams need a person who wants to do the clean up. This will keep you out of the bleeding edge feature/product space because you lack a honed skill in actually developing the app. Your skill is now to talk to an LLM and fix nightmare code, not work on new stuff that needs expertise. Just food for thought.
- deleted 1y ago
  [deleted]
- kamaal 1y ago
  I think writing code was never slow. Or atleast never the slowest part of the overall process. Vibe coding might be fast, but thats only if you wish to pretend that coders deploy to production directly within minutes of writing code without product discussions, automated builds, CI/CD, code review, production testing, UAT, regression testing, security testing etc. In reality when you factor in all these things, which are absolutely necessary if you don't want you product to break every new release and lose users permanently. You have to do the same drills as you always did. To that end, unless you are building something very large, coding velocity is largely irrelevant.
  - righthand 1y ago
    I would also argue that the OPs comment describes “hacking” not “writing code”. They could escape that loop by employing software development skillsets, for example TDD or perhaps using the debugger instead of pounding away at a compiler. Usually when people pound at a compiler it’s because they don’t know what they’re doing or how software even works.

righthand 1y ago

If you enjoy being a custodian no one is going to chastise you for that. As you have stated there are many nightmares to clean up and all teams need a person who wants to do the clean up. This will keep you out of the bleeding edge feature/product space because you lack a honed skill in actually developing the app. Your skill is now to talk to an LLM and fix nightmare code, not work on new stuff that needs expertise. Just food for thought.

deleted 1y ago
[deleted]
kamaal 1y ago
I think writing code was never slow. Or atleast never the slowest part of the overall process. Vibe coding might be fast, but thats only if you wish to pretend that coders deploy to production directly within minutes of writing code without product discussions, automated builds, CI/CD, code review, production testing, UAT, regression testing, security testing etc. In reality when you factor in all these things, which are absolutely necessary if you don't want you product to break every new release and lose users permanently. You have to do the same drills as you always did. To that end, unless you are building something very large, coding velocity is largely irrelevant.
- righthand 1y ago
  I would also argue that the OPs comment describes “hacking” not “writing code”. They could escape that loop by employing software development skillsets, for example TDD or perhaps using the debugger instead of pounding away at a compiler. Usually when people pound at a compiler it’s because they don’t know what they’re doing or how software even works.