Live data from Hacker News

Your job is to deliver code you have proven to work

simonwillison.net

671–680 of 699 posts

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

#671

> 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.

Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…

There is also another way to view this:

People who have a sloppy/lazy way of working are exposed more quickly by this.

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

#672

Earlier quoted context omitted.

> so if it doesn't work then I have to figure out why. But it's built on top of things that are understood. If it doesn't work, then either: • You didn't understand the problem fully, so the approach you were using is wrong. • You didn't understand the language (library, etc) correctly, so the computer didn't grasp your meaning. • The code you wrote isn't the code you intended to write. This is a much more tractable…

> "nobody knows what the code means, or has a mental model for how it's supposed to operate" > Believing you know how LLM-generated code works, and why it works, is not the same as that actually being the case This is a strawman argument which I'm not really interested to engage. You can assume competence. (In a scenario where one doesn't make these mistakes, what's left in your argument? It is a sufficiently strong…

I am assuming competence. Competent people make these mistakes.

If "assume competence" means "assume that people do not make the mistakes they are observed to make", then why write tests? Wherefore bounds checking? Pilots are competent, so pre-flight checklists are a waste of time. Your doctor's competent: why seek a second opinion? Being mindful involves compensating for these things.

It's possible that you're just that good – that you can implement a solution "as simple as not making these mistakes" –, in which case, I'd appreciate if you could write up your method and share it with us mere mortals. But could it also be possible that you are making these mistakes, and simply haven't noticed yet? How would you know if your understanding of the program didn't match the actual program, if you've only tested the region in which the behaviours of both coincide?

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

#673

Earlier quoted context omitted.

> If the code has no author ... there's nowhere to go if you realise "oops, I didn't understand that as well as I had thought!" That's also true if I author the code myself; I can't go to anyone for help with it, so if it doesn't work then I have to figure out why. > Believing you know how it works and why it works is not the same as that actually being the case. My series of accidental successes producing working co…

> so if it doesn't work then I have to figure out why. But it's built on top of things that are understood. If it doesn't work, then either: • You didn't understand the problem fully, so the approach you were using is wrong. • You didn't understand the language (library, etc) correctly, so the computer didn't grasp your meaning. • The code you wrote isn't the code you intended to write. This is a much more tractable…

Just like there are some easy "tells" with LLM generated English, vibecode has a certain smell to it. Parallel variables that do the same thing is probably the most common one I've seen in the hundreds of thousands of lines of vibecode I've generated and then reviewed (and fixed) by now. That's the philosophical Chinese room thought experiment though. It's a computer. Some sand that we melted into a special shape. Can it "understand"? Leave that for philosophers to decide. There's code, that was generated via LLM and not yacc, fine. Code is code though. If you sit down and read all of the code to understand what each variable, function, and class does, it doesn't matter where the code came from, that is what we call understanding what the code does. Sure, most people are too lazy to actually do that, and again, vibecode has a certain smell to it, but to claim that some because some artificial intelligence generated the code makes it incomprehensible to humans seems unsupported. It's fair to point out that there may not be humans that have bothered to, but that's a different claim. If we simplify the question, if ChatGPT generates the code to generate the Fibonacci sequence, can we, as humans, understand that code? Can we understand it if a human writes that same seven lines of code? As we scale up to more complex code though, at what point does it become incomprehensible to human grade intelligence? If it's all vibecode that isn't being reviewed and is just being thrown into a repo, then sure, no human does understand it. But it's just code. With enough bashing your head against it, even if there are three singleton factory classes doing almost the exact same thing in parallel and they only share state on Wednesdays over an RPC mechanism that shouldn't even work in the first place, but somehow it does, code is still code. There's not arcane hidden whitespace that whispers to the compiler to behave differently because AI generated it. It may be weird and different, but have you tried Erlang? You huff enough of the right kind of glue and you can get anything to make sense. If we go back to the Chinese room thought experiment though. If I, as a human, am able to work on tickets to cause intentional changes to the behavior of the vibecoded program/system that results in desired behavior/changes, at what point does it become actual understand vs merely thinking I understand the code.

Say you start at BigCo and are given access to their million line repo(s) with no docs and are given a ticket to work on. Ugh. You just barely started. But after you've been there for five years, it's obvious to you what the Pequad service does, and you might even know who gave it that name. If the claim is LLMs generate code that's simply incomprehensible by humans, the two counterexamples I have for you are TheDailyWtf.com, and Haskell.

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

#674
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...

Yep. Remember, people not posting on this website are just grinding away at jobs where their individual output does not matter, and entire motivation is work JUST hard enough not to get fired. They don't get stock grants, extremely favorable stock options or anything else, they get salary and MAYBE a small bonus based off business factors they have little control over. My eyes were wide open when 2 jobs ago, they sai…

There are people posting on this website that are in that category; or in those companies. For example most people working outside America as a SWE who like the profession. The options to work for a place that gives stock options, and equity in general is small -> and generally in many countries is heavily penalised tax wise.

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

#675

Earlier quoted context omitted.

Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…

Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!

No you don't. Feed the essay to Claude and ask it to summarize it for you, or just use the Jira MCP and have Claude or codex take the ticket, use the GitHub MCP to get it the source, have it go work on the ticket, have it generate the code, generate some unit tests, then you go literally yell at your computer using Wispr Flow or some other transcription software to tell Claude how to fix the mess it made, and then you after you've cleaned it up, you submit the PR.

When ChatGPT first came out three years ago, we joked about Devin and having an AI coworker, but I was just given 5 tickets to work on before break, and damned if AI didn't take a well scoped ticket and just did it before I even finished reading that very tightly scoped ticket.

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

#676
post #542

Earlier quoted context omitted.

It's not that much of a twist, given that it was basically the plot of THGTTG.

THGTTG was actually just an early version of the prompt. "What do you get if you multiply six by nine?"

42

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

#677

Earlier quoted context omitted.

You close the ticket and ping the manager of the nontechnical person submitting the ticket. Then you have a discussion with management about the arrangement and expectations. If it doesn't go well you polish your resume.

That sounds like good advice for someone 1) in a less hierarchical organization, and 2) during a period when jobs are easy to get.

Or someone who

1) has the savings such that they aren't a wage slave (applies to any income level)

2) has any dignity

People willingly put themselves in situations where they have no autonomy and no options by living their entire lives paycheck to paycheck or close enough to not make a difference.

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

#678

> 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.

Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…

Got this kind of crap from multiple tickets I filed with GitHub

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

#679

Earlier quoted context omitted.

Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!

No you don't. Feed the essay to Claude and ask it to summarize it for you, or just use the Jira MCP and have Claude or codex take the ticket, use the GitHub MCP to get it the source, have it go work on the ticket, have it generate the code, generate some unit tests, then you go literally yell at your computer using Wispr Flow or some other transcription software to tell Claude how to fix the mess it made, and then yo…

While I personally find that generative AI has helped me be more productive and even boosted my ability to learn things, I really _dislike_ that we’ve normalized this behavior:

Whether a Jira ticket, an email, a yearly review, we feed bullet points into a black box to get a bunch of fluffy text. On the other end, we feed the fluffy text into the black box to get bullet points.

We’re killing penguins because we’re somehow afraid to just send the simplified bullet points to each other in the first place.

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

#680
post #54

> Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work. That's really not a great development for us. If our main point is now reduced to accountability over the result with barely any involvement in the implementation - that's very little moat and doesn't command a high salary. Either we…

The value is being better at it than any QA or product manager. Experienced software engineers have such a huge edge over everyone else with this stuff. If your product manager doesn't understand what a CORS header is good luck having them produce a change that requires cross-domain fetch() call... and first they'll have to know what a "cross-doman fetch() call" means. And sure they could ask an LLM about that, but t…

Nah; the only advantage that a software engineer has is that if they are experienced they've probably just a little bit bright. But their role will probably change to something other than a software engineer. Bright valuable people that care and are engaged are rare anyway. They may transition to a different role slowly (e.g. Product, QA, BA, etc) because they still offer value and know the domain, but it isn't traditional SWE. That's been disrupted by AI; I don't want it to be true and I'm hoping for something else; but reality is staring us in the face at the moment and it isn't fair to people to talk platitudes anymore. The fact that you have to write an article like this feels like defensive framing to me + illustrates what happens once a skill is devalued by people/society due to disruption; it proves to me where this is all heading.

My thought on why people especially juniors are just delivering slop: Why bother with quality? Why bother with the craft? When it will be disrupted by the next tool/AI model/etc in the next few years anyway? Just think short term - will this slop get you through the PR and tick a short term box? If so success - might not have a job long term anyway due to all the AI stuff. In fact if I keep ticking boxes I'm more likely to last than the other person given more job incentives. Just get paid today.

In your example a QA that is skilled at testing websites should pick up CORS issues for example. And the models will keep getting better and eventually give them harnesses too - and we SWE will slowly automate everything around this because the only lifeboat left for your career is to cash out hopefully by disrupting yourself (no unions, professional bodies, etc).

Post reply on HN