Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your job is to deliver code you have proven to work

simonwillison.net

Post reply on HN
Print view View original

331–340 of 699 posts

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

#331

Post by acituan »

First problem is turning engineers into accountability sinks. This was a problem before LLMs too, but now a much bigger and structural problem with democratization of the capacity to produce plausible looking dumb code. You will be forced to underwrite more and more of that, and expected to absorb the downsides.

The root cause is the second problem; short of formal verification you can never exhaustively prove that your code works. You can demonstrate and automate that demonstration for a sensible subset of inputs and states and hope for the state of the world approximately staying that way (spoiler: it won't). This is why 100% test coverage in most cases is something bad. This is why sensible is the key operative attitude, which LLM suck at right now.

The root cause of that one is the third problem; your job is to solve a business problem. If your code is not helping the business problem, it actually is not working in the literal sense of the work. It is an artifact that does a thing, but it is not doing work. And since you're downstream of all the self-contradicting, ever changing requirements in a biased framing of a chaotic world, you can never prove or demonstrate that your code solves a business problem and that is the end state.

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

#332

Post by newsoftheday »

simianwords wrote: post #255
layer8 wrote: post #138

I’d go further and say while testing is necessary, it is not sufficient. You have to understand the code and convince yourself that it is logically correct under all relevant circumstances, by reasoning over the code. Testing only “proves” correctness for the specific state, environment, configuration, and inputs the code was tested with. In practice that only tests a tiny portion of possible circumstances, and omits…

I would like to challenge this claim. I think LLMs are maybe accurate enough that we don't need to check every line and remember everything. High level design is enough.

My jaw hit the table when I read that. Just checking here but, are you being serious?

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

#335

Post by mystifyingpoi »

cynicalsecurity wrote: post #197
0xbadcafebee wrote: post #149

Actually it's more specific than that. A company pays you not just to "write code", not just to "write code that works", but to write code that works in the real world . Not on your laptop. Not in CI tests. Not on some staging environment. But in the real world . It may work fine in a theoretical environment, but deflate like a popped balloon in production. This code has no value to the business; they don't pay you t…

It gets interesting when a company assigns 2 story points to a task that requires 6 minimum. No time for writing tests, barely any time to perform code reviews and QA. Also, next year the company tells you since we have AI now, all tickets must be done 2 times quicker. Who popped this balloon? I know I need to change my employer, but it's not so easy. And I'm not sure another employer is going to be any better.

Classic butchering of otherwise decent Scrum idea. If assigning 2 points means no tests, then you are already using story points wrong, and complaining about it is meaningless.

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

#336

Post by asadotzler »

roryirvine wrote: post #272
cynicalsecurity wrote: post #197

Earlier quoted context omitted.

It gets interesting when a company assigns 2 story points to a task that requires 6 minimum. No time for writing tests, barely any time to perform code reviews and QA. Also, next year the company tells you since we have AI now, all tickets must be done 2 times quicker. Who popped this balloon? I know I need to change my employer, but it's not so easy. And I'm not sure another employer is going to be any better.

Are you not involved in doing the estimation?

involved in is meaningless. if 10 people at a table all offer their inputs, it doesn't matter if mine is the rational one, or even if I hedged against their irrationality with an inflated estimate, the 9 other estimates will dominate. That's the whole problem here, a lack of autonomy and a lack of expectations for responsibility. Make the developer responsible for the estimate, and hold them accountable for the results. Letting the organization make the estimate and then blaming an LLM for the failure is a recipe for company collapse.

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

#337

Post by postflopclarity »

bee_rider wrote: post #273
sorokod wrote: post #178

Earlier quoted context omitted.

> One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review. I would have thought that reviewing PRs and doing it well is in the job description. You latter mention "someone" a few times - who that someone might be?

Can we make an LLM do it? “You are a cranky senior software engineer who loves to nitpick change requests. Here are your coding standards. You only sign off of a change after you are sure it works; if you run out of compute credits before you can prove it to yourself, reject the change as too complex.” Balance things, pit the LLMs against each other.

I do this all the time. I pass my code into "you are a skeptic and hate all the code my student produces: here is their latest PR etc.. etc.."

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

#338

Post by hostyle »

alphazard wrote: post #320
Larrikin wrote: post #287

Earlier quoted context omitted.

But why do that for the company instead of yourself?

This exactly. You have to be honest about why you are building something. If the answer is that you actually want to use it, then yes, quality and maintainability are important. It might even be a good idea to use no AI whatsoever. But if you are building it because doing so is in the long chain of cause and effect that leads to you being fed and having shelter, then you should minimize the amount of your time that i…

Most people spend maybe 1/4 of their working age life at a job working for someone else. Why would you deliberately sabotage that by checking out mentally and waste all that time on sub-standard work? How do you expect to earn a promotion? You can produce good code at work and even better code at home for yourself. Deliberately producing slop at work will not help anyone.

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

#339

Post by asadotzler »

SunshineTheCat wrote: post #326
xmodem wrote: post #283

Earlier quoted context omitted.

What's your point, though? Let's assume your hypothesis and 5 years from now everyone has access to an LLM that's as good as a typical staff engineer. Is it now acceptable for a junior engineer to submit LLM-generated PRs without having tested them? > It was thought impossible for a computer to reach the point of being able to beat a grandmaster at chess. This is oft-cited but it takes only some cursory research to s…

In the scenario I'm hypothesizing, why would anyone need to "check" or "test" its work? What chess players are checking to make sure Stockfish made the "right" move? What determines whether or not it's "right" is if Stockfish made it.

There are clear win conditions in chess. There are not for most software engineering tasks. If you don't get this, it's probably a safe bet that you're not an engineer.

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

#340

Post by ncruces »

WhyOhWhyQ wrote: post #284
BeefySwain wrote: post #279

Earlier quoted context omitted.

Consider that this isn't just a random AI slopped assortment of 9,000 tests, but instead is a robust suite of tests that cover 100% of the HTML5 spec. Does this guarantee that it functions completely with no errors whatsoever? Certainly not. You need formal verification for that. I don't think that contradicts what Simon was advocating for though in this post.

I think it would be interesting if professional engineering becomes more like producing formally correct documents for the AI to implement.

We have these tools that we use to write formally correct documents.

They're called programing languages, and a deterministic algorithm translates them to machine code.

Are we sure English and a probabilistic algorithm is any better at this?

Post reply on HN