> So, I admit that I'm finally getting into this "let Claude help you write code" stuff, and I'm enjoying it a bit for the stuff I, honestly, just don't want to write; but ... I still read it. I still review it. I still look at the code like I'm peer-reviewing it and go, "Uh ... I don't like this area at all. That's going to be really hard to debug at 3am" and so on.
I used to. I've stopped in recent months, only because I just can't keep up with the pace it's churning out the code. If I was to read it, it would take multiples longer to develop anything, maybe into orders of magnitude longer. Occasionally I'll dip in just to get a sense of things, especially if it's struggling with something, or at the opposite end, if it's completely trivial. But I'm hardly reading anything now.
Why? You own the pager, I assume. You own the mental hit when something you let go live (especially with your name on the PR) leaks customer data or deleted someone’s work.
And if you’re not reading your own work, is someone else during the PR? Are you reading other people’s PRs?
How do you know what your product does and how it does it?
From what I understand for most people it isn't a conscious choice, it happens slowly over time. People naturally don't want to waste time, the code is there and if you don't look too closely it works, so they start skimming instead of going in-depth, expecting anything majorly wrong to pop out. But those things probably won't because generated code is very good at looking extremely high quality at a surface level no matter how bad it actually is. So eventually even the skimming starts feeling like a waste of time so it tapers off too.
When the combustion engine was invented, and we got the means by which we could accelerate our trip by 10x, and at the same time scale it to multiple people, we didn't tell the humans to keep pushing the vehicles by their hands, didn't we?
As a developer you are more akin to a car mechanic, who’s still expected to know how the engine works even a century after it was invented, rather than a driver, who is just the user in this parallel.
Mechanics I've been to generally have no idea about how things actually in the car work - from what I could understand, area is full of recurring problems, and this exactly benefits mechanics to solve them through trial and error approach rather than understanding much how underlying things work. Pretty much close to what I would say SWE will turn into, there's no other choice IMO in foreseeable future.
I think you underestimate the skill of more experienced mechanics. Tractor (as in 18 wheeler) and master mechanics tend to know what’s going on under the hood in detail.
I’m sure there are many of those, but like everything, there are tiers. I’m sure we’ll get something similar in SWE, but my hope is that you’ll still be able to choose to be a high tier engineer if you wanted to
Evidence so far does not suggest people driving off a cliff so while a valid concern it's not a likely one. We also acknowledged that the benefit of using a vehicle is such that it outnumbers the risks it may introduce. We never said there will be no risks attached.
We’ve only been on this train for 3-4 years, and in that period, we’ve already invented terms for this kind of vibe-coded, highly-breakable crud. We’ve also had a few, relatively high-profile in their spheres bugs come out and hurt people’s real, lived experiences.
And that’s just the stuff where the house of cards failed quickly.
Software by definition has always been and will remain broken in one or another way. AI makes no difference or whatsoever. Arguably, it will help raising the quality of software.
Exactly. That would mean going back to square one, and I also personally don't review the code anymore but I am more focused on asking the model to demonstrate the value it created through benchmarks, workload-generators, and e2e tests.
Mostly it proves as a valid approach, barring the bugs the model can introduce to value-demonstrating benchmarks which can of course skew the evidence on hypotheses, and thus code trajectory the model opts to go with.
The problem I see with this is really that I am not anymore under the control but I am not sure I see other alternative. I am becoming more and more like a system observer with surface-level understanding of the system rather than the engineer with zoomed-in level of understanding of how the code actually behaves. Perhaps we're transitioning into a QA roles present.
I used to. I've stopped in recent months, only because I just can't keep up with the pace it's churning out the code. If I was to read it, it would take multiples longer to develop anything, maybe into orders of magnitude longer. Occasionally I'll dip in just to get a sense of things, especially if it's struggling with something, or at the opposite end, if it's completely trivial. But I'm hardly reading anything now.