I dunno dude, it's getting scary fast. You tried a fable/5.6sol maximum effort on a chunky task yet?
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.
Interesting that you use self driving as the metaphor here, when we've been told for years that self driving will be taking over the roads any day now... and yet...
Still waiting to see the scary products of AI. I see cool tech demos, sure. But I'm not scared just yet.
A very large percentage of systems you use every day being built with AI?
Coding has changed butbuissness has not.
Or unemployed, the jury on that is still out.
Real question here, as I'm struggling with this and I'm not finding a lot of evidence to support my inclination (that you are correct).
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.
> Software works 80-90% of the team exactly as it should.
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.
I think you might be taking that number a bit too literally. What I mean is, it works enough that no one is complaining. But, all software has bugs. Some are logic/syntax bugs, and some are intent. "It should do this, but actually does that."
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.