I've made many friends and acquaintances over the years who are top notch, some world class, programmers.

I'd say that 90% of them are very excited about using LLMs for coding. They have nothing to prove to anyone and can easily steer AI to reach "godly" productivity (please note these guys were 10x programmers already).

I also know some weak programmers and most of them tend to be critical of AI and want to get rid of it.

Lastly, a couple of people I know are against AI for moral/ideological reasons without denying it can bring productivity increases.

This is purely anecdotal but I'm starting to notice this pattern everywhere I look.

I feel like code quality is important when humans have to reason about. However if the future is machines managing the code then all that matters is AI understanding it.

The only danger is losing grasp of internal components of the system, but maybe there'll be a "management" layer eventually for humans.

I don't know what the future of programming will look like but I don't see us rolling back the clock to 2021..

> or be stomped into the ground by EXPERIENCED programmers who do

FIFY.

I've found experienced devs with AI is a force multiplier, but AI in the hands of juniors however is my hovercraft is full of eels.

We use AI to write almost all our code in a fintech - trading applications. If the quality is low, bugs cause monetary loss. Degradation in performance causes monetary loss. And so on. It doesn't happen. We have very good functional and non-functional testing and the coding agents are able to iteratively add functionally correct features and improve performance.

I don't understand what other people are doing differently to get worse results. We cannot ever go back to humans writing this code, because our competitors will eat our lunch if we do.

I think there is a big industry push on "use AI to deliver features faster".

It could have also been a "use AI to test our product more", but I don't see that anywhere.

I hope you agree LLM's can actually help with quality, if used for that purpose?

I am not doing small changes though, I add large features or refactors daily, which involve changing hundreds of files and thousands of lines, even if I wanted I couldn't review everything by hand.

But will we need fewer people is the question.

The productivity gains will go where they always go when a mature industry undergoes automation. We'll reduce headcount, ramp up the output expectations of anyone lucky enough to keep their job, and expand the operating margins for shareholders.

None of this capital has ever been earmarked to build better consumer utilities.

The productivity gain is invisible using your metric.

What I have seen is that, with LLMs, an entire class of process brokenness disappeared in the in-house codebase. Before, there were many trivial tickets that, in the end, required a 5-line bugfix sitting in the queue for months. Now, such tickets are resolved instantly, and the backlog is shrinking.

Because the code is and almost never was the problem. Product design and business involves a lot more than code.

Personally, I did see a lot of entry-level products having a lot higher quality and better UX. At the same time, most companies go for fast iterations and are profit-focused, do product quality is not really a target for many.

Have you considered asking them to write the prompts?

I simply test the final result,manual tests, automated tests, benchmarks, people using the apps and giving feedback, increased number of sales, etc.

Also to make it clear, I am not saying the code itself is better, but the end-product and what the user sees and gets. Like that saying "if it's stupid, but it works, then it's not stupid"

Because the exact same processes that create it faster, are also now generating large comprehensive test suites, and data-validation suites based around the actual business requirements and data/edge cases.

In essence, it is writing the code faster (great), but then also writing the code that was often previously never written due to budget/time limitations (comprehensive testing/validation).

So, how do you know the code is the highest quality ever? Because we have test result data that PROVES it to be the case. It isn't "trust but verify" it is "Don't trust. Verify."

Very little code written in the world day to day ever has to justify its 'quality' or long term value. A lot it is just one off tools, bits and bobs to make a teams life easier or whatever.

I used to work in Web agency for sizeable brands and not a single site I built lasted over a year because the companies changed concept regularly. The next agency would come in and tell them it was built wrong and couldn't be reused etc etc. We did the same, it was irrelevant how it was built and we didn't even look. This is the nature of most code. The problem is that very few people will ever be in a position to be writing verifiable important code, but every developer likes to cosplay that they are.

Most code is ultimately an, annoyance businesses need to meet a goal that will always be a cost. It's often worth treating it as such and writing things that are easy to spin up and teardown.

The people most vexed by AI dev appear to be the ones who think writing code is a pinnacle role, it's not even though over our lives the salaries would sometime suggest otherwise. That's ultimately going to be a short term blip in the landscape and most code will be one seen as the cost it is.

A programmer's output was never code. It's was just what we had to do to get computers to work for us. Now I just ask a genie to do what I did and check the results.

How do you know it's high quality if you do look at the code?

Competitive programmers don't usually produce quality code, I'm guessing it could hardly be worse even without looking at it.

He must have been a really bad coder.

Claude told him so.

Indeed, I am just building apps people use, they are not "critical infrastructure" and the world won't end if there's a small bug, I don't vibe code self driving cars, defense systems or medical devices. A

If there is a bug, it will be fixed quickly anyway, so only a few users might ever see it, or see it only for a brief time.

Even when manually coding, projects still have issues and bugs, I don't think much changes in that aspect now, if anything, there are fewer bugs now in most high quality apps than before, due to AI catching more issues. See all the vulnerabilities found in old core code and libraries nowadays, that humans didn't find.

There’s a huge gulf between toys and critical infrastructure.

LLMs write better code than humans with fewer bugs. They also do it much much faster so you can spend all the remaining time testing. Tests are written faster too so not only you have more time for testing but also you can use it better.

>>Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?

>>Don't you see the contraction you just did there?

I wouldn't trust anyone who refuse to use LLMs for programming. Their code is worse, they test it less and it takes longer to write. For me "no LLMs" attitude is a sign of incompetence. Good for hobbyist trying to keep their brain active but that's about it.

That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.

"didn't even look at it" is a giveaway of the OP being a liability on top of a boaster and the company who employs him deserves to go out in flames

Wonder if he tells his boss to "I pushed critical code to production without even taking a look at it" or is it just for show on HN