At this point I literally have no idea what modern coding is supposed to look like. I still open my editor, type stuff in and run make. All these tools are released daily and they just fly over my caveman head.
All I do now is spend all day on calls with people whose shit exploded and I'm trying to scrub it off the walls, ceiling and the customers.
Why in the world would I want to become someone that doesn't write code?
Are yours?
Good times ahead!
Interjecting, here. Perhaps not an academic repeat of five years ago; is this an eon for Technology or not long enough? I've lost track. Anyway, I appreciate the optimism.
An anecdote, from the ground floor: this industry has shown it's paying leagues of on-site hands to install systems, at scale, from USB keys. PXE products have existed for decades; we're writing one [to adopt] when we could take one off the shelf. These artisanal OS installations are too rich for my blood. Or, they would be, if this modernization didn't happen to be the code I'm still writing by hand. Half a decade in (or several) depending on perspective.
I'll believe things are progressing as you say... when this type of mismanagement stops happening like clockwork. Want more chatbots/datacenters? Catch up to the mid-1980s; BOOTP 'just' dropped.
I still like reviewing code, but I don’t need to physically write it
If anything, my setup has gotten ever so simpler as models got better.
Why would this person be more skilled? And more importantly, what does it mean to be "skilled" in the era of AI?
I'm trying to be open-minded to both sides, but I have senior engineers on my team with a fleet of agents, shipping code they don't fully understand, and... everything is fine. Stuff still breaks, we fix it. Clients ask "How does XYZ work?" and we say, "Not sure, let us get back to you." And they're totally fine with that answer.
Everything within me screams that this is wrong and we should have intimate familiarity with the system, but I cannot find any evidence that the path of "running a team" instead of "building engineering skill" is not going to work out fine in the long-run. (Yes, my comparison between "team" and "engineering skill" is a bit rough but I'm not interested in the semantics.)
All the evidence that I'm seeing in my own business, with senior engineers meeting clients' needs with autonomous agentic teams is that it's all fine, and while there are gaps, it's actually okay. Clients are happy. Software works 80-90% of the team exactly as it should. Bugs are fixed quickly. We ship more in 3 months than we previously could've shipped in a year. I'm baffled and frankly not as advanced as my devs (I still ask questions one by one to my agent, like a Real Caveman!)
It makes me wildly uncomfortable so I'm trying to wrestle with this. I want your statement to be true, but I just don't see evidence of that.
Either you work in a non-standard field, or your standards for software are way too low.
What software gets to fail 80% of the time? If your ecommerce checkout software fails 1 in 5 times, you don't have an ecommerce business at all, you are dead in the water. If your airline booking software fails for 1 in 5 customers, you are out of business.
99.99% reliability still means 1 in 10000 customers are experiencing an error, which at scale can mean thousands to millions per day. That's completely unacceptable for any software I've ever been involved with writing.
The sum of ALL of these classes of bugs is such that our clients haven't complained about the software being particularly faulty. It's impossible to tell if it's more or less buggy than it would've been written entirely by hand, but I suspect it's less buggy than it would be if written by hand.
I spend a lot of time reviewing code and the LLM code works for what the implementer wanted and from the outside things function the way people expected, but inside the code is becoming more and more knotted and incomprehensible.
Now maybe you could point claude at it and say "make the code easy for people to understand too" and no one is bothering to do that. Maybe it's a skill issue and the people around me should be prompting better or revising better.
The only thing I know is that I'm seeing it happen. Code quality is going down, comprehension is not just missing because people didn't author the code, it's getting worse because even when they go to read the code it's become too complex and weird. So now they have to rely on LLMs to tell them what the code they are responsible for is doing and how.
The thing that remains to be seen is if comprehensibility will matter. I can't look at the assembly the compiler outputs and comprehend it and it doesn't bother me. LLM advocates argue the same will become true for code, it won't matter if you understand the code because it only matters that the LLM can comprehend it and keep making it do the things you want.
I'm less inclined to believe that being able to reason about your codebase and make changes to it is something I really want to put into a bunch of hyperscaler company hands. Enshittification tells me that this honey moon of affordable intelligence will reach an end at some point and a lot of companies are going to clamp down on more expensive tokens and a lot of engineers are going to find that they have both let their code comprehension skills atrophy and aren't permitted to take every little question and change to the LLM because it's too costly.
They will crack open the codebase, every changeset with a full comprehensive page of LLM-speak explaining how it addresses the problem, every changeset in isolation reasonable enough, and an end state that is something only an LLM can love.
Maybe in a few years being a good coder will be like being a good taxi driver with self driving. You know the best spots and the ai can't drive the most unusual roads but effectively 95% of all driving is self driving.
Coding has changed butbuissness has not.
1.5 million people use it for 90%+ of their drives
Prolly what, 30yrs? Places like SV or other advanced locations will hit majorty faster than that. The rest of the world ~50yrs.
Hype is fast but tech is a decades rollout. AI will hit its stride in 5-10yrs. Which is scary because it's already stupidly powerful. Saturation of AI though is still a 20yr+ horizon.
I test it. I have another AI do code review. I push it to test, then after tests to production.
For some common tasks, that I don't find interesting it is great. I do a lot of CRUD, I honestly cannot imagine writing these apps without AI.
It made curious and freed my brain to think about other things. I am now playing with hardware and plan on launching a niche product. This would not be possible if I 100% committed to programming without AI.