I'm damn sure the answer is "no", but the devs at my workplace are all in on it in a way that's not as absurd on the surface as the "coding is a solved problem" kind of tech bros. There's an emphasis on the "human in the loop" that I think is far from sufficient; we used to have a human in the loop, it's called actually writing your fucking code!
As a sample, this is from a transcript of a recent discussion about AI with some devs on my team:
Me, a senior dev:
To be clear, I'm not saying not to forego the human in the loop. I'm pointing out that there is an inherent contradiction between using agent as our main means of writing code and actually being able to review all of its output -- be it before or after opening the PR. I'm worried that we'll end up in a position that we're expected to do something intractable, if not strictly speaking impossible.
New mid-level dev:
I just think we should still be responsible for reviewing all the output. Like how I see the before vs now is:
- Before: human plan -> human write -> human review
- Now: human plan -> claude write -> human review (+ claude review)
And in effect we're just as responsible for reviewing every line of the Al code as we were for reviewing every line of human code. Once that changes that's when the Al slop starts coming out So we should never end up posting a PR where we're like "hey guys claude wrote this so do the thing you do for claude PRs"
Team tech lead:
@AppetiteOfExcess, this is a problem across all dev teams in every industry. It's a huge issue. I think we need to lean on Al to speed up PRs, but how we do that is not well defined yet. I think it can help us get our head around a PR faster. Maybe we need to made an artifact for some PRs that give a breakdown of what is changing. Then we can grill Al once it understands the changes. That might speed things up a bit. The important thing is to really understand the code and the impact of the change.
@mid-level_dev I agree with you but I think the new process will be more like the following
- Humans (the whole team) plan by making highly defined stories
- Al makes an implementation and test plan
- Human reviews plan
- Al executes the plan with human oversight at certain steps
- Al does a review using /code-review (new context by default)
- PR is posted with change overview
- Human uses Al to understand the changes and review the code
I don't know how to push back on this while being taken at all seriously. It has me considering that maybe I'm in the wrong for rejecting a tool that is considered useful by all but a few stick in the mud devs, and that those devs will never have a shot at a job again unless they pull their heads out of their asses and join our modern "AI"-driven world.
The problem is the vast majority of software engineers are charlatans who would spend 99% of their time making annoying abstractions to piss me off personally instead of solving the problem. Now expand this to ai they can make those annoying abstractions so vast and so quick that you basically need ai to delete their code as well lol. The entire thing is a solution in search if a problem that only really exacerbates the weird dogmas software devs have put in place for years. So for the most part I use this robot shit to delete all their robot shit.
If you have to use it never get it to start the work for you only use it to tidy up work you have already done yourself, write the plan and MVP and some thin docs and get it to tidy up after using abstractions you approve.
This way you know what the code is doing, keep your skills and it really only does the boring work for you and a higher tendency to get a reasonable output.
The other use is as a searcher tool for unfamiliar codebases you can get them to map it out for you or locate something you’re looking for. Since im forced to use it at work this is how I keep my delivery speed high without completely removing my brain from my skull, it gives me direct control and autonomy where ai is a searching or formatting tool at best. It also has the main target of my already working code to go on which means it spends less time doing random shit. If you can basically target it at the stuff you don’t like doing and try to keep doing what you enjoy.
This is basically the only way i have managed to “keep up” without completely losing my soul or passion for programming. I still need to work on personal projects outside of work to keep sane though and that will be relegated to human written docs, books and typing
But don’t get me wrong im the biggest ai hater here i detest the technology and what its doing. This is only if you HAVE to use it how not to hurt yourself in the process coming from someone who actually likes solving real problems instead of inventing problems to solve. And you’re not wrong for rejecting the tool because the idea a human just needs to review slop code is ridiculous but also not even what happens in practice and blindly trusting it is kicking the can down the road but also harming your own career position and typically only promoted by people who were shit a writing code.
I've always had a visceral hatred for the term software engineer itself. The only people that ought to be able to call what they do "software engineering" are people working on must-not-fail-under-any-circumstances programs like control systems for lunar landers or nuclear reactors or MRI machines. There's a good reason that "engineer" is legally reserved term in many countries, reserved for people who are members of a professional engineering licensing body and who have gone through a formal education and apprenticeship to an engineer. It shouldn't be able to be slapped on a linkedin profile because some HR lackey says that Spaghetti McVibercoder is an engineer because they know how to vomit Claude code that they don't understand into a git repo.
The watering down of the term started with electrical engineers who only work with consumer electronics or mechanical engineers who only work with toys. Civil engineers have been seething about this for decades at this point.
In the sciences too, 30 years ago it was molecular biologists or biochemists 'engineering' strains or enzymes but now it seems a whole layer of bioengineers has grown over those research fields doing the same things. The exception is chemical engineering, that's always just been designing the plumbing for chemical plants so they don't explode
https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
The invention of this phrase also conveniently gets the speaker to buy in that economics is, in some way, a science, which it patently isn't
Abstractions are good sometimes, but only sometimes. LLMs seem to like abusing them like crazy though.
I'll pretty frequently use abstractions to take really abrasive APIs and make them easier to use. Specifically because I use Python, and no one ever bothers to implement the data protocols for their classes.
I shouldn't be calling
resource.get_next_item()in a while loop when it should implement the iterator protocol so__next__and__iter__can do that work for me.LLMs don't really seem to care about that sort of abstraction though, since it's entirely there to make my life as someone who writes code easier, and they will just happily call
get_next_itemover and over.Whenever I try to voice this at work, it falls on deaf ears. Management has cultivated a vanguard of devs ("AI champions", as they're called) over the past 2 years to ensure the decision to pivot to Slop-Driven Development comes off as relatively bottom-up.
There will always be class traitors gunning to fuck us all with the vain hope they can leave us all behind. I hate it all because I live and breathe computer nerd shit and have done my entire life, I really care about my craft and these absolute assholes just continue to shit all over it time and time again. I don’t do it for the business I do it cos I like making good systems.