Your job is to deliver code you have proven to work • Hacker News Board

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

#641

Post by necovek » Fri, Dec 19, 2025, 2:27 PM UTC

JohnBooty wrote: post #596

phito wrote: post #101

Earlier quoted context omitted.

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.

Yeah, I've definitely found that nobody reads more than maybe 10 words of the PR description. I've also never seen anybody but myself write substantial PR descriptions at my previous 4-5 jobs

But if nobody writes them, they don't have the habit of reading them either.

However, also make sure your PR descriptions are not "substantial" in the "there is a lot of it" sense, but only "substantial" in the "everything of substance is described, but not more" sense :)

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

#642

Post by necovek » Fri, Dec 19, 2025, 2:31 PM UTC

oceanplexian wrote: post #135

simonw wrote: post #44

Earlier quoted context omitted.

100%. There's no difference at all in my mind between an AI-assisted PR and a regular PR: in both cases they should include proof that the change works and that the author has put the work in to test it.

At the last company I worked at (Large popular tech company) it took an act of the CTO to get engineers to simply attach a JIRA Ticket to the PR they were working on so we could track it for tax purposes. The Devs went in kicking and screaming. As an SRE it seemed like for SDEs, writing a description of the change, explaining the problem the code is solving, testing methodology, etc is harder than actually coding. Ir…

Invite engineers to solve it in a way that makes it cheap for them.

Most shops I've been at prefix their branch names with ticket numbers ("bug-X-" or "TCKT-Y-"), and then it's trivial to reference it back. Some will write scripts on top, which gets them even more motivated to solve your problem (and might add links into the tracking tools too, move the ticket to "In Review" when the PR is up, close it after it's merged...).

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

#643

Post by necovek » Fri, Dec 19, 2025, 2:32 PM UTC

comfydragon wrote: post #550

rootusrootus wrote: post #253

Earlier quoted context omitted.

It could be a death-by-a-thousand-cuts situation and we don't have enough context. My company has spent the last few years really going 1000% on the capitalization of software expenses, and now we have to include a whole slew of unrelated attributes in every last Jira ticket. Then the "engineering team" (there is only one of these, somehow, in a 5K employee company) decrees all sorts of requirements about how we test…

> The branch itself gets created with the ticket number and everything follows from that, there's no extra effort. Only problem there is the potential for a deeply-ingrained assumption that the Jira key being in the branch name is sufficient for the traceability between the Jira issue and commits to always exist. I've had to remind many people I work with that branch names are not forever, but commit messages are . H…

It sounds pretty simple to automate that away too: make it part of the merge hook to include the source branch name into the message.

We are engineers, everything is a problem waiting to be automated :)

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

#644

Post by simonw » Fri, Dec 19, 2025, 2:36 PM UTC

nottorp wrote: post #618

Hmm. I've never been asked to do formal proofs for my code. Where does he work?

This isn't about formal proofs, it's about manual testing and simple automated tests.

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

#645

Post by simonw » Fri, Dec 19, 2025, 2:38 PM UTC

andai wrote: post #615

> Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it. How does this work? When expectations about the program's state vs its observable behavior diverge?

Just one very simple example: you add a new frontend feature where clicking a button opens a modal. You include an automated test that selects the button and clicks it using document.querySelector("#mybutton").click() - and the test passes. Then when you test it in a browser yourself you find that the button is impossible to click because it's invisibly positioned behind some other element.

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

#646

Post by DonHopkins » Fri, Dec 19, 2025, 2:46 PM UTC

jennyholzer2 wrote: post #17

dfxm12 wrote: post #6

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. Is anyone else seeing this in their orgs? I'm not...

[dead]

[flagged]

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

#647

Post by ChrisMarshallNY » Fri, Dec 19, 2025, 2:46 PM UTC

farhanhubble wrote: post #595

ChrisMarshallNY wrote: post #534

Earlier quoted context omitted.

When I come upon an issue, I pretty much immediately copy/paste the code into an LLM, with a description of the context, symptoms, and desired outcome. It will usually home right in on the bug, or will give me a good starting point. It's also really good at letting me know if this behavior is a "commonly encountered" one, with a summary of ways it's addressed. I've probably done that at least a dozen times, today. I…

There's a gut feeling that comes from having gotten your hands dirty enough that tells you if the LLM is being smart or spitting out bullshit.

The main issue I have with LLM-generated solutions, is that LLMs never seem to know about “Occam’s Razor.”

Their solution usually benefits from some simplification.

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

#648

Post by giancarlostoro » Fri, Dec 19, 2025, 3:20 PM UTC

endorphine wrote: post #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.

I have said it before on HN using LLMs should 100% justify devs having enough time to test and document the code, and understand it better. The problem I do see though will be management.

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

#649

Post by 9rx » Fri, Dec 19, 2025, 3:22 PM UTC

pydry wrote: post #476

9rx wrote: post #473

Earlier quoted context omitted.

I wonder how many more times we'll rebrand TDD (BDD, SDD)? Just 23 more times? ADD, CDD, EDD, DDD, etc. Or maybe more?! AADD, ABDD, ACDD, ..., AAADD, AABDD, etc.

BDD is different, it is a way of gathering requirements. As is, SDD it is some sort of AI nonsense.

BDD was trying to recapture what TDD was originally, renamed from TDD in an effort to shed all the confusion that surrounded TDD. Of course, BDD picked up all of its own confusion (e.g. Gherkin/Cucumber and all that ridiculousness). So now it is rebranded as SDD to try and shed all of that confusion, with a sprinkle of "AI" because why not. Of course, SDD already is clouded in its own confusion.

Testing is the least understood aspect of computer science and it turns out that you cannot keep changing the name and expect everyone to suddenly get it. But that won't stop anyone. We patiently await the next rebrand.

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

#650

Post by freedomben » Fri, Dec 19, 2025, 3:24 PM UTC

> Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it.

Seriously, this cannot be emphasized enough. Before LLMS when we were writing tests completely manually, manual testing made sense to me as the second step. However after playing around a lot with coding agents and LLMs, I fully agree this has flipped. Test it manually first! When you generate the tests it is extremely wise to ensure that the tests fail without the new code, and pass with it. You definitely need to review the test though, because it's remarkably easy to have the agent put something in there that makes it not a good test.

Just a couple days ago for example, Claude made a test pass by skipping authentication and leaving a brief comment informing that the authentication made the test flaky. It even threw a quick variable in there that enabled running or disabling flaky tests, and flaky tests were disabled by default! Had I not been doing a good review, I definitely would have missed it because it was cleverly subtle. I've also seen it test the wrong endpoint!