Live data from Hacker News

Your job is to deliver code you have proven to work

simonwillison.net

101–110 of 699 posts

Re: Your job is to deliver code you have proven to work

#101

For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those wh…

I often write PR descriptions, in which I write a short explanation and try to anticipate some comments I might get. Well, every time I do, I will still get those exact comments because nobody bothers reading the description.

Not to say you shouldn't write descriptions, I will keep doing it because it's my job. But a lot of people just don't care enough or are too distracted to read them.

Re: Your job is to deliver code you have proven to work

#102
post #27
post #12

Earlier quoted context omitted.

Yeah that's fair, the manual testing doesn't have to sequentially go first - but it does have to get done. I've lost count of the number of times I've skipped it because the automated test passed and then found there was some dumb but obvious bug that I missed, instantly exposed when I actually exercised the feature myself.

Would automated tests that produce a transcript of what they've done allow perusing that transcript to substitute for manual testing?

The value of manual tests is when you "see something" that you didn't even think of.

Re: Your job is to deliver code you have proven to work

#103
post #101

For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those wh…

I often write PR descriptions, in which I write a short explanation and try to anticipate some comments I might get. Well, every time I do, I will still get those exact comments because nobody bothers reading the description. Not to say you shouldn't write descriptions, I will keep doing it because it's my job. But a lot of people just don't care enough or are too distracted to read them.

I just point people to the description. no need to type things twice.

Re: Your job is to deliver code you have proven to work

#104
> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest.

It's even worse than that: non-junior devs are doing it as well.

Re: Your job is to deliver code you have proven to work

#105
post #64

Earlier quoted context omitted.

LLMs are tools that make mediocre devs 100x more "productive" and good devs 2x more productive

From my vantage I would argue LLMs make good devs around 0.65x more productive

I think on average a dev can be x percent more productive, but there is a best case and worst case scenario. Sometimes it's a shortcut to crank out a solution quickly, other times the LLM can spin you in circles and you lose the whole day in a loop where the LLM is fixing its own mistakes, and it would've been easier to just spend some time working it out yourself.

Re: Your job is to deliver code you have proven to work

#106

> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non -junior devs are doing it as well.

it's even worse than that! non-devs are doing it as well

Re: Your job is to deliver code you have proven to work

#107

> As software engineers we… That’s the thing. People exposing such rude behavior usually are not, or haven’t been in a looong time… As for the local testing part not being performed, this is a slippery slope I’m fighting everyday: more and more cloud based services and platforms are used to deploy software to run with specific shenanigans and running it locally requires some kind of deep craft and understanding. Vend…

Whenever I have to work with such systems, is usually when I do have to write an interface and have a mock implementation. Iteration is much faster when I don’t have to worry about getting the correct state from something I don’t have control over.

Re: Your job is to deliver code you have proven to work

#108

Having the coding agent make screenshots is a big power up. I’m experimenting with how to get these into a PR, and the “gh” CLI tool is helpful. Does anyone have a recipe to get a coding agent to record video of webflows?

Not yet. I'm confident Playwright will be involved in the answer, it has good video recoding features.

Re: Your job is to deliver code you have proven to work

#109
post #41

I agree with the author overall. Manual testing is what I call "vibe testing" and I think by itself is insufficient, no matter if you or the agent wrote the code. If you build your tests well, using the coding agent becomes smooth and efficient, and the agent is safe to do longer stretches of work. If you don't do testing, the whole thing is just a bomb ticking in your face. My approach to coding agents is to prepare…

> Yesterday there was a story "I ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in hours".

Yes, from the same author, in fact.

Re: Your job is to deliver code you have proven to work

#110
post #97
post #41

I agree with the author overall. Manual testing is what I call "vibe testing" and I think by itself is insufficient, no matter if you or the agent wrote the code. If you build your tests well, using the coding agent becomes smooth and efficient, and the agent is safe to do longer stretches of work. If you don't do testing, the whole thing is just a bomb ticking in your face. My approach to coding agents is to prepare…

There are always unknown unknowns which a rigorous testing implementation would just hide under the rug (until they become visible on live, that is). > They had 9000+ tests. They were most probably also written by AI, there's no other (human) way. The way I see it we're putting turtles upon turtles hoping that everything will stick together, somehow.

> They were most probably also written by AI, there's no other (human) way.

Yes. They came from the existing project being ported, which was also AI-written.

Post reply on HN