Hacker News Reader

> See you in a few years when we can’t even keep up with the deluge of error prone programs.

I think the worst case of this situation will pop up before that; not writing code at all but just hook the AI up, ‘prompt engineered’ directly like so;

     <body>
     <script>doInsuranceForm();</script>
     </body>

Which will AI generate a html insurance form every time the page is requested and handle the user input etc. And it’ll be subtly wrong most of the time; it’s insurance, who knows if the current programmed forms are correct anyway (I know of at least one insurer that rounds off $0.01 wrong almost every policy because of using float for money on the web side).

Why have the AI make code we can read? Just let it do the entire thing /s

It’ll happen though and it will be used seriously by companies. The quality of the AI, legislation and public/consumer complaint fallout will determine if we get back to code that humans check. Being sceptical about humans wanting quality over paying as little as possible, I am going to say no.

> A former colleague of mine challenged his grad students to implement an error-free version of binary search. He gave them the specification and verified each one: the majority of the submissions had errors.

I was in a class on Isabelle where we had to write and prove correct a binary search function. As I recall, everyone admitted that their first function didn’t work.

Java's was broken till '06

https://en.wikipedia.org/wiki/Binary_search_algorithm#Implem...

People often do (L+R)/2 but that can overflow. Using L+(R-L)/2 avoids the overflow problem.

As someone who has a binary search in their interview question, I will claim that far more people run into the problem of trying to do midpoint/2 and midpoint*2, long before overflows.

AI will be a major productivity enhancer. The things that make programming interesting will be what programmers focus on in the future. There's so much potential software that could be written that I don't think that the number of programmers will decrease at all.

This may be true, and it worries me. I have a (completely unproven) conjecture that things that make programming boring (like writing boilerplate code) are more or less things that let us avoid burnout.

How many hours per day can you stay focused on difficult (or at least non-boring) problems? And for how many years?

Whenever someone says "AI = productivity enhancer", I hear "AI = burnout accelerator".

Burnout has different causes.

For burnout because of intense work, it could be that the movement to reduce the number of hours we work will come at the right time. 4 day work weeks at 100%, for example.

Lots of people experience burnout because writing boring code can be mind-numbing. Then there are people factors, such as a bad manager. Perhaps AI can give us more understanding management?

IME burnout is neither about boilerplate or traditional "interesting" problems, it's about "somebody else didn't do their job right" problems like the infamous "why can't I just serve 5 terabytes?" story or toxic work cultures.

https://rachelbythebay.com/w/2021/10/30/5tb/

If it takes away the boilerplate and the interesting problems leaving us with just with 5 TB problems then yeah, burnout city.

If programmer numbers decrease it won't be as a result of running out of things to code or AI, it'll be as a result of market consolidation within a few, extremely powerful firms who can squash most competitors like bugs.

Like the US auto market - a once thriving ecosystem of fiercely competing innovative small businesses consolidated into 3 vertically integrated firms who now think innovation is building a slightly bigger truck.

Of course, they'll probably blame it on AI coz a story about the inevitable march of technological progress invites less government oversight of the abuse of market power, and we will no doubt be plied with plausible sounding stories to that effect.

> AI will be a major productivity enhancer.

This worries me. The problem of programming isn't that we're too slow at writing code. It's that we're not thinking critically enough about the problems we're solving. And the way we approach programming is to not fully understand what we're doing and derive joy from fixing the result of our neglect later on.

TFA touches on this a little but doesn't dive in deep: how do you know that your software does what you think it does? In such a small example, a world renown researcher missed an error! Several people did. In their current state, LLM's will gleefully give you wrong answers as if they're 100% correct and it is now your job to verify they are correct. Most programmers do not know how to write a proof or other sort of formally verifiable specification. How will they know that the code they are about to commit is correct?

For now, LLM's aren't capable of mathematical reasoning. You can't prompt it for a piece of code and then ask it to demonstrate it's reasoning or prove to you why the change is correct with regards to your specifications.

And to make matters worse, humans are terrible at finding errors in code. Empirical studies on large scale informal code review suggest that humans can only reduce error rates when reviewing somewhere in the realm of 200LOC every couple of hours. We're not effective at finding errors to begin with and our abilities drop precipitously if we read too much code. Now we're going to have an assistant that generates possibly correct code and we're going to have to proof-read hundreds of lines?

This does not seem like a good use of time or enhancing my productivity.

I think we need to wait until we can get ML models that understand proof tactics and kernels to help automate proofs. I would be much more willing to accept code from a bot that can demonstrate its reasoning and isn't simply generating code based off of statistical models. Computers are nefariously discrete machines and "almost right" isn't good enough in many, many cases.

What will enhance productivity, in my humble opinion, are better languages that let us write more precise specifications and can derive the code for us.

> I think we need to wait until

I think we should take advantage of any improvements we can get, that result in a net gain, for the individual. Programming is a practical endeavor. There’s no need to wait.

You’re absolutely right! Don’t wait! Learn how to write proofs and use model checkers today!

But I think most people will prefer the easy way out.

We often have to spend so a lot of time and energy on boring but critical tasks like writing repetitive CRUD code and tests. LLMs can free up that time and energy for critical thinking.

We will have to review code LLMs write, I don't doubt that, but the overall process should be faster. Additionally, they can review the code we write as well.

LLMs can find bugs in code, not all for sure, but they have the broad knowledge to be able to at least suggest lines of code that aren't working and why their reasoning.

I think this idea of having formal methods integrated with AI code gen will be really powerful. If we can write verifiable specs, or even a way to automate approximate verification, then it can be used a s a scoring function to train an machine learning algorithm that performs codegen.