Somewhere in the last year, a bunch of us who hadn’t shipped real code in years quietly started shipping again. Not reviewing it. Not architecting it in a doc and handing it off. Actually building it. And loving it.
I lead software for a living. That means my days are meetings, roadmaps, hiring, unblocking people, and saying “no” a lot. The last time “writing code” was my actual job was a long time ago. I never stopped being able to code — I stopped having the time to code. At least in my day job. There’s a difference, and every engineering leader reading this feels it in their bones.
If you identify with this post and you are in a manager position, please heed my warning. Throw away your prototypes. Stop vibing “quick fixes to unblock me”. Stop trying to help your devs because you think you’re superman now. You are only pissing everyone off, I promise. The devs who didn’t stop coding while you were off doing important manager/product stuff are the ones who understand what’s best for the codebase. And yes, they also know how to use LLMs.
Just because you feel like you have a new superpower doesn’t mean that everyone needs to be saved. Follow the damn engineering process.
100%
I got this my superior who decided AI allowed them to code fixes and we were stuck with buggy code that wasn’t merged, because the superior had moved on to a more important task requiring more AI “support” and couldn’t process the comments. Things could’ve been faster had we implemented things ourselves.
When you aren’t out in the fields dealing with stuff, you don’t know what’s important to the workers. “Jumping in” for a minute to do a task might actually slow down the team if understanding of day to day struggles isn’t present.
I’m contributing story execution. And my goal is to contribute like any other team member. My code gets reviewed. Harshly because I don’t know all the norms for this code base. And honestly it’s great because to be a technical lead I feel like I should know the code way better than I’ve had time to.
Great. The “why don’t you just…” idiots are “writing” code again and not reviewing it.
What could go wrong?
Who needs human review, the AI can do that? Who needs human coding, the AI can do that? Who needs human testing, the AI can do that? Who needs human requirements engineering, the AI can do that.
80% uptime. How did this happen?
The AI agents need to sleep, too, so the downtime is expected
Still five nines of uptime — 79.9999%.
Yeah, I thought the blog post was gonna be about horror stories, because even the greatest senior/architect/whatever will push absolute garbage into your codebase, if they don’t have the time to familiarize themselves with how the code actually works.
Even if it’s some isolated component, if they implement it without explaining the what and why to others, then no one else can maintain or debug that. And you do not want to rely on your super important guy to have the time to fix things when production grinds to a halt.
At this point I think we’re moving past maintaining projects. Tech debt is no longer going to be paid off; management will just suggest a complete rewrite using AI as soon as issues get too complex for a junior dev with Copilot to figure out. It’s going to be a mess.
I
feelfear the same. Problem is, when it’s too complex to maintain for a junior dev/intern with AI, it’s probably also too complex for a rewrite/redesign with AI…
I don’t mind writing code and having copilot review it. I can tell a clanker to fuck off in satisfying ways that I couldn’t with a junior dev.
…and there’s the one time in 10 when it sees something and I can make a minor improvement.
Still, the “Oh crap, my code actually is broken” monents are few and far between.
Could you qualify what you mean by “idiots”? The author and the examples he gives - Kent Beck, David Heinemeier Hansson, and Garry Tan - are all very experienced software engineers.
By idiots I mean the people who haven’t engineered in years.
The subject of the article.
Seems self-evident.
Well that depends on how quickly you believe that engineering skills atrophy without use.
Though, I’d argue programming is like riding a bike. Even after a long break, it’s not difficult to get back into it, as the fundamentals for programming haven’t changed.
If they’ve stopped engineering, then they probably weren’t good in the first place, what skills they had are rusty, and their knowledge is out of date.
I’d argue programming languages are like natural languages. Use it or lose it.
Writing code was never the bottleneck. This didnt make it easier. It just made it faster, people already ignored the output when engineers made it.
Weather or not this is good or not wildly depends on who the person is and what the situation is. The article seems rather self aware.
Reminds me of that one time when Microsoft said “We don’t need UI/UX designers, powerpoint is so easy that managers can do UI/UX design themselves”.
That’s how we got Windows 8.
Most of the problem with 8 was M$ insisting that desktop computers should get the mobile UI treatment because “we’re totally going with phones now so fuck you”
Them proceeding to completely fail at the mobile market was no surprise.
… Windows 11 is far worse. 8 was solid compared to 11. 8 was a pain in the ass, but it mostly did what it was supposed-to.
What does being technically solid have to do with UX?
Windows 8 had a “reason”(TabletPCs, and the success of Tiles on Windows Phone) for the changes made. The old UX was still there if you knew where to look and what settings to change; Some searching online could mostly have you back to what you wanted in under an hour. It was coded by humans, tested by humans, and consistently worked as intended.
Windows 11’s changes have no such saving-graces or anything resembling rational justification. They let their AI re-code a bunch of fundamental features, and particularly the UI/UX, from a low-level programming language to frameworks intended for fucking websites, just so they could say it was capable of doing-so. Along the way, they used AI to test the results and skimped on or ignored the results from testing done by humans.
How many times before has Microsoft publicly admitted one of their products is broken and promised to fix it? What does being technically solid have to do with UX? EVERYTHING.
Windows 8 didn’t have a reason to look like a child drew the UI in paint. I remember well the moment I first booted up the technical preview of Windows 8, being flabbergasted by how bad it looked. I choked it up to being a technical preview, they likely didn’t get around to put decent graphics in, but no, it stayed like that.
Windows 8 also didn’t have a reason to go touch-first (and really touch-only) on the UI for a OS with a non-touch install base of around 99+%. That’s terrible UX.
Any decent UI/UX guy would have been able to tell them that they should make the UI switch between desktop mode and touch mode depending on what hardware was present or which mode the user selected.
As you said, it was “only” an hour of fiddling with the registry to bring it back, so it was mostly there. A decent UI/UX designer would have just added a button or an autoselection feature.
But since they said “screw professionals, let the managers do the design” you got shitty UI/UX that caused a massive flop.
The parallel I was drawing that with Win11 and the help of AI they are doing the same. They fire the experts and have the managers and other non-experts do the job of the experts and it falls apart.
Offtopic:
frameworks intended for fucking websites,
You know who also does that? GNOME. The whole GNOME DE is coded in JavaScript.
Sure it did. Tiles on Windows Phone were a big hit for a time. If anything, the problem on that side of things was that they didn’t commit and make sure the things that worked on the phone also worked on the “tablet” version.
Instead, they took the approach that "the developers will thank us for charging them an arm and a leg to learn and use the new APIs, like they always have, forgetting that developers often follow users, and almost every user was verbal about hating what MS had done, including Windows phone users who understoo what had been promised then effectively bait-and-switched.
Microsoft’s way has just always been so inspiring, you know?
I never got into gnome. Was more of an XFCE guy for a time, enough-so to realize Gnome had “deprecated” anything I liked about GTK. I was more looking for a classic start menu style with minimal overhead, and XFCE gave me that, while most other DE’s wouldn’t let me do stuff that Windows 95 had been cool with.
An agent handed to someone who doesn’t know what they want produces a confident pile of plausible nonsense. Fast. The same agent handed to someone who knows exactly the shape of the solution and can smell when it’s drifting? That’s the mech suit. That’s the leverage.
yesssssss
I’ve long been off the critical path because as a tech lead I have a lot more random stuff (and meetings) to deal with. I’ve been able to vibe code some non-production stuff like scripts to unify feature lists across JIRA, specs and the upstream docs which has helped free up time to hand craft more code on production.
I don’t care too much about the quality or maintainability of those scripts as long as they make my life a bit easier. I do care about the maintainability of the production code base.
Agreed. This is my experience exactly, though I really only took a break from production code for about a year. It feels really good.
