Cleaning up after AI rockstar developers
codingwithjesse.com
codingwithjesse.com
I'm right there with you, but this last sentence concerned me a bit.
In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives. You can still get hand-made leather shoes, but very few want to pay $1000+ for them. You can still get art and paintings that someone poured weeks of work into, but most people buy their wall-art and chachkas at HomeGoods.
The main difference is the disposability assumption, and software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are. This mindset doesn't align well with software that must continue to operate in order to support some process. A disposable countdown app, sure, throw it away, but anything built around long running business processes should not be treated in that way.
I have concerns that focusing on software craftsmenship frames the issue as "boutique and bougie and unneccessarily expensive" vs "what I need for my usage", instead of "maintable and trustworthy" vs "disposable".
[0] Is that an initiative that benefits large model providers like OpenAI/Anthropic? maybe, but that's not my point here.
Sure, that cheap desk that arrived in a flat box and got assembled by me and a screwdriver was mass produced in a factory. But it's design had way more expert craftsmanship put into it than would ever be feasible for a bespoke product. High upfront design cost, then mass produced at a low marginal cost.
That had been the state of art for software from the beginning. When you download Firefox, there is no expert programmer carefully building you an artisinal web browser. There is a CDN server sitting in a data center somewhere copying bytes out of its cache for you.
One of the things AI us threatening to do is replace the CAPEX craftsmanship, which has not happened at scale in other industries.
What AI has had more success at it replacing low end "artisinal" software; which is a category that has thus far been so uneconomical is essentially doesn't exist.
The LACK (https://www.ikea.com/us/en/p/lack-side-table-white-30449908/) is probably one of the most optimized pieces of furniture you can buy. There's no hand crafted desk that can be this cheap. A wood worker won't even get out of bed for $17.
Now is it an amazingly beautiful, rock solid, heirloom quality piece of furniture? No, but it's not trying to be that.
Programming is the equivalent to designing a factory, not carving out wood pieces.
I've worked in large organizations where a small number of staff+ engineers were approaching programming as factory, while many more engineers were obsessing about the details of their own narrowly-focused work and liked it that way.
It feels like the scale is tipping more towards the factory model and, understandably, not everyone is excited about that.
Yes there is expert craftsmanship in the industrial scale design of ikea products, and yes there is expert craftsmanship in a bespoke, handmade wooden desk, but AI results in neither of these. It's cheap and disposable and tuned for putting up the appearance of something high quality without any of the actual intent that would be put behind either of the other two examples.
I also don't agree that software is disposable for the same problem. If it's a temporary problem sure, the code is thrown away and we create something new when another, different problem comes up that can be solves with software.
But if it's an enduring problem? The code sticks around.
There is no equivalent of unit manufacturing in software since it's just copying around bits.
"Craftsmanship", then, in the context of software just means how much you give a shit about designing something good. That's not going anywhere unless we get to a point where even the quality of the software that we use ceases to matter, and there is nothing to indicate we're moving in that direction.
A screw used to be a bespoke and precious object. It took a ton of time and effort to make a good screw. What we would today consider a 'machine screw' could only be made by extreme labor from someone very, very skiled.
But the thing about machines is that a machine can transfer craftsmanship. You can make a single really, really good screw and then a machine can transfer the quality of that screw into countless new screws.
In the modern era, screws of all types and qualities are more or less equally disposable. We produce in the billions today screws that would take days or weeks to cut by hand.
I sort of view AI the same way I'd look at a lathe without a leadscrew. You have to make your own screw by hand the first time, and then you can transfer whatever quality you can muster to any number of new screws. If you get better at making new screws, you can load that into the lathe and start making more and better screws. But you are fundamentally limited by the quality of screw you can make yourself. If all you can manage is a crooked lumpy mess, then that's all you'll be able to get out of the machine.
I don't think handmade shoes are the right comparison, unless you're talking about software that's meant to be used by just one person.
The more apt comparison might be to the engineers building and maintaining the manufacturing equipment in the shoe factory. It's a degree removed from the consumer, but there's definitely still craftsmanship involved there.
Not sure what that proves.
> considered a 10x developer
We need to stop exaggerating so much. A 2x dev would be insane! A 1.5x dev does a year's work in 8. A 1.1x dev does it in 11. Saving a whole month itself is a massive amount of money saving. Our "10x" devs are really 1.1x and I'm not sure why we see that as anything less than wildly impressive.
Can we stop exaggerating so much?
Even assuming that maybe the average developer could come to learn how to solve the problem you can easily see the gap between taking months to learn how to solve a problem versus already knowing how to solve it on short notice being over 10x.
Large productivity differences are mostly a function of differences in capability than differences of speed in solving rote problems easily within their capabilitys.
> Have you literally never run into a problem that the average developer can not solve, but a expert can solve?
> Even assuming that maybe the average developer could come to learn ... already knowing how to solve it on short notice being over 10x.
Clearly I understand the gap, I explicitly mentioned it. I mentioned a month's work is quite valuable. I'm not the one diminishing that value, you are.
I can totally buy instances of 10x improvement, but that's not what we're talking about and not how anyone is using the term. Everyone is talking about sustained output. No one gives a shit if you're 100x for five minutes but 0.5x the rest of the time.
Your critique isn't wrong, per say, but it is a non sequitur to the conversation.
I doubt even a staff level engineer is even a 10x above the junior. Will the staff level engineer write better code and faster? Hell yeah they will! But will it take a junior 10 years to write the same software a staff level does in a year? Maybe. But if it does I'm not convinced they're even trying, so not a fair comparison. 10 years is a lot of time. A lot of time to learn, refactor, or even build the damn thing from scratch a few dozen times.
Seriously, 10x improvements are actually wild.
But why dismiss a 10% gain as if it's nothing? Why is the smaller number bad?
Is the need for the number to go up so strong that we don't care how divorced from reality it is?
Yes these exist. The rate at which they exist is grossly exaggerated. Every company likes to think that their problems are special snowflakes. Nothing could be further from the truth.
In these discussions we try to solve for a 0.00001% problem by claiming it's common to encounter.
Put simply, the 10x developer is a 10x because they've spent ~10x more time immersed in the problem domain than the average developer.
What they do is more sleight-of-hand than Tony Stark engineering his way out of a terrorist cell. If 10x engineer takes a weekend to solve a problem that has stumped the team for a month, it's because he's collected the necessary context to solve the problem over the course of their long career; doesn't mean the answer didn't need to be synthesized, but they already had the raw materials in their cupboard. They have a giants' shoulder to stand on because they bothered climbing. They didn't derive anything from first principles; no one prototyped an Iron Man suit from scrap contraband.
The implication being anyone can be a 10x engineer in the right environment.
---
Allow me to carry my own throne with an anecdote, believe what you will: once upon a time, Engineering Manager had the brilliant idea to create a modular system for our main product, the pitch being that we can outsource feature development to contractors while keeping team costs down as we only need to maintain a lean modular system. They tested the idea on a couple of easy scope projects which were successful.
Then came the big test. Three projects outsourced to a team of four contractors. These projects were far more complex than the first two: lots of state management and integration with other systems. In due time deadline neared and the contractors had a very pretty UI that just needed to be wired in. I got pulled in to see the projects home. It was supposed to be easy if not for the Pareto Principle. Relationship with the contractors soon soured as they bailed, showing us that they've technically already accomplished the project on their billable hours spreadsheet. We, the regular team, just needed to deploy the code they turned in but the deployment is none of their concern apparently.
That's when I had to roll-up my sleeves, got dirty with their spaghetti code. The way I see it, the contractors fell on the part where they had to integrate with other systems because said systems were legacy, i.e., created before the idea of the Lean Modular Main System. Honestly, even I didn't know exactly how to work with them but, crucially, I knew how to get answers when the going got tough. I knew how to quickly figure out what I didn't know because as a regular employee I knew things beyond first principles.
In the end, two out of the three projects deployed. They were only a couple weeks late. IIRC the third one only failed because it really ran out of time budget. Upper Management was not happy but Engineering Manager stuck out his neck for me, for which I am genuinely grateful. I didn't get exactly the coveted 10x wording out of him but he pointed out that I released 2/3 whereas a team of four couldn't even release one.
That's not entirely accurate of course. I could code you up a decent web frontend but I could not, for the life of me, get all those pretty UI animations to work even if it's my only way out of a terrorist cell.
My issues with using agents is actually kind of similar... pushing for simpler solutions over excess complexity... I want an image zoom control, and the AI goes down a rabbit hole of complex math, JS and CSS... Why not just wrap in a div with overflow properties set and scale the actual image size? (then it does that and uses 1/10th the code, and surprise it actually works).
The more I use AI, the more I hear about overspend and rework, the more I'm absolutely convinced that the right way to use AI in coding is as a gatekeeper... babysit it, review what it does and steer it in the right direction.
A good analyst makes a hand-crafted, custom report in a day. A programmer makes a factory that makes thousands of reports per second for a thousand clients.
I am yet to find a factory at HomeGoods.
Now the kind of factories we make might change, but isn't it the fun part?
No, I don't think it's the fun part. Judging by the number of people glooming over LLMs, not many people seem excited about it.
I think of AI agents as a factory unlock too.
Anything of quality needs inspection, review, and so on before you ship it. The human in the loop step is critical for value delivery.
Many software companies don't think of themselves as factories but they ship a product to a million customers and it solves a work unit of value for each customer.
Now AI agents may eventually reach a similar potential where many kinds of work can be manufactured by an agent.
The difference I think we are saying as engineers is shipping code isn't the unit of value if you want to turn a code agent into a code factory. It's just a byproduct of the value. Code is the liability, tool, or contract to delivering the value. Poor engineering results in poor output that cannot scale or poor quality that no one wants.
Without us inspecting and reviewing the output you risk the value not being delivered. Also without us, in the past you don't have a factory to begin (although vibe coding has collapsed how soon people can setup a software factory now), scaling it takes engineering effort. We build the factory and also ensure it is operating well to deliver that value to customers.
The ability for a program for loop to do a million iterations is foundational to our knowledge. AI agents just scale that up and is one of the tools we use to get there.
I'm not scared of agents making code cheap. I just see them as another tool in the arsenal to build scalable systems now. Yes some people don't need to scale and some don't need anything of quality. That's fine and is welcomed to improving people's lives. If they want to scale or need a quality factory line they come to us to deliver that still.
I think it's myopic to think this isn't coming. But it's also short sighted to assume our value is gone at building, shipping, and operating factories.
A "Report" is just a document feature projection.
People may initially think this is in err, then think again... =3
What if for a lot of software projects out there you don't need craftsmanship but you need something closer to real engineering: "This is what a sane PostgreSQL setup and transaction management for your app looks like, this is how you do validations and the ORM layer and logging and interaction with APIs and request queueing, this is how a good front-end page looks like, here's the off-the-shelf component library you use, here's how your process errors and show toast messages and handle redirects without messing around with browser history, here's all the accessibility and mean things you DON'T do (like hijacking scroll, not having contrast, having too many animations etc.)."
You don't have a rockstar building a bridge, nor do you usually have craftsmen taking risks on innovative materials and new approaches: most of the time, you just build the damn bridge in ways that have worked for decades and have been proven. Software industry doesn't seem to know what is proven or works, cause it's a moving target. Outside of maybe niches like writing code for airplanes, completely different standards there, not sure if most devs would personally want to work in those conditions, though.
Instead on one hand you have orgs and devs that are moving too fast and create a lot of churn without nailing down what works and doesn't, on the other hand you have a lot of people (myself included) that often have to push out slop because tech stacks are a mess and you still have deadlines which don't care about any of that, and largely the state of software development seems like a comparison between Windows 9X, the UI/UX of which was at least partially based on usability studies, and the modern version which... well, you can see for yourself.
They were creating fast like AI and so mich like AI. But they were merely humans. Cleaning this slow and buggy mess took years killed many companies.
Today we have AI and industrial quantity of code without any engineering skill involved in the process
So before, you had 3-5 levels or craftsmanship to choose from, with an exponential cost increase. Now you either get to choose the dirt-cheap mass-produced stuff, the middle tier mass-produced stuff (still relative cheap), or like you stated, you're gonna have to drop $1000 on a pair of leather shoes. Full hockeystick-graph.
And sometimes the craftsmen just disappear. These days for example, it is hideously difficult to find high quality linnen.
Software has been the most disposable object in our lives since you could push a new build over the web. Builds change overnight, new versions every month with small updates. You have it backwards. Software has very little to no regulation compared to physical products and requires little to no effort to change. It has been disposable for decades at this point.
The change is large numbers of developers feel they are becoming disposable.
We will see if that is actually true if any of the AI companies can actually monetize their government cash infusions.
Small updates are in no way throwing away the entire thing. A monthly update is not a start-from-scratch redevelopment. The old version was not disposed of in the way you are trying to imply.
The vast majority of software development is based around an incremental process over time.
Disposable source code would mean you prompt the AI for every new release and throw the old code away.
The thing that creates the lemon markets is that you can't really distinguish quality until after purchase. This is extra hard with software because the average population is tech illiterate. It's even hard to distinguish when people are tech literate (and not all of HN is). Same thing with cars, most people can't tell the difference, so they buy based on price.
We kinda did this to ourselves. We pushed everything online and killed all the stores. Remember when no one would buy anything online because how risky it was? Then they created "free returns, no questions asked" and people would buy a few things and then send it back? That gave a store like feel with the convenience of home. So everyone moved online, the stores struggled to keep up, the Internet retailers kept running in the red (just like physical stores), the physical stores died, then the online sites needed to get a profit, so free returns stopped or diminished (or drove up the cost of goods. Yay arbitrage! It's like paying for credit card fees when you pay with cash \o/). So now everything is just worse.
We do similar things everywhere. We've started running the whole economy this way. By looking at it through a spreadsheet. Data is great, don't get me wrong, I'm an incredibly mathy person myself, but these are just proxies. To do good data analysis you also need to see beyond the math. To see where the proxy measurement isn't perfectly aligned with the desired measurement. How the measurement[0] can mislead you.
> "what I need for my usage"
[0] all measurements are proxies. You can't measure anything directly. No, you can't measure a meter. You can measure a comparison to a meter stick. You can measure the time of flight of a laser. You can do all sorts of things like that but everything is always a proxy. If you think this just matters for high precision, well... just look at any house.
[1] an incredibly talented third party could get you exactly to where you need but now you've just doubled the people working
Code can be like "heavy machinery", maybe needs license to operate. If an app has sensitive data in it, it becomes like a residential structure subject to building codes and inspections. I shudder to think of how this would play out it our oligarchic, anti-competitive environment though.
> stakeholders don't
[0] It's not incredibly, it's monopolies
A license to operate the code, what a trip.
To be frank, most other business units that are not tech or tech adjacent do not care about the code in the slightest, or the maintenance / security / durability of said code. It’s a tough world to live in. We understand the value of good code, maintainable systems, and proper design across the board. Relaying that to leadership who does not see the value is time wasted.
“What do you mean we need to rewrite it to adhere to engineering spec? It already works. Just deploy it to production”.
I don’t think we’ll ever be treated as engineers. We just had a non-technical person spin up a vibe-app that is now in production, real (measured, methodical, secure, spec driven, efficient) development is actively being devalued at my company and probably across the board…
Rant over. You propose a good solution I just can’t envision a future like this, there’s too much value in “barely good enough”, but perhaps the ramifications of that will eventually bring about your proposed future!
Arguably they are even more willing to cut corners though. Nothing by IBM or SAP should be considered "crafted", yet those companies have a strong place in the world of business today.
Then we go back to the old “the prototype works; I’m the boss and I’m telling you to deploy it to production”
The prototypers, who move fast and break things, who throw together shiny first versions that look great and work some of the time;
The architects, who take the prototypes and take the time to build it correctly;
And the gardeners, who maintain the built system for the next 10-30 years, fixing bugs, making incremental improvements to speed or resource usage, and updating dependencies so that it continues to function on modern machines.
The crazy thing is that there are a ton of developers with different tastes who would love to fill each of the roles, but not many companies that are able to manage all three types without pushing everyone into one bucket.
Worse, often you need to spend years before you realize how an initial design decision was a mistake - not only are you proposing to throw away millions of dollars worth of work - you also don't know that your proposed better design is really better.
I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a process, the quality of code/architecture matters little if the low bar of functionality is met. Functionality can be sold to customers or used to test the market. It’s basically the whole MVP thing and the MVP should be a bit jank. If it wasn’t, you spent too much time/effort on it.
All said, there’s definitely some approaches to make it less jank from day one. Unfortunately, jankiness is a subjective metric.
Product Managers coding is like Developers writing marketing pitches.
Like they actually iterate on the UX alot when they are vibecoding things up, answer alot of questions that can onky be answered when you see an initial version of experience and realize something is off. Id rather they waste the clankers time with that than mine
One of my faults is "When somebody tries to explain something I hear 'A' and everyone else in the room hears 'B'". And vice-versa. But if someone can iterate a very VERY rough cut of what they want and hand it off to a design / development team ... well ... damn. That might make everyone's life a lot easier.
You're saying even that bit doesn't require them.
I work in IR for small to medium sized business. The past few years have seen my business increase well beyond what I can reasonably handle and my bank account feels like a dragons pile of gold.
I will always always be on the side of security should be integrated and planned for and by no means do I want to see breaches.
That being said giving people of dubious expertise the ability to blast out an app in an hour has been an absolute windfall for me and others.
When clients come to you, is that because they always intended to get help taking their system to production? Or is it a last resort after all the AI approaches fail?
Is there a general way that these projects break down? Or are the failures usually subtle?
Yes, there's probably a market for vibe-coded software, but if there is, then there's also a market for fixing other companies' vibe-coded mistakes...
Phrased another way, you pay company A to vibe-code some software or extra software features for you, then you subsequently pay company B -- to fix company A's vibe-coded mistakes!
(Hey, look on the bright side! It's more money for taxes, GDP, employment ("jobs jobs jobs!"), and the circular Internet economy! :-) )
Yes indeed, because macroeconomics is ultimately a giant circle!
If you're a reasonably talented developers, I think there will be money to be made picking up projects left behind by coding agents. Maybe you'll use AI tools to do this, maybe you charge to migrate to other platforms and maybe you are paid to simply do bugfixes.
Every single contractor will say: that never happens when I do it...
This is a better solution for many businesses.
One, they already have a steaming pile of crap that kind of works. Forking that over to someone to "fix" for €10-50k is a steal - even if there's a decent chance they deliver nothing valuable.
You're talking about on the low end a few weeks of a dev's salary. You get next to nothing for that most of the time...
You could easily spend 4-5x that, take 3-4x longer and get something you can't use at all.
Happens all the time.
The anti-LLM propaganda is getting ridiculous at this point. No project "needs 10GB" to compile, unless you're working with astronomically massive repos, and _no_ LLM will _ever_ generate that. Lint errors (depending on cause) are either meaningless or a result of poor prompt engineering. If you want your project linted/formatted a certain way make it clear to the LLM.
Most people have no clue what that means. Most Devs should know but I would wager that newer devs don't have enough opinion or exposure to do that.
This story doesn’t add up.
Ive had ai make code that doesn't pass a linter and make code look like hand aligned code.
> _no_ LLM will _ever_ generate that
Did you even read the post? Seems you are being overly hostile, defensive and dismissive. Honestly, you sound like an astroturfer to me. I'm curious to check your history to see if you match the vibe.
Do you have any idea, even before modern LLMs, how much code out there was just given more memory instead of optimized? There are even good reasons for it (it can be cheaper than having devs spend time if there's more productive work to be had).
It can be very easy if said code needs to parse through gobs of data.
You've never tried to compile NextJS slop, have you? It absolutely can take that much. All those junkdevs have 64GB in their MBPs for a reason. NodeJS max heap is now dynamic because of this.
And 2) There's the people who it's painfully forefront of mind that they're smarter than most everyone around them. Some of them are jerks, some of them are exhausted by being surrounded by relatively "stupid" (again, relatively...) people. For the latter group i have some sympathy. Imagine walking through life and everything is clear, obvious, easy to process and having to watch humanity make stupid choices over and over and over again when the answers have been long known...
I don’t claim to be book smart or have a high IQ or whatever but I feel this way about small things that I feel are common sense. It’s maddening to me to watch people fumble around. Or do X when obviously it will result in -Y a bad thing. I really have learned to just not vocalize it, most of the time. It’s especially unhealthy for my close family relationships as I just see so much of it that I could nag them to death.
I'm still not sure how to deal with people being not only wrong but either too dumb or too arrogant to change how wrong they are. (Which is of course me being wrong and unable to change…)
Just the other day I was watching a video on youtube, of someone absolutely struggling at a task that had a built-in checklist, verification steps, pictures, and basically (in my opinion) perfect guidance. This is something where, if I was doing it, I would just... do the steps. in order. and it would work, probably... 99.9% of the time, the first time, and relatively quickly, to boot.
I watched them fail to succeed like... 5 times in a row. At no point did they actually complete all the steps and verification in order. And this was a reasonable, intelligent, thoughtful, thorough person. They just could not follow a checklist, visual or written instructions, probably to literally save their life.
This sounds like Bog who records himself setting up Linux distros or configuring software
my wife and i have two non-overlapping sets haha you can imagine how that plays out
Yesterday she literally failed miserably at a single task. Her mission was grocery shopping. She drove to grocery store, shopped, and came home and left the groceries in the car. Didn’t realize it until she was making breakfast the next morning and there was no milk.
I see this two ways; 1) I would never make that mistake 2) I know her quite well, partners for over 20 years now, and this kind of thing is just her normal par for the course type of “oops”. The second part is what frustrates me the most, I like to learn from my mistakes and she treats it as a given that she’s just spacey/dimwit by nature and leans into everything being an “accident”. Obviously not healthy if I treat her like a child so I just watch her fumble through life and try to have a sense of humor about it all.
If she's unsure, it's worth looking into. The immediate relief available by way of the strategies that documentation on the disorder provides can be life-changing and don't require medication nor therapy in order to be put to use.
I somehow suffer from both simultaneously!
However... NONE were "the 10x developer" who built up a huge mess. Which a team and I had to spend months and months cleaning up after.
The first is that you aren't as smart as you think you are, because if you actually understood the people around you in any real way, you would instantly find them less frustrating. But instead you are using flawed heuristics, built out of your own insecurities, to interact with the world.
Possibility two is that you are smart, but you have developed a malformed coping mechanism whereby you take all your negative traits (social ineptness, anxiety, impatience) and treat them all as simple the nature outgrowth of your prodigious intelligence. This is a common coping mechanism, and the neat thing is, it has nothing to do with intelligence. You can be dumb as a brick and still feel like you're in a world of morons who are inferior to you.
In fact, I suspect these two explanations are one explanation.
Personally, if I had to choose between a world of people with "low IQ" who are self-aware and one of people with "high IQ" or are extremely un-selfaware, I would choose the former every time.
Many devs choose to just do their day job or decide to follow a cargo cult.
Probably not every dev can have the same output, but if you decide to keep thinking beyond what is the cultural average, then everyone could be smart in their own way.
Most people don't realize they can do that.
> The flow of data was so hard to follow, it seemed like someone was trying to cover up a murder.
> Just getting the code to run on your laptop took a week.
I always thought I’m the only one having problem understanding the data flow, or setting up a proper dev environment. Impostor syndrome (and sometimes toxic environments that pushed for “velocity”) didn’t help either.
Felt good to know I’m not the one.
This one surprised me. Claude Code in the CLI has made standing up an app and debugging whatever random dependencies or docker BS a dream compared to the before times, when you'd have to learn the architecture while simultaneously troubleshooting whatever isn't working on your machine
I can remember a time when learning was valued and leaving the camp cleaner than you found it was considered a basic professional standard.
But I can also remember a time when Scrum became all the rage and next thing you know we’re all stuck on the sprinting treadmill, management is obsessing over “velocity”, and it’s generally an everyone-for-themself free-for-all to clear the absolute minimum criteria to get the ticket moved to the “done” column in a semi-desperate effort to keep up with your ever-growing backlog of tickets to which you’ve been over committed. Don’t worry about incomprehensible code or flaky designs; taking your time to do it right the first time looks bad on the KPI dashboard but rework does the opposite because you get to count the second (third, fourth, etc.) times the same task needs to be revisited towards your velocity metrics, too.
I’m not sure most developers younger than maybe 40 realize just how much worse our line of work has become over the past ~15 years.
It might have been you, a couple of months later, or someone else. I have dealt with slop produced by unknowing programmers most of my career. With this vibe coding I think my job is still safe. The amount, though, is increasing exponentially.
My current job is genuinely just boring. It's tasks that are so simple, a junior could do it. But no, instead they needed a medior. I'm not saying I'm better than this, nor that no medior will pick it up. I just cannot push myself to care about the code this company makes. It's old, dusty and it serves no one of importance. These customers use it because they once bought the tool and do not care enough to switch, because the tool in question is not interesting.
I was promised work soon that aligned more with my experience, but I do not foresee these customers to come to a stale company like this.
It's not surprising that this company is losing customers, employees, etc. But I have a mortgage to pay. Today I had the conversation about how they might not extend my contract, basically threatening me to take more ownership, do more work, for the same pay. Sadly I have to make it last until I find a new position that is actually interesting. I don't even need a lot of money, I could give a rat's ass about "growing". I just need enough to survive.
This might be a very unrelated comment, in which I apologize. I just do not have another vent to post this to.
I didn’t have any major financial obligations like you though, so it was a much simpler decision for me.
Hang in there buddy and also thanks for the deeply human comment.
Maybe the problem is imagining that you need sixty three levels of granularity to describe experience or to establish superiority over sixty two categories of "lesser" engineers?
The point I made was that as an SSE (L63), there’s a certain amount of scope and autonomy that is expected neither of which I was getting and hence I resigned. I am not trying to bully or denigrate anyone junior.
The levelling system specifies the output and the characteristics of the output expected out of an engineer, that’s it. Whether I believe in it or not is beside the point, I was in the system so I did believe it otherwise progressing through my career would have been impossible.
I can very much relate.
Garbage products, by garbage companies, feeding on the laziness and tastelessness of most, as it's being capitalized by marketers.
And now, to make the matter worse - it's all being 100x by the LLMinazation of the entire field. Making code unmaintainable. And worse, making us all dumber.
I really wish we never have stumbled upon it.
I am a bit curious here. Does that simply mean to should to extra hours and do bullshit duties or is there actually more coding work opportunities? Or do they expect that you should prove more valuable out of nowhere?
I don't want to downplay your experience. In the latter cases, I wonder if you can actually do something.
What I'm getting at is if you'd like to find a stable place to vent about some shit without worrying about some assholes scraping it, I'd gladly share an email and a PGP key with you. If there's one thing I'm quite good at, it is minding my own business. That extends to the handling of other's business.
Have a good one.
Since then I’ve slowed down. It’s been an overall positive change for my life. Being a team player unfortunately won’t give you the same kind of upward mobility in this crazy industry, but it’s done amazing things for my mental health.
You can always abstract later, but once you start it’s terribly difficult to reverse.
It's a pity that the article ends cautiously with recommending to perhaps adapt AI usage practices. In this climate we are not there yet to publish the unfiltered opinion that generative AI is garbage and should be disposed of. Soon we will be.
As for the AI code, the most defining elements are unneeded complexity and low understanding of the abstraction involved. When you need a 10 lines functions, the AI will happily write an entire module because that’s how a fully implemented domain is like. But it’s not part of the requirements. As for the low understanding, you will see strange code, which are not fully antipattern, but are definitely not needed as it solves issue that the platform/library/framework doesn’t have or already have a solution for.
I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
I have found that a lot of the "massive amounts of bad code" left behind by "rockstar developers" is actually just a long slow drip of added complexity in the face of changing requirements. and I find that people think they're "refactoring the code for readability" when a lot of times, they are actually just "rewriting the code and therefore understanding it in that process".
I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.
For me the article is about programmer culture and work ethics, it's hard to discuss with hard facts. Yet sharing this personal experience is valuable.
There's a big difference between the two and LLMs are increasing the chasm. The Software devs are crying out because the LLMs can already do their full job. Software engineers are happy because the LLMs are removing a large chunk of the job that's low value.
Software dev using an LLM is gonna produce "slop"
Software engineer using an LLM is going to have an increase in productivity depending on how they're using the LLM tools.
Even if so, dev or engineer, both can be low or high skill. Their job title doesn't tell how sloppy or good their LLM usage will be.
At least that's my takeaway here.
The chasm between "Software Developer" and "Software Engineer" is getting wider. Articles like this and the comments under it give away who is an Engineer and who is just a coder.
If I had AI tooling at the time I'd probably be more inclined to have it both refactor / optimize the existing application, add automated regression tests etc, and use it to extract all of the features and requirements for it for a potential rebuild.
But honestly I think if that application was properly designed and factored (instead of nesting JS in HTML in strings in JS or concatenating XML from query results only for it to be converted to JSON taking up 50% of response time) its lifetime could've been extended, especially if it was then containerized into a HHVM or similar php optimizer.
But, hindsight.
One of my particular complaints is how code-gen LLMs tend to re-create the same code over and over again. Case in point, a use-case where a team name is generated from a list of team member names. The LLM re-generates this code in-line every time it needs to display the team name, rather than simply writing and reusing a utility style function.
I know I need to fix this. At this point I'm planning to just prompt something like "please list all the places where team names are generated/calculated", plus manually search through the codebase, then perform the abstraction myself. But I'm unsure how to prevent this (both this example, and other cases that could benefit from similar utility functions) continuing to occur in the future.
We had one on our team in the past.
A bunch of microservices built on an in-house RPC framework he wrote, RabbitMQ, half-baked "monads" in an OOP language, esoteric naming, and no comments (the code should be self-documenting!), no docs.
Management adored him.
Once we started to grow, the problems started to appear: bad orchestration, uninformative logs full of PII, poor error handling, edge cases that were nearly impossible to fix within the existing abstractions, dependency hell, etc.
At that point, he moved on.
It took years and many hundreds of pull requests to clean it up.
You could optimize for different things. Code understandability by the team, speed, technical brilliance.
If you optimize for technical brilliance but nobody else on the team understands the code its still a failure.
Seen over engineered code
However, as always, AI usage is a matter of taste. Including your style rules in the prompt matters. Introduce new paradigms/tools/code into the main codebase because they solve a business problem, not because they are technically interesting. Careful development does not break 7 things to introduce one new feature, etc.
It's really that simple.
> Then you add an agent that goes through the code and simplifies it
Can you? I just asked Opus to generate a sum function.
def sum(a, b):
return a + b
add = lambda a, b: a + b
If you ask it to simplify something, it will make changes whether it needs to or not. Now imagine we were working with a function that is a couple hundred lines. What changes would it make?
The reason something superfluous was written to begin with is because an LLM does not always know what is superfluous. Producing and reading is really cheap for the LLM, so it doesn't have the same considerations we do in writing code. It's more willing to reinvent the wheel or write something that is way more verbose than it needs to be.
In practice, asking an LLM to simplify it just means it adds a different superfluous thing. Or it refactors things that didn't need to be refactored (because it can do it quickly). The result is LLM code, even if it's good, tends to bloat a bit. Multiply that across 100 people all vibe coding and not reading the code base, and soon you have an unreadable mess.
This is an utterly terrible idea.
I'm reconciling with the fact, that, if I let AI write a bunch of code, I have to depend on that AI to maintain it.
I just spent the last week, hunting down memory issues in the app I'm writing. I had a lot of help from an LLM. It rewrote most of the view controller that implements the map screen. That view controller is now 4,000 lines long (but half of that is comments), but it works extremely well. It took many context resets and rewrites to get here.
I would not have done it that way, but then, I probably also wouldn't have fixed the issue. The issue was really in Apple's MapKit, and I needed to do some gymnastics, to keep it from jetsaming my app. It's not particularly good code; but it works.
I've made the difficult choice to leave the sloppy view controller in the project, with the option of completely ripping it out, in the future, and replacing it with less "intense" code. It's pretty much "firewalled." It won't be that difficult to do it, assuming I have the bandwidth (and Apple finally fixes the memory hog issue, which seems to have been around for a long time).
There's all kinds of options that I could have (and still can) explore, but I feel that this is the best one.
But this article is absolutely correct. I think we will have a "slopocalypse," when it comes time to pay the piper for the thousands of vibe-coded applications that are certain to be authored in the next couple of years.
Then there's important code, like business logic, security related stuff and such. For that I'll happily use AI to brainstorm ideas and avenues, do code reviews where I'm prepared for it to be wrong and help with library suggestions etc, but where I want to write the code myself so I understand what's going on.
We'll see how it changes, been a wild ride so far.
I've made a few internal web browser-based tools recently, and I let Codex and Claude handle the entire frontend. Don't really care about the details there.
Tool is not exposed to the internet and they had limited scope. I handled the important details on the backend myself, and I reviewed the integration tests carefully.
These tools would just simply not been made without Claude and Codex.
YMMV as they say.
I know of several projects I've worked on that are alive well over a decade later, and some of which I've heard feedback on even recently. Very little of it excessively negative.
It's been an uphill battle though, especially having worked in a lot of C#/.Net shops, where Enterprise Patterns are often adopted when not necessary or prudent. There's also a balance between new tooling and what's working/known already.
Of course, I'll probably never get hired again anywhere so it doesn't matter anymore.
Completing each individual programming task is easy. Engineering the system in a sustainable way that changes can be traced, understood and reasoned about is difficult.
The problem is, as many other comments have pointed out, typically the business doesn't value this.
Archiet also ships with the right architecture documentation, without the right architecture or specs-driven documentation, AI rockstars need clean up.
The author already describes himself as "not a rockstar developer", but if this is the definition of "rockstar" I need to recalibrate.
Being able to learn new languages and libraries, to me, is completely normal.
(Also: how funny is it to suggest rewriting code you self-admit you can't even read.)
I've never heard of this guy. He's "self employed"
The article lacks any real detail and it just a guy patting himself on the back.
I don’t understand why all this stuff is all of a sudden “new.”
It feels like we’ve got an entire generation of people who never had to spend their time factoring or doing hard infrastructure work
It’s actually pretty baffling how rare it is to find somebody who has consistent experience in refactoring that is under the age of 40
I even had a PE buy the company I worked at, put in a new CEO, and his goal was to rewrite the entire code base in a year. I asked him what problems this would solve and never got a straight answer besides "its yucky" and "people told me they dont like it."
I have had multiple upper management teams decide that "dealing with this product is too hard, let's start from scratch" as if the new thing wouldn't have the same problems of the old thing, but with less effort put into it.
People love to work on new, all the possibilities and none of the bugs!(yet)
Getting product to prioritize refactoring a working product is like pulling teeth. Even if maintenance is a moderate drain on resources, work beyond maintenance on working solutions isn’t seen as a net win.
1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.
2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.
3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.
What’s “new” is indeed the “new” bit in cleaning up new projects.
"Software Engineers" are embracing LLMs and getting shit done same as before.
Current AI coding is certainly very lacking in the craftsmanship department. But it is not obvious to me that that will always be the case. I don't think there's some fundamental reason AI could never produce code that matches or exceeds the craftsmanship of human experts.
In the UK we call it 'Belt and Braces'
At least not the rockstars I had the pleasure of working with.
AI tools are producing code on behalf of a developer. If that developer is fine putting their name on code that they don’t understand, applied to a code base they also don’t fully understand then you have a very human problem. The technology just magnifies this.
This cascades of short sentences are a giveaway.
It reminds me a little of when Hegseth wrote "we're clean on opsec" in a message thread with confidential military information that he accidentally sent to a journalist. It seems like role playing/fantasy fulfilment for certain personalities. I struggle not to hold some contempt for people like this, who are making life difficult for everyone for their own petty reasons. I can sympathize when it's simple ignorance, but the ego chasing really is inexcusable and needs to be called out more.
Yes, yes you can, but you can't force the LLM user to _understand_ your feedback so that they reduce the burden on you, as the reviewer.
> It's more expensive to fix code at runtime than at compile time and at compile time than at design time. Unfortunately, AI rushes people to runtime as fast as possible.
https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...
Perhaps I should start trolling people that your software is not truly Open Source if it's not Open Prompt.
If management and teams would instead value highly elegant code structures over lots of "spewed out" code lines "that (superficially) implement a feature", I would bet that the problem discussed in the article would be much less of an issue.
Nah. Now everyone can build single purpose, single use, throw away software.
Somebody wake me up when the ABET SWE PE is back.
Much needed right now as I slept only two hours since yesterday after solving a SEV-0 and having to wake up after a 2 hour nap, so I could be now cleaning up the fallout before business hours.
I am not a AI-denier, I am actually thankful I have AI right now to multiply my force, but frankly, people STILL need to review that fucking code, and the people who review the fucking code STILL need to be good enough to be able to write it themselves if they needed.
Whoever says otherwise is either an AI investor, a linkedin influencer or a complete imbecile.
--- EDIT
Please add a section on how to communicate and write a post mortem where the guilty is completely exhonerated without the blame falling on me as I try to save said manager's face.
It’s actually not much different than a decade ago cleaning up somebody else’s giant Visual Basic or PHP spaghetti code that stuck on the wall
Why are you allowing AI rockstar managers to (I assume) push without code review? Why are you cleaning up the fallout? It's not AI issue, it's people issue
In reality, sometimes I wonder if there is really anything beyond perceptions.
The basic workflow adopted by our manager was thus:
1. Discover a bug or get a feature request
2. Pass the task to the development team verbally
3. Developers prioritize tasks based on which ones are more likely to be forgotten by management
4. Approx 20% of tasks get completed
5. Repeat step 1
Basically our superstar developer absolutely allowed our non-technical management to commit software development seppuku. His successes were highly visible, but his failures were not:
1. Clobbering other developer's commits because he didn't know how to use git to rebase or merge changes
2. Copy pasting (not forking) entire codebases to work on a new feature that then got so bloated they were impossible to merge
3. Absolutely no documentation of any sort, not even comments.
4. No automated testing of any sort on any of his code even though there was an effort by the rest of the team to do better testing.
5. Refusal to use the common Docker development platform everyone else had standardized on, many times his code only worked on his machine.
6. He wouldn't fix bugs, he would just re-write the core logic of the feature that had the bug and then he wouldn't bother to remove the old logic.
7. Regular, daily code dumps of 1000-2000 LOC that contained new features that were not discussed by the team, sometimes from casual conversations with a sales person, sometimes completely made up by him out of boredom I guess.
8. Our Linux BSP was stuck in Amber because the only copy of it was on his local machine (allegedly). When asked many many times by the rest of the team to get it in our company repo he would check in something that did not compile and was not even remotely close to what was being used on our boards.
9. Instead of adding dependencies where needed he would take a 3rd party library, chop it up and copy-paste it into our code directly (see point 8).
10. Last but not least just general slop code with 15-20 levels of indentation, no modularity, dirty hacks everywhere.
The problem is that this approach implements features quickly but in a way that conflicts with the team's mental model, ultimately ruining the entire codebase.
A lot of blog posts initially framed this as a problem. I agreed to some extent.
But as I've gained more programming experience, I've come to realize that all programs degrade over time until they are reborn. Eventually, it seems that destructive innovation is necessary for longevity. And sometimes, new patterns emerge from that kind of disruptive feature development.
So you could say that AI rockstar developers and AI-driven development are close to being a "tactical tornado" because their codebases are bad, with poor maintainability and reliability.
Maintainable development, in my experience as a traveling contract developer, usually refers to code that is well-modularized and well-crafted, making it easy for someone like me to understand the codebase when I come on board. But when I saw the leaked Claude code, frankly, the code quality was disappointing—yet by my standards, it worked very well.
So I've changed my mind lately. I think we actually need a new classification of developer types: those who love creating new things but are bad at maintenance, versus those who are conservative, good at maintenance, and build beautiful code.
What makes me think not too badly of recent AI-Rockstar(or AI vibe)developers is that as any industry becomes more advanced, it becomes harder for stars to emerge. Work gets divided and specialized, and no single individual can master everything. For example, I'm confident in writing 60,000–90,000 lines of code by combining frameworks based on IoC (Inversion of Control). But I'm weak at large-scale programming like distributed systems or low-level programming. That's the difference in expertise. I'm strong at the macro level but weak at the micro level. You become cognitively optimized for your own domain.
vibe coding developers(or AI star developer)since AI is still far from being highly advanced—produce messy code, but they definitely bring a new kind of shock. And when you look at their internal structure, many developers mock them. This reminds me of Undertale. Undertale's code is full of if statements and an enormous number of branches—honestly, it seemed like the developer didn't even know the basics of coding. Yet that game became a historic success. The same goes for programming. Some people make the code components beautiful and efficient, while others focus on delivering what the end consumer wants.
So these days, I even think that the more AI developers create bad software using AI, the more new jobs will emerge to maintain that software. Everything always has two sides, it seems.
And in a way, maintainability means knowing how that feature fits into the overall shape and UX of the product. With new products, that prediction is often impossible
> As you waded through the slop, you browsed job postings and fantasized about leaving
Just because you didn't understand something or haven't heard about a library, doesn't mean its slop. How do you make sure your definition of "clean code" is not a slop to others?
As I was leaving my last job, I advocated everyone migrate from plain old es6 to typescript, b/c several times broken builds made it to production.
Certainly my coworkers may of felt upset that typescript is too verbose and pointless if everyone reaches for the "any" operator. But that doesn't mean the decision to move to Typescript was bad, it just means the company is "old school" and not willing to take the time to adopt modern workflows...
There is no such thing as technical debt in the age of AI. It's just a series of migrations that take minutes to come up with.
I migrated from two disparate databases using AI and it took minutes for it to write the migration code. I had it double-write the data, and then I told the AI to write code to compare between the two databases, and I then tested over the course of a week.. I fixed some small bugs, or more precisely I told the AI to fix the bugs and it did.
Then once I was satisfied, I switched it so that the new database was primary and the previous database was secondary. Then I tested to make sure the data was still in sync. Then I switched off the previous database, then I removed all traces of the previous code.
It was simple and relatively quick. The thought that there exists technical debt in this age is absurd. One person can do things an entire team used to take in a fraction of the time.
Producing new technical debt quickly doesn't mean there's no more technical debt.