I think people will come around to accepting llm written code eventually, but it's hard having your entire career, and identity, upended overnight.
Many people, myself included, have come to define themselves by their coding skills. They've taken great pride in not just solving the problem, but solving it in an elegant or nice looking way. Crisp comments, nice spacing, clever abstractions.
In an age where an llm is better at scanning the code than you are, these things just do not matter anymore. Llms will be doing the debugging. Llms will be doing the writing. Llms will be doing the optimizing. And so all that matters is that llms can make sense of things.
And they are much much better at making sense of things without the need for so many of the things that humans rely on as waypoints.
The skill is no longer writing the code. It's solving the problems. Maybe it always was.
That's not a distinction that people really benefit from.
Approximately nobody can read other people's code for intent or quality, let alone to surface malware meant to be hidden in it.
For almost everyone, the only hope is that somebody else validated the code you want to use before you choose to use it and successfully interfered with its distribution upon finding an issue. That's why the culture of automatic-updating package managers and bloated dependency graphs are so dangerous and why inserting delays into package managers can make such a difference in exposure to supply chain attacks for those that are intent to use them.
It's true that open source provides the transparency that makes any kind of third-party validation possible, but closed source benefits from commercial vendors staking their brand on what they release. It's a tradeoff, not a straightforward win for one side.
I think the most obvious impact (good AND bad) will be from people who didn't have (or want) skills to begin with being empowered to have a model crank out custom software to do little things to make their lives better. Can't atrophy a muscle that doesn't exist!
The tools can definitely go away. They could get exponentially more expensive to where it is no longer financially possible to keep it subsidized. The bubble could pop and most of the companies could go bankrupt. It's not exactly like a calculator because it requires such an astronomical amount of resources to keep running.
I agree with you but there is a calculator analogy where the resources are local and while taxing for most, viable for the individual. Local AI is less capable than an army frontier model agents but still quite useful.
$10 gift became $10M for city government, with $30M tax expected over next decade
I mean... pretty easy to see why...
I think if the city tried to communicate what that money is going to be used for, perhaps it'd be slightly more palatable.
Or perhaps the pitchforks are already out, and it wouldn't.
The problem is that these things often don't manifest. There's a massive data centers near me. Supposedly we're supposed to get all this blah blah blah. Well, the data center "accidentally" didn't pay for several months of water to the point where the local cost of water went up what what they thought was a shortfall until they realized nope, we were just stolen from. And no way could we fine them for this total accident of not paying their massive water bill for several months. They're put business partners. Somehow.
Also, I've had more black outs since the data center has been active than I've ever experienced. I'm sure these things are unrelated. Along with the increased cost of electricity. And I'm on the other side of town from the data center. The locals nearby complain about more.
I still don't know what supposed benefit I got from it being here. We already had a well funded government before the data center was here.
I think this situation is why many are so anti-data center. The city gets the cash from the land sell and they get some temporary industry from the construction and then it's just a drain on the area.
4d chess move is to sell it for the price they'll pay out in salary to the city lawyer, city engineer, favored contractors, and whoever else will show up as paid "expert witnesses" to the trial defending the sale. Whoever challenges it thinks they're costing the state, when in fact the trial is the whole grift and it doesn't even matter who wins.
A thought I have been tossing around in my head as the models get better is that it really may not matter what the code looks like.
If the observed behavior of the software is good, then the software is good.
If a bug, of whatever kind, can be fixed by a model on a vibe-coded codebase, then that's a fixable bug. If there are no exploitable vulnerabilities, then the code is secure. If the performance is adequate, then the code is performant.
It simply does not matter what the code looks like if, from the outside, it does what its supposed to, and, from the inside, a model can fix the issue if one is found.
More than ever, software engineering is now really a job about making sure the code is doing what its supposed to.
And even if it DOES matter what the code looks like, you can have a model fix that too.
The thing is that a lot of code rely on multiple layers of abstractions with their own correctness and failure states. And then you overlay the domain correctness and failure cases on top of that.
But all of those correctness are imaginary. The hardware only enforce a few (and it may be buggy). The OS adds some more (and it’s buggy). The compiler/interpreter may have bugs (but that’s rarely a nuisance) and the libraries are often brittle. There are cracks everywhere in the tower of abstractions.
The code has never mattered. What has always mattered is the knowledge of what is the model of correctness of the software (programming as a theory by NauR), so that you can discern where a program is wrong.
The thing is a crash or some other immediate errors are actually nice to have. You get to react immediately and can have a core dump or a stacktrace that points you the error. What is truly a terror is silent corruption (wrong order of operations, wrong values for a comparison that has expanded the idea of correctness, security issues that has been backdoored for years,…).
As Hoare said:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult.
LLM are very much the second kind. You write a lot of complicated code, and then you can no longer reason about their correctness.
> There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult.
Don't forget that LLMs are trained on human code. If they cannot understand what your code does then they cannot make changes to it, or at least - having them understand your codebase becomes expensive (more trips to Anthropic servers)
Many people, myself included, have come to define themselves by their coding skills. They've taken great pride in not just solving the problem, but solving it in an elegant or nice looking way. Crisp comments, nice spacing, clever abstractions.
In an age where an llm is better at scanning the code than you are, these things just do not matter anymore. Llms will be doing the debugging. Llms will be doing the writing. Llms will be doing the optimizing. And so all that matters is that llms can make sense of things. And they are much much better at making sense of things without the need for so many of the things that humans rely on as waypoints.
The skill is no longer writing the code. It's solving the problems. Maybe it always was.
reply