Hacker News Reader

Comment by rvz | Hacker News Reader

> I'm a programmer, and I use automatic programming. The code I generate in this way is mine. My code, my output, my production. I, and you, can be proud.

Disagree.

So when there is a bug / outage / error, due to "automatic programming" are you ready to be first in line to accept accountability (the LLM cannot be) when it all goes wrong in production? I do not think that would even be enough or whether this would work in the long term.

No excuses like "I prompted it wrong" or "Claude missed something" or "I didn't check over because 8 other AI agents said it was "absolutely right"™".

We will then have lots of issues such as this case study [0] where everything seemingly looks fine at first, all tests pass but in production, the logic was misinterpreted by the LLM with a wrong keyword, [0] during a refactor.

[0] https://sketch.dev/blog/our-first-outage-from-llm-written-co...

View on HN

> So when there is a bug / outage / error, due to "automatic programming" you are first in line and ready to accept accountability when it all goes wrong in production?

Absolutely yes. Automatic programming does not mean software developers are no longer accountable for their errors. Also because you can use AP in order to do ways more QA efforts than possible in the past. If you decide to just add things without a rigorous process, it is your fault.

Agree. Much of the value of devs is understanding the thing they're working on so they know what to do when it breaks, and knows what new features it can easily support. Doesn't matter whether they wrote the code, a colleague wrote it, or an AI.

Yep writing the code might have gotten a little bit easier but was never was the hard part to begin with.

>> are you ready to be first in line to accept accountability

I'm accountable for the code i push to production. I have all the power and agency in this scenario, so i am the right person to be accountable for what's in my PR / CL.

That is the policy I set up for our team as well—when you push, you declare your absolute responsibility for any changes you made to the repository, regardless of the way they were conceived.

That is really about the least confusing part of the story.

Owning the issue is one thing, but being able to fix issues with a reasonable amount of resources is another.

To me code created like this smells like technical debt. When bugs appear after 6 months in production - as they do, if you didn't fully understand the code when developing it, how much time, energy and money will it cost to fix the problem later on?

More often than I like I had to deal with code where it felt like the developer did'nt actually understand what they were writing. Sometimes I was this developer and it always creates issues.

I hope you aren't missing the point. My position is similar to the author. I WILL take responsibility for the code I push to production, and rather than input a prompt and roll the dice on the outcome, I am strategic in my prompts, ensuring the LLM has the right context each time I I voke it, some of that context being accurate descriptions of what I want built, and I am in charge of ensuring it has been properly vetted. Many times I will erase what the LLM has written and redo it, by myself depending on the situation.

Replace "LLM" with "IDE" and re-read. The LLM is another tool. Of course tools can't be held responsible, the person wielding the tool is.

> Many times I will erase what the LLM has written and redo it, by myself depending on the situation.

The contention here is that antirez doesn't think this is necessary anymore. 100% code gen, with the occassional "stepping in and tell the AI how to write a certain function"

Your position is more balanced and quite similar to https://mitchellh.com/writing/non-trivial-vibing

Reply on news.ycombinator.com