The bill for the API usage was _hundreds_ of times higher than the subscriptions. Companies with a few hundred engineers, but without sky-high margins, simply cannot afford not to understand their codebases.
We'll have to wait and see how many companys get hurt by overuse of AI coding, the one I work at included.
I also don't think this is the right way. We are giving away practices and lesson learned over decades, in just over 6 months without fully understanding long term implications both technical and non-technical. And that is based on very optimistic bet that models will be able to handle all those potential issues that we might be concerned about in present. All the arguments/counter-arguments are mostly speculative, and I think only time will tell. My speculation is that this all BS will at some point self-correct at some point, it wont be like pre-LLM but it wont be crazy vibe-code don't look at code (or pretend we review code) either.
"An agent wrote the code" is not an excuse for failing to understand how the system works and fits together.
If you do multiple review passes you almost always end up picking up numerous issues in the first two passes, sometimes quite crucial.
We all may end up ignoring the source code most of the time. But for a few years at least, we won't be able to ignore the quality of it, because nobody knows how to use "AI" in a way that has stable high quality over years of changes.
Being able to speak to what’s possible or not will definitely be a valuable skill.
Hopefully when the cost of tokens rises and your company can no longer afford to pay for it at the level needed that someone will be willing to keep it running.
Also: syntax is for humans, might as well use LISP AST syntax for all future languages since no human is going to read it anyway.
I thought it was a pretty insightful point coming from a 16 year old boy (being a former 16 year old boy myself).
I think this is the place where a lot of "coders" are now, they only cared about the manual part of the job which is gone.
What's different in software is that developing software always kinda was building and designing factories spitting out copies at the end (while actually creating and distributing the copy increasingly being the easy part). So in this profession you have a split between people who were actually only in for the manual part of building the factory while you have others for whom the manual part always was just a means to an end. With the purely manual part gone there is still a shitton of work left which is in the end a lot more complex and challenging than mere button pushing but it's different work.
I think this is a very small part of the population, if anybody. Craftspeople, perhaps definitionally, are people who care about the work of making AND the results. This is true for many many devs.
That argument has been repeated so much while all the experienced developers keep saying that coding was not the hardest part of the job. The hardest part was adding the new changes while ensuring the system doesn't break and that it's still easy to modify later. In the latter case, intuition plays a big role into labeling what is a core truth of the system (unlikely to change) and what is a transitory need.
Coding was just something you do (and relax while doing so), not something you put your whole being into. When I code, I mostly think about the system. Which is why I look at the docs and my notes often to check the semantics of whatever symbols I want to use. I don't think about the actual typing of the code.
That's the actual argument against agentic coding. No one is checking semantics, it's hope and prayers that the software is correct.
The hardest part, by far, was ensuring you were delivering value. It was, and is, all too easy to build something technically impressive but completely useless.
Verification isn't nearly as hard. We understand very well how to minimize the chance of error. With humans involved there is still room for mistakes, of course. There is no such thing as a panacea. But the space for failure here is significantly smaller than in the above.
> it's hope and prayers that the software is correct.
I don't think anyone has thrown away their verification systems. If anything, they've doubled down. And for what mistakes can be made within verification, LLMs are quite good at recognizing those mistakes, so it is likely that software has never been closer to being correct. There is still no such thing as a panacea, but we're a long way from relying on hopes and prayers.
In most software, value is not solely about new features (to get new customers), it's also ensuring that existing features work smoothly (so that customers don't leave). I got maybe one or two features to deliver each quarter, but I could spend all days hunting down customer bugs.
> Verification isn't nearly as hard.
Only when you're experienced enough to design the codebase to ensure so. It's easy to write un-testable code. And so many times, I've seen code being written with no clear requirements. And the dev does not track what is a hard constraint versus what assumptions he has made. It's up to the user to test the software and fixing each bug is like hunting in the jungle. It's that attitude that get amplified by LLM tooling.
But they do still need the job shop machinist which fill essentially the same niche using slightly different tools (mills and lathes rather than forges and hammers). Is your 16 year old implying that LLMs are the programming equivalent of a mill/lathe in metal working?
Another note: some software has a history of multiple decades. In fact, I happen to work on such software. IMO it would be irresponsible to turn the code into an incomprehensible slop fest just because some AI boosters want me to believe that "coding is solved" or "software is dead".
Code quality is no longer a concern to almost anyone
If that's true (and it is not), it's only because almost anyone is "making" code now. That they don't understand the importance of code quality means nothing; it remains important without them. And professionals certainly don't need to pay attention to these inane oversimplifying takes of "what software is now".Well, one engineer decided to take a look at the code and found one file was 20,000 lines long. It was an awful mess with too much going on. So much for "AI governance". I knew this was going to happen but these guys don't want to hear anything about being cautious with AI. The solution is always more AI.
I am looking for a new job.
For now there's still human reviews but soon it will be all automated. I estimate that the AI review (latest Opus) is around 15% to 20% accurate
I immediately stopped writing any code by hand. If they wanna pay me more to do a worse job, more power to them :)
If that's the worst you can say, then it's done a pretty good job.
I remember the "software craftsmanship" movement of the early and late oughts. Refactoring patterns, clean architecture and all that--nobody outside a tiny group gave a single sh*t about it.
I'm not saying this in a sneering tone. I'm incredibly sad about this state of things. But the industry as I experienced it very rarely placed any value on quality code. So when I see ai writing code I don't see anything of value being lost. I suspect that a lot of high quality code will still get written by people who care and direct their agents to do so. Similar to how a carpenter can produce wonderful work with power tools but a regular joe will produce awkward wooden slop.