> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.
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.
Craftsmanship is not dead in other industries in the same way it is being talked about for software.
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.
Definitely. Expert craftsmanship in cost optimization, in shipping optimization, in production/factory design and optimization, in material sourcing, in durability testing, in design for mass market appeal, in marketing material, in documentation, et cetera.
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.
Some programming is the equivalent to designing a factory, some programming is the equivalent to 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.
I'm not sure why this even needs to be the comparison?
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.
Physical industries are very different than software. Leather shoes are made many times, 1x per customer. Code is created once, using the same product for all customers. This gives a lot more leverage on investing in a quality product.
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.
That's wholly the wrong perspective. The equivalent of "craftsmanship" in software would be how the shoe is designed, not its manufacturing. Software developers produce unique intellectual property. They don't manufacture units of software. Similar to book authors or musicians (not on tour).
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.
There's a really interesting angle here from machining.
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.
If you've ever watched an episode of "How It's Made" and seen how incredibly customized these machines are, it won't be surprising that the people who build them are proud of their work.
I'm not sure that I completely agree... my longest lived apps are the ones that were built with a KISS to the extreme mindset... make it as simple as possible and easy to replace as can be. Then it just lives forever.
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.
Thought experiment: would a junior developer armed with a modern day gpt-5.5 or opus 4.8 in 2015 would have been considered a 10x developer (assuming nobody knew they were using AI)?
If you want to play games like that, you could also flip it around and ask if the AI would have been eventually fired (assuming no one knew they were talking to a computer).
The 10x developer never existed. You're telling me these people are doing a year's worth of work in 1.2 months? Seriously?! 10x?! In a year you can probably learn to program from scratch and participle if you're working 8hrs per day 5 days a week
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.
Of course they do. Have you literally never run into a problem that the average developer can not solve, but a expert can solve? That is infinity times more productive.
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?
In what time frame?
> Even assuming that maybe the average developer could come to learn ... already knowing how to solve it on short notice being over 10x.
10x? I'm not convinced. 10x is a pretty big increase, as illustrated above.
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?
It doesn't mean more work it often means creativity.
For example when I was an EE I worked at a company that had spent nearly 8 months, 50k on consultants, and easily 3 peoples full time for a lot of effort plus the testing side.
I swapped that 800$ board out for essentially a lightbulb. Did identical work <50$ and was more reliable. That simple change was easily a 10x improvement if not more because the logistics of that one board was absurd.
I'm proud of that EE work but code is identical. I would never call myself a 10x developer but I've wiped entire code bases more than once.
Maybe I have "10x" moments? But to say this isn't a real phenomenon means you're in a super structured and political enviroment.
I probably had that kind of 10x moment yesterday. I spent 2.5 hours analysing a feature request and I eventually advised my customer to think very carefully about it: it might solve a problem but the implementation time is going to be long, even with an AI, because of actual development and the time we will spend in testing it. Furthermore the new infrastructure will have recurring costs higher than what it saves. My advice is not to proceed. 2.5 hours vs 25 or more. 10x.
My point is that these 10x moments aren't sustained. When we're talking about a "10xer" we're talking about someone over a longer period of time.
For "in the moment"s and short term projects, 10xers certainly exist. There's definitely things I can do in a week that would take juniors more than 10. But for bigger projects? Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years? I'd really doubt the latter and the amount of things I can do in a month that a junior can't do in 10 are a whole lot smaller than what I can do in a week that they can't do in 10
> Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years?
I briefly worked at an organisation where I was consistently and sustainably able to ship in two month blocks what other teams of 3-6 engineers at that organisation could not successfully deliver at all. I would consider myself around 75th percentile productive compared to the industry, but in that specific organisation I was at least 10x as productive as the median engineer - regardless of their seniority.
I think engineers tend to form clusters where everyone is roughly as intelligent/competent/productive as each other. Outliers tend not to join the cluster, or they leave quickly. I've seen this happen at the level of a company, but also in larger engineering orgs at the level of a team or group. High performers don't stick around when their median colleague is a low performer and vice versa.
Perhaps you've had the good fortune to work mainly in organisations with a high competency floor. Looking around, you may not see anyone who's 10x as productive as anyone else, but maybe you're ignoring that everyone is in the 90th percentile of the industry.
Once was part of a team where a mid level guy spent a year building/heavy maintenance of some catastrophe of a solution. They literally had the end users copy and pasting hundreds of commands from a generated excel sheet of a command per core (shudders). I spent ~2wks on a different architecture that was a massive improvement we abandoned their code base. He quit like 4 months later to join some faang. Granted that 2wks of work was on top of a distributed cloud infra that took me 6 months to build.
So yes, a skilled dev might skip entire months of work someone else would make.
What you seem to be describing is a companies skilled engineer designs something and passes down the spec. The guy making the spec is the 10x guy. For large projects it's even more pronounced. The article literally described someone who wasn't skilled they simply knew how to smooze the MBA's and a company with poor engineering leadership.
> a problem that the average developer can not solve, but a expert can solve?
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.
I think the myth/claim of a 10x developer is true but only relative to said rockstar engineer's immediate environment.
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.
> the 10x developer is a 10x because they've spent ~10x more time immersed in the problem domain than the average developer.
Your ratio is off. This doesn't grow linearly, it grows exponentially. It probably takes more than 10x the experience/time to get to 2x in performance.
> If 10x engineer takes a weekend to solve a problem that has stumped the team for a month
This is very rare in the real world. There are also alternative explanations you're ignoring:
1. Luck. Seriously, do not underestimate luck, it plays a major role in your life[0]
2. Fresh eyes: You're not burdened with all the noise of the past engineering[1]
3. Getting to leverage the existing work. You have a new prior, you know to not think through the problem like the rest of the team has been.
Those are two obvious explanations but there are more. The reality is that it is going to be some combination along with the experience that you suggested.
> I didn't get exactly the coveted 10x wording out of him
I do not want to imply in the least that you shouldn't be proud of your accomplishments. You absolutely should! But is this "10x" or actually smaller? A few weeks late you said, so how long do you think it would have taken had you not been so skilled? 20 weeks? More? If it really would have taken 20 weeks then yes, you are a 10xer and call me wildly impressed.
But mind you, I'm also saying that being a "2xer" is wildly impressive. I'm even saying that being a 1.1xer is impressive (because it is!). So I'm really not trying to diminish your accomplishments. The feeling of pride you should have for your accomplishments shouldn't be diminished because you aren't calling yourself a "10xer". That's not what's being said here.
Plus, my whole point is about sustained output. 10x and even 100x certainly exist in short tasks. I mean I can certainly produce a hello world program in python 100x faster than someone that doesn't know how to program. But over longer periods of time this gets to be much harder. Again, I don't want to diminish your pride, the story you explained is not a short task.
[0] That isn't to say that skill doesn't matter, it very much does. But luck is pretty far up there. It is behind skill in importance, but there's not a single (or even 2) factor that controls your life.
[1] This isn't luck, you can control this too. Stuck on a problem? Walk away. Go for a walk. But come back.
The research referenced in Fred Brook's The Mythical Man Month found that there was a 10x difference in programming task completion time between the FASTEST and the SLOWEST developers, but only a ~2.5x increase from the median to the fastest.
This! I've worked with a few developers I would consider net negative to their team and product, in that their removal would have increased 3-4 other team members productivity by say 20% each. Coincidently these developers were almost exclusively Indian immigrants. In organisation with poor corporate culture and the ZIRP (Zero Interest Rate Policy) days of hiring to signal growth and managers hiring to increase the number of reports (to signal importance) compounded the problem
No. I experienced this firsthand. Brought on a on level dev who was using Ai. Created slop, when asked how it works, he just said “it’s all in the documentation” Lots of good documentation, but that’s bot what I needed. I needed an engineer that understood and knew what he created.
I’m no longer at that org.
What really sucks about mass production is that it inevitably kills the middle tier of craftsmanship, whilst doing nothing to offer something of similar quality.
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 engineers are not artists nor shoemakers. They are factory makers.
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?
It is definitely the fun part to me and scaling a factory is the challenge we all decide every day we write code.
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.
> In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives.
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.
I still remember times when my work was mostly cleaning and refactoring old code written just to have higher LOC by devs from India paid in cents per line.
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
"software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are"
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.
> Builds change overnight, new versions every month with small updates.
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.
I don't think craftsmanship is dead, but I do think we've built a lemon economy.
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"
I hate how prolific this saying is. You can't know that you have all you need for your use case without first knowing more than you need. It's not something you asymptotically approach, you *have* to surpass it[1]. Without going beyond you, with no doubt, are just setting yourself up to live with unknown unknowns. It's absolute insanity that we say this bullshit with a smug look like we've discovered something profoundly intelligent.
[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
Craftsmanship does not have to die to have millions of software-engineering jobs displaced, right? I assume when people worry about the craftsmanship, they worry about that enough number of people would lose their jobs because AI coding has becomes sufficiently good.
Yeah, even though I like 'craftsmanship' here, stakeholders don't. I think "durability" is pretty good. 'Engineering standards' perhaps. I think we'll start to see the groundwork laid for software engineering as a proper engineering field, where specific performance characteristics are required for certain stakes.
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.
Because why would they? Most stakeholders don't have long term incentives, only short term. So the incentive is to buy low, cut corners, sell high. What's more incredible[0] is that the aggregation of this somehow makes long term growth.
Hah. What a dream. Instead they’ll hire a team of what is essentially interns and have them deploy mass amounts of minuscule features with 0 guidance because, “hey - it’s cheap as hell and does 75% of what it’s supposed to do.”
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!
> but anything built around long running business processes should not be treated in that way.
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.
I like fixing code made by AIs and others (outsourcing code is similar as someone else said already). Last week we found out some client tried to vibe some departmental tool; the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on. Now we have to fix it: its basically free 10k-50k euros over and over again for this type of work. Very easy if you know what you are doing; impossible if you don't. Keep m coming.
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.
Ha, I'm a gardener then, on my 15th year of maintenance. So halfway there according to you. Slowly, very slowly, fixing the thousands of bugs the rockstar left behind 15 years ago.
It's easy to look at a newly made garden, its flowers all freshly planted and its paths all neatly laid out, and think it finished, but once you see one that's been carefully maintained for decades and how its plants have matured and grown together and how the steps have been worn by human feet, it's clear the project is merely off to a good start.
This comment made me imagine what would the guy maintaining my first deployed project at my first company thinks about me. Never had this thought ever cross my mind.
The problem is those shoddy foundations can support a lot of weight before they finally fail. A prototype you write in a day - not a big deal to throw away. However if you have been working for a while that is a lot of effort/money.
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.
More than half the time it is correct - until you figure out those things you are asking to focus on you won't know what really works. Going for ideal now just means when you get to those things you discover another thing you hadn't thought of in advance and so you are no better off.
Experienced developers in a domain can sometimes anticipate the issues, but experience only comes from failing.
The real answer is allowing some budget to fix things and then fixing them as you go along.
Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame.
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.
It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code.
If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
> If you have a good architecture and keep good code hygiene
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.
Then redesign the architecture. No need to go for a full rewrite as it can be done progressively. One thing I’ve seen is that people can be afraid to delete code, even if it’s not used anywhere.
> You will never get the chance of "customers requesting changes" if you never ship.
Why does good code imply never shipping?
Managers and Developers have different thresholds for “good enough to release”. The former are not the one on call for bugs or the one that get blamed for outage, but they are the ones that get praised when projects are completed quickly. Anything that’s past demo level is good for them.
I'm not saying they're mutually exclusive. I'm just saying that we can't expect them to come as a packaged deal.
For example:
Company A - janky code, ships quick
Company B - great code, ships quick
Company C - great code, ships slow
Company D - janky code. Ships slow
The average survival rate will be in the following order:
B > A > C > D
My point is company A will capture the market and iterate quicker than company C.
Company B is what you're probably thinking of , and what many people think they are building.
Company D is what most people are actually building.
Company C will win out in the long run over company B if they have capital and network.
I like this. It has a lot to do with the company building journey too. Some companies that I feel are probably the B types had a super clear product vision that quickly resonated with users. So the original architecture that fit their vision was probably easy to scale for the features that came as a natural progression of the product. Meanwhile, a company that builds a product and tries to pivot or found the original vision only partially what customers wanted, well these situations put you in the position where it’s probably easier to just force what you have to work for the basis of your iteration. Starting from zero is usually not as easy as it sounds. It’s more like you make a Hail Mary football pass, usually ugly and risky but can get quick results.
I don't think I've ever not learned a better way to write something after writing it. Sometimes it's small and insignificant, sometimes it "forces" me to start over. The funniest is when more than half the code deals with something that won't happen. The banana that is not a fruit clause.
You can prototype UX with a tools like balsamiq or taking photos of paper sketches with paper-to-app application. No need for code to share an idea. Especially from business to engineering or vice-versa.
Product Managers coding is like Developers writing marketing pitches.
One of the major concerns with prototyping, at least in my experience and based on the general vibe I've felt from others over the years, is that clients will generally do some variation of "You have a working prototype? So how many days until it is prod ready? No more than a few weeks, right?" and that will be their expectation. AI makes prototyping easier, but makes this specific drawback much worse. Expectations are going to be misaligned, leading to many disappointments, and likely some number of developers taking undue negative outcomes. I'm not even sure if it will normalize to reasonable expectations, given that this tension never seemed resolved even before AI was in the mix.
This is a very interesting thought. We complain about having to fix some MBAs vibecpded slop, but it actually might be faster, easier, and alot less painful than getting them to try to explain their vision to us and implement what they have in mind.
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
You are right, but at the same time, if no UX designer is involved in the loop, what happens when they've prompted a prototype that looks good - and therefore eludes them to think it's designed good as well? How do we convince them that we need to involve a UX designer to fix the application flow?
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.
That's odd: all the other AI proponents on HN recently defended their decision to produce AI written code by saying the coding was never the hard part, it was the translation of business goals to a spec.
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.
Agencies that focus on this sort of work are going to make bank. We’ve already gotten some work like this, and it’s just going to keep coming as people think they can vibe code their products. Like you said, easy money.
Lots of people are gambling on AI with big bucks. Some of it is promising but all those bets won’t pay off. I like to think of this mindset as being the human slot machine that people are shoving money into.
Without doxxing yourself or your clients, can you share more about how this plays out?
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! :-) )
I'm sometimes puzzled by the way people use "circular" to describe an economic system pejoratively. (Not to suggest you are.) Seems like any worthwhile economic system is ultimately cyclical. Pulling resources into the loop is just a bonus....
Some of this is also going to die out, if the prediction of price increases for LLM tools and tokens holds true. In that case a lot of this software essentially becomes abandonware overnight because the actual maintainer was Claude or Codex.
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.
Are clients really paying for it? It’s really fascinating actually. Is it because the ”client” built it so they have sentimental value and sold it to themselves before you receive the request?
Nice the market is real and the problem is growing with the muti-agent work, The mess that AI do also create a nice opportunities until someone actually solves the ai result.
Most devs will say less, but the reality is most of the time you build the wrong thing first, and the price you quote almost never gets what the client wants/expects and includes many overruns.
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.
As some already said; the real win is into having a business driven prototype; the work to gather those specs is already done and, generally, very costly when done in the traditional way. So from scratch if having to do all of it is more expensive; technical from scratch far less so.
That is also fixing… The client does not care about technical things so indeed rewrite is usually the best way even if we do not tell we did (people are proud of what they made so they do not want to just get told it was thrown away).
> the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on.
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.
Well, this is not the first project that has this. Depending what llm/harness and how it is yielded, this happens, a lot. How often have you had Opus 4.x note; ‘485 failed tests, but those are not related to my changes so I will not dive into them’? You believe someone who does not know about tests or code or linting or compilers will push back on that? I know that’s not happening for a fact.
I have approx 40GB of docker containers spun up at any time in order to run the app I work on, and it only seems to get hungrier by the day. I have absolutely 0 problems imagining a single unoptimized Next app needing multiple gigs just to run, yet alone compile.
Shameless plug - I've been working on a general repo linting tool alint [0], which helps keep a repo cleanly structured and hygienic - essentially a linter for everything in a repo that a language-specific linter doesn't cover. It also has some considerations for integrating/playing nicely with agentic coding [1]. This started as a replacement to a bunch of scripts I had in repos that did similar things - but more cohesive, readable and much faster.
You'd have to know what a linter is and tell the LLM to set it up though, right? Or just get lucky and have it suggest setting it up/set one up without asking.
The OP said that this was coded by a product person though. The product people coding and using these tools, who are spreading the pro-LLM propaganda, are not doing proper prompt engineering nor lint fixing.
> _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.
I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and understands all they do. I've had friends who go off on crypto related maths and I'm like "I passed that class, but know that I do not really know the subject you just talked about" ...
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...
Some people are very good at working with complex abstract ideas, but are terrible at signaling that intelligence to others. And some are fantastic at signaling intelligence and steering conversation toward domains of knowledge that they've studied (many political commentators come to mind), but don't seem to have processed those ideas very deeply.
> 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.
One of the things I try to teach my kid is: You are going to have to deal with the fact that there are deeply stupid people all around you, without it affecting your mental health. Those stupid people might be in a position of power over you, they might be other kids in school (or coworkers, later), they might be the president of the country, they might be your neighbor, or they might just be obstacles on the road on your way to work every day. You need to learn how to cope and accept this, gracefully deal with them, and how to protect yourself from their stupidity when it might affect you. It's emotional regulation that smart people need to learn or they go crazy.
A lesson which I wish I had learned as a kid; I had examples to work from, but nobody taught me how to deal correctly. To cope and accept without it eating me up.
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…)
The older I get, the more I realize that individual variation in humans is truly enormous. Any trait you could pick is much more widely distributed than any individual human can see from their perspective.
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.
Same wrt my wife and I. She’s quite clumsy and to my assertion doesn’t always think things through. So it’s a bad combination for “accidents” to always happen which I think are very preventable and quite obvious to occur using her approach. A lot of it is just mental errors that I don’t make, but it’s not that I’m perfect I probably just make different mistakes (I think less volume too ;)
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.
Well, how hard should you beat yourself up over a mistake like that? If I forgot my groceries in the car, I'd just laugh about it being a silly one-time mistake. But if it happened twice I'd take it more seriously, and maybe make a note or something to remind me. I'm sure everyone has made some silly mistake like forgetting a jacket at a party or leaving a phone at home sometime. I think we should be a little extra forgiving toward others, because we'd so easily forgive our own mistakes
Does your wife have ADHD? She may not be physically capable of learning from her mistakes without the use of frameworks built to address the disorder.
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.
It's lonely being an outlier, especially in a trait that's so fundamental to how you see the world. Despite best effort, it's hard to relate to most people, and they especially find it hard to relate to you. The delta of lived experience is quite wide, often insurmountable.
I would say there are two explanations for group 2.
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.
Or perhaps there is a 3rd explanation, spending all of your time with people much less intelligent is frustrating and unsatisfying, and being such an outlier, it's how most of your time is spent.
Someone with a 142 IQ is to the 100 average in the same way that 100 average is to someone with a 70 IQ. We don't expect people with average IQ to spend all of their days with 70 IQ people (in a peer situation).
(BLAH BLAH BLAH Multiple intelligences, IQ isn't a good measurement, etc)
If you're so secure in your intelligence relative to your peers, why are you responding to me?
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.
> painfully forefront of mind that they're smarter than most everyone around them
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.
> 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.
> Just getting the code to run on your laptop took a week.
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
And in the before times, you learned a lot and walked away with knowledge on the deps needed, connections, .env secrets, and cleaned it all up and documented it so the next dev would have an easier time doing it.
Yes it did. That's how I learned a great many things throughout my career. I'm sure some people didn't pay attention or try to understand what they were doing, and didn't learn. That's on them. But most of us learned a lot that way.
I think it depends on how “before” we’re talking about.
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.
Indeed, there were plenty of people doing just that. I imagine they get the most out of vibe coding. However, when it became a problem, an engineer was still required to fix it.
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.
The second tome I had to do that for the same project (new computer), I sarted taking very detailed notes when doing this kind of unpleasant, supposedly one-off things.
You're not alone on this, I've also felt the same way, and those knowledge often lives in people's heads or random slack threads, and with AI code it's even worse It just generated what looked reasonable at the time.
I kind of envy people who need to clean up after others. At least you're puzzling.
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.
You are not alone. I was in this exact same position at MSFT and I put in my resignation. I am an L63 but the work I was doing, was something an L60-L61 could do and I frequently felt I was in one of those Bullshit jobs (courtesy of David Graeber). I was paid handsomely but once the sign on stock ran out, I saw that I was staying in the job just for security. I felt like one of those Hooli engineers who were sunbathing at the Hooli office terrace waiting for their stocks to vest. I am only 9 years into my career and I didn’t see that as the optimal thing for my career rn.
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.
> I am an L63 but the work I was doing, was something an L60-L61 could do
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?
Have no idea why people here are picking up on MSFT’s levelling system? I didn’t invent it.And it actually starts at L59.
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.
>Have no idea why people here are picking up on MSFT’s levelling system? I didn’t invent it.And it actually starts at L59.
Because it's standard arrogance by developers not realizing that Microsoft Level system is actually pay bands and because it was developed in 80s, leveling system COVERS all jobs because pay systems didn't support different pay bands back then. So there are lower levels then 59, for things like janitors, secretaries and others who don't make as much as SWE.
It’s not like the op invented Microsoft’s leveling system. It looks like junior engineer is 59 and 63 is something like senior engineer. I know at google there is a very meaningful difference in the work and responsibilities expected between our equivalent of 63 (L5) and 61(L4).
Believing in that system so much to say something like that might be worse. Noting against the OP, that kind of Stockholm Syndrome can be found in my past as well.
Not sure I understand. Is your contention that the distinction between senior and non-senior engineers is fake and everyone's doing basically the same thing? Or are you just objecting to the (arbitrary) names Microsoft uses for them?
False dichotomy. Of course not everyone has the same experience/skills, but any corporate system of putting individuals to tiers has little to do with experience/skills.
That's just not accurate. I've seen these systems run at multiple companies, and in every case they had a lot to do with skills and experience. It's true that they're not a perfect classification, and I think it's defensible that some people prefer a system where this kind of leveling doesn't happen.
But the tradeoff is that career advancement becomes less legible in a way that other people often find frustrating. Why does Alice get paid 3 times as much as me to work on cooler and more important stuff? "Alice is L7 and I'm L4" is often an easier answer to accept than "Alice is a better engineer than I am" or "People with Alice's experience have more options than I do".
> That's just not accurate. I've seen these systems run at multiple companies, and in every case they had a lot to do with skills and experience
> I am an L63 but the work I was doing, was something an L60-L61 could do
So you and OP believe that, these systems are good indicators of skills, so much that the last statement sounds normal?
I was thinking like that once, as well, but I got disillusioned. These stuff tend to be gamed.
> Why does Alice get paid 3 times as much as me to work on cooler and more important stuff? "Alice is L7 and I'm L4" is often an easier answer to accept than "Alice is a better engineer than I am" or "People with Alice's experience have more options than I do".
Sure, that's why these system exist. They justify pay, that's all there is.
> So you and OP believe that, these systems are good indicators of skills, so much that the last statement sounds normal?
I do. I think it's good not to box people in, where certain work is only for (my company's equivalent of) L63s and an L60 isn't even allowed to try. But when I do see L60s try, they usually need someone to come by and intervene, because there are critical skills that come with seniority that they don't yet have.
To be more concrete, one thing I often notice in junior engineers I mentor is that they're very "task brained". They understand their job to be nothing more than a sequence of development tasks, so they struggle to understand what's happening or how to help when it comes time for important things that aren't tasks. One guy I knew was frustrated that he didn't understand how priorities are set, and yet would never read the customer stories in his email that the company used to set priorities.
> So you and OP believe that, these systems are good indicators of skills, so much that the last statement sounds normal?
Op here, yes I do believe, the levels aren’t perfect though. I believe in them because I was once L60 and L61, I knew intimately what was expected of me then and I can assure you the work I was doing as an L63 could be done by someone few levels down, which is to say I was underutilised. The team was also not the right fit for me.
Levels tell you two things, the scope and autonomy you get in your work and more importantly compensation. From the compensation view point, it does tend to be “gamed” frequently by developers hired from outside who might be out earning devs promoted within.
I think they measure different things. The ladder levels have to do with the type of jobs you can accomplish in a large organization. I actually find they translate reasonably well to nontechnical roles in corporate structures. It is of course tempting to think that good engineers will be high level in those ratings, but that’s really not what is being measured by levels. A certain proficiency is required, but it’s mostly about responsibility and ability to take on tasks of a certain scale or organizational complexity.
All this to say it is absolutely reasonable for the OP to complain that they are being underutilized at the role of senior being given small byte sized projects of for no other reason than that this would prevent future growth.
I learned in my 30s that most of the software profession works on boring projects. Uninteresting, low value code, for a barely-working product, used by customers who don't really care, in a low-stakes market that doesn't reward excellence, rigor, or quality. If you can find the rare company where this isn't the case, go for it!
At first I thought "medior" was a strange typo for "senior", but on seeing it twice I had to check - apparently it's used in some parts of Europe to mean "mid-level"
> I just cannot push myself to care about the code this company makes.
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.
> basically threatening me to take more ownership, do more work, for the same pay
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.
I'm not the best friend. I often don't do my part to hold up my end of social contracts. That said, I'm a fairly decent low-commitment penpal. The internet is the place where I vent as well, and it often feels like a void. It doesn't scratch that therapuetic itch and therapy proper doesn't appeal to me.
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.
The first few sections hit me. I think that I used to be a “rockstar”, until I realized it wasn’t a good thing. Perhaps I could get things done 10x faster than my colleagues. But at some point I realized it wasn’t because I was 10x more productive than a normal person; it was that I worked in a way that made the normal people around me 1/10 as productive.
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.
I've definitely shot my own foot off in the past by implementing things in a rockstar manner. In my case, it typically involves me over-abstracting something that really doesn't need it. Or building something for use-cases that never actually happen. So I have to try to keep YAGNI and KISS in mind whenever my mind wanders into over-abstraction territory.
The ironic rockstar comparison is very good. The classic rockstar only cared about "new" technologies and wrote spaghetti code, the new 100x AI rockstar can do more damage.
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.
I’ve cleaned up after outsourced code and it has a different flavor to AI rockstar code. In the former, you can see that the developer only care about the current ticket. After every merge, it’s a flurry of bug fixes, because they always break something unrelated. And that’s due to bad design, you will see a lot of copy pasted code and unused code.
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.
there is certainly code that sucks; but the article strikes me as someone conflating "code that sucks" with "code that is complex and big and takes a while to get used to".
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".
tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes.
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.
Almost all opinion pieces are like that. They lack information density, but some readers (like me) like them that way. Otherwise, I'd only read one-line summaries.
I guess some people don't like articles that don't deliver a skill.md to solve a problem.
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.
I mean, go look at the author's linkedin and github. They're a "dev" with 20 years of 1 year of experience. Not a software "engineer"
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.
You make up an false dichotomy. The differentiation between the title and the supposed skill level based on title, is neither true nor helpful to make your point.
I was such a fool to lean hard into two production engineers to build the infrastructure around the two very profitable projects I built. I could have made so much more money spaghetti coding it all like a 10x boss and then jumped to Anthropic for one of those sweet 9-figure comp deals. Stupid, stupid, stupid me.
Don't call them rockstars - call them "resume-driven developers."
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.
Yeah, v1 is sloppy, then I tell the LLM to clean it up. Every 1 prompt of building tends to require 1-5 prompts of clean up. Simple, fast, clean good code.
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.
> Every 1 prompt of building tends to require 1-5 prompts of clean up. Simple, fast, clean good code.
I have found this to be very effective as well. However, it's so easy to do, I can't imagine they won't build it in.
The harnesses will improve and the loop of "self-review, judge what needs clean up, do the refactoring, repeat until clean" will get included in the one-shot. They are already doing this somewhat, they'll just get a lot better at it and as the models get faster and cheaper to run, the refactoring churn at the end of each task won't even create a noticeable delay.
I do not think the high-level "taste" knowledge that I've built up -- when to break something off into its own service, what to put in the DB vs cache vs queues vs blob storage, how to isolate important logic in pure functional layers so it can be tested and validated independently -- is any more "unlearnable" to AI than the stuff I previously considered impressive that's now one-shottable like "write a Prolog implementation from scratch".
And yes, right now you still need the architectural and system design knowledge because the LLM will fuck that up. We'll all find out if that continues being needed in the future. From what I understand about LLMs and how they work, I doubt it, but also, yeah, I doubted it would've gotten this far when I think back 2+ years ago.
Also, maybe I should be clear, I pretty much never one-shot things. My sessions with claude or other cli tools always starts with a bit of a conversation until we converge on a good plan, claude builds the code, we discuss some more, then we iterate.
I wish I had current-day AI (and a big credit card) for my previous job, they had a big legacy mess made by a productive but not very good developer, but my job was to rebuild it.
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.
Any tips on how you unsloppify things? Are you using things like claude.md/copilot.md (or similar) to guide better, do you have specific types of prompts that you run, or do you adjust your code review practices in some way to more efficiently review lots of slop code?
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.
I accept that for every prompt of building I'm going to have 1-5 prompts of refinement.
Once the LLM tells me "Okay, it's done, everything works" I always as it to do a thorough review, I tell it to split up the work among sub-agents with each one taking on a specific responsibility (look for code smells, look for bad architecture, review the data access model, DUPLICATE CODE, testability and unit testing, etc.)
After a certain number of revisions and reviews you'll come to accept the shortcomings it comes back. Usually there will be specific design decisions you made that the LLM keeps bringing up, once the review only brings that up and maybe some other minor issues it's time to move on.
I don't overly rely on markdown files and directions. I don't rely on tooling around it either. I just don't trust the LLM when it says "all done", tests pass, and deployment works. I make it to multiple reviews and iterations even when it thinks it's done.
I also ask it to explain the system back to me. Obviously it should understand the system just by reading the code. But somehow, explaining the system back to me seems to make it more effective. Then I'll ask it questions about how I should make changes to the system. Sometimes I'll agree, sometimes I'll disagree and offer an alternative and ask it to assess the alternative. Having this entire conversion in its context seems to make it way more effective at refactoring/unsloppifying code.
Understand what you're writing. If you never build up the mental model of what the code is doing you'll never be able to discern what is slop and what isn't. There are no shortcuts.
Piling more prompts on might get you to the same end result, but without understanding you'll never know when you're there.
Absolutely. I really don't think the future will be humans reading and picking apart an AI-generated codebase, there will be tech debt agents or whatever running overnight.
I think you misunderstand why tech debt lingers around. It's not a capacity or capability problem.
Organisations just don't want to deal with the accountability involved with "touching cold code". Whether it's a human or "AI agent" doesn't change the "It worked in prod, you touched it, you broke it, never touch anything again" dynamic.
That's one dimension of it, but in the context of this thread we are talking about how maintainable a codebase is for other humans. If your codebase is messy you depend on a few key employees and it might be hard to onboard new ones, so there has always been financial incentives to reduce tech debt.
Um, no, actually AI makes it better because the cost is lower now. I'm not sure what point you're trying to make here, obviously organizations already fight against tech debt all the time through a variety of means?
The point there is that it is MUCH easier to get corporate to agree to something when the cost is nebulous and being paid anyway. If you get a senior dev to clean up some tech debt, how much did that cost the company? The dev will have some multiple things at the same time, so you can't cleanly assign a number of hours, maybe multiple people are involved. It's practically just an unknowable. Practically, $0.
So your proposal to handle tech debt created by "AI" being unable to do good engineering is... throw more AI at it? There's a saying about the definition of insanity which comes to mind.
Code that is written will have to maintained often by someone else than who wrote the code. So if one write code nobody else understands its an eventual maintenence failure.
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.
Its never been quicker or cheaper to build something with bad foundational assumptions and principles. Its never been easier to add features whilst not recognizing that it comes with added responsibility. And it will never be too late to hire me for your V2 migration project.
I think this is fine? Code used to be very expensive to generate, now it is cheap. Building glue logic between well-defined, well-documented APIs has never been easier or faster. There is a time and place for throwaway code that quickly automates a task. It is fast food to fine dining -- not everything needs to be a Michelin star experience.
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.
I think an important caveat is that LLMs are prone to writing unnecessary code, i.e. there's almost a superfluity to it, that at the same time makes it less straightforward and more prone to unnecessary side effects, which it does catch and handle, but that again expands code further.
Then you add an agent that goes through the code and simplifies it. Before every sprint, you get the agent to simplify whatever it can without losing fidelity.
I should probably know better than to interact with a 3 month account called "freediddy", but here we go.
> 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
Then I asked if it could simplify it further. I would expect it to say this is simple enough, or just use the actual `sum` function, but it did this.
add = lambda a, b: a + b
That is, at best, a useless but harmless change.
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.
> If you ask it to simplify something, it will make changes whether it needs to or not.
This is false. You can prompt it to only make changes that will have a material effect on the performance. You can create performance tests and have it run the test after every change and if nothing changes then back it out.
You're not thinking creatively enough about how to use AI to your advantage.
One argument I heard from a college that the experimental llm written code (not production ofc) should be "write only" - you specify the requirements and constraints and let the machine figure it out - you specifically avoid "fixing it" or "cleaning it up" or reviewing the code because it disrupts the state of this discrete optimizer (over code). Not saying that it is right, or that it should be applied in prod, just noting that this is one potential way to go for non-critical code with clear "win conditions".
I kind of resemble the Rockstar portion mentioned... that said, I'm a massive fan and prominently defend KISS/YAGNI over most other principals... Not the there are never abstractions, but IMO, abstractions should make the rest of development easier and not just hide the common points of use/access behind painful boilerplate or interfaces.
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.
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.
So far my take has been that there is code that isn't very important, in the sense that if it works it works, it won't be modified or extended much if at all, and it's easy to verify that it works as expected. This type of code I'm happy with letting the AI go wild on.
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 never seen code that is unimportant. It’s either being used or not. If it’s boilerplate, it can be abstracted away. There are domains that are riskier than others (debug logging vs crypto for auth), but sometimes bugs in a somewhat safe place can lead to some catastrophic issues (you do not have to break a crypto algorithm if the key can be leaked via logging).
As I said, I think it depends on what's being made.
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.
IMO that is not a rockstar developer, but a junior developer rocking LLM agents.
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.
This is why I always work at a new company at least 6-12 months before making any major changes. I use that time to get into the flow of how things are being done (even if I think they are not efficient). I may make some suggestions but that's it.
Of course, I'll probably never get hired again anywhere so it doesn't matter anymore.
I heard this kind of rockstar stories a lot from my friends but I never encountered one in real life. I worked in small and big companies and no one with allowed to use any obscure language or tooling. I count myself lucky.
I’m sure the general premise around AI-generated code is accurate. That being said, I’ve definitely had interesting moments where e.g. Claude produced code that matched the pre-existing codebase quite nicely, and slowly started building up its memory of how new pieces fit into the codebase in an idiomatic way. Then again, it started to throw in Tailwind-based CSS classes all of a sudden, because it assumed that Tailwind had been set up (it wasn’t).
This is where determinism is useful to help avoid these. A tool like Archiet does the determinism side of things and generates working solutions, which can then be given to a human or AI to sort out any gaps. This saves time, tokens and the need to clean up after AI rockstar developers.
Archiet also ships with the right architecture documentation, without the right architecture or specs-driven documentation, AI rockstars need clean up.
The point is that developers like this purposefully introduce new languages and frameworks that only they (and maybe not even they) fully understand, so they make themselves harder to replace and ensure that they appear ahead of the curve. (Then they get bored and leave anyway.) It's totally valid to introduce new technologies when the problem calls for them, but doing it in a way that's purely detrimental to the rest of the team is very selfish.
Exactly my point. Learning stuff is fun. But if you're going to introduce new technologies or programming languages into a system, you need to make sure it suits the skills and experience of the rest of the team. Rewriting the company's admin dashboard in Elm, not letting anyone else work on it, and then quitting - that's just cruel. (Elm's cool, but you know what I mean..)
There's a difference between introducing new things because they are a well thought out appropriate choice and completely ignoring the standards of the company because you want to do resume driven development. I believe the author is talking about the latter.
I've worked with folks like the ones he cites. I've been jealous of their ability to absorb new things, but then you realize they're absolutely allergic to any kind of maintenance or responsibilities beyond "build, build, build".
Like many other critiques along this line, I think the answer is: Yes, for now. For example, in my own code base, I have an agent dedicated to maintaining a sane data model. This agent reviews the plan in advance and again during code review. And then I review the code myself. This seems to be sufficient for my work, at least. YMMV. It was a good post though. I enjoyed the take and the writing.
>Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.
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.
The fact that LLMs fundamentally do not, and cannot, have understanding or reasoning. I don't think you can produce craftsmanship through sheer volume of throwing stuff at the wall and seeing what sticks.
That's because the businesses got into the habit of new C level means new project, obviously the old code is bad.
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)
Yep, I worked at a small company that got bought by a bigger one. We had a solid if aging product to support which was one of the big players for the niche. Once there was a leadership change, 2/3 of the devs got put on building a replacement software. Then in a couple of years our subgroup got spun off and sold to PE and the v2 project was shelved for another brand new design to align with the new ownership. I left just before the spin-off, but witnessed how the original software slowly rotted away and all of the marketshare dominance we had for that area slipped away.
Devs love new tech and the product people love something new to put their stamp on, but chasing that high can be ruinous.
I have seen over the past decades this concept of just reusable throw it away code becomes the norm and that’s why also I’m always surprised to look at people complaining about AI development and it’s like yeah it’s just the same as all other development at this point everything‘s just frameworks and throwaway code
I’m not even mad at it but it’s just one of those things where people are like “I’ve never dealt with anything like this”
But it’s the majority of operational software engineering since more or less forever
I think its also the pyramid of age - as you work in this field a lot of people burn out, the field was significantly smaller in the past and has shown huge growth, and the young say "yes sir!" and work nights and weekends on the fucking stupid idea while the older folks push back.
So in general most of the people have worked on a bunch of greenfield development, thought of the project 2 years old as aged out entirely, and never thought you might "maintain" something at all.
In my experience, this is because a modern engineering organization is laser focused on delivering value. Value rarely aligns with refactoring an existing, working implementation. If need the data, you build an integration on the output data. If something isn’t working well enough, you fix that one thing, you don’t refactor half the application.
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.
The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:
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.
It's different because LLMs can generate code that immediately needs to be refactored at speeds that were unfeasible before. There was a practical limit on the amount of technical debt that could be created in a day before, now that limit is 10x or 100x higher. It can be generated far faster than it can be fixed.
Then code factoring was never the key problem was it?
It was organizational discipline
Again this is the same problem previously…organizational lack of discipline means you get some diva to build some un maintainable thing and then you have to go back and refactor it later
The problem is the same the speed is different I acknowledge but both our organizational problems and have nothing to do with writing code or technical
If a neighbor leaves their dog's poop in my yard I have a problem.
If someone builds an industrial scale dog poop delivery mechanism that delivers tons of dog poop to my yard every day I have a different problem even though the underlying basics are the same.
One thing I’ve found helps is leaning a bit more towards a modular almost microservice like model with clearly defined interfaces. Gives you a bit better control than a huge unified ball of AI spaghetti code
Is the "Cleaning up after hundreds of AI rockstars" part a description of an actual experience? I don't feel that it is. I would expect much more swearing if it were the case.
This is a confusion that you could not have predicted, but primed by your comment, I expected "terminal star" to refer to a suggested predecessor of the AI rockstar. No, it refers to the animated Claude Code star :P
I don’t think the analogy between rock star developers and LLMs bears out here. Like any other tool, AI abides by the basic reality of garbage in/garbage out. If you don’t make sure the LLM has sufficient context then you get what you get. Same point with vague prompts.
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.
The post seems to not address the fact that different product phases exist which in turn affect the software. Similarly, teams are different and get assembled for different purposes. There is also a difference if software was created in the past 24 months vs past 10 years. It is very easy to attack decisions made which look messy now, because many reasons. Everything looks obvious in hindsight. And then making it ad-hominem like does not sound smart, it is a clickbait, the issues are usually more complex.
this resonates with me, but fortunately one difference between LLMs and rockstar developers, is that LLMs will at least _try_ to explain what they are doing, and why something has to be certain why. I've gotten quite a lot of mileage from being a five-year-old with Claude and just asking "why" until I'm satisfied
100% wasn't. I use Derek Sivers' approach, search "writing a sentence per line", and I try to keep my sentences short intentionally. If you view source on the HTML you can see the line breaks.
Sometimes I wonder if any of this will even matter in a few years. How many of us compile code and then have to clean up the assembly, or even worry about what a compiler generates as long as it's correct?
I realized recently that this all has an unsavory element of ego to it. It doesn't help that LLMs have basically been trained to talk like they're performing in a movie, getting creative with techno-babble that sounds both plausible and exciting. I recently had to review some slop where the LLM was using terms like "event storm" to describe how some callbacks work, or "gating-solve" to describe a simple change to an if statement. Combine that with their sycophantic tendencies, and it really can make you feel like you're a star hacker in a Hollywood movie.
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.
Funny, the element of ego I'm seeing are the devs that can't accept that LLMs write perfectly good code at a faster pace. It's always "slop" this or "vibe coded" that. Meanwhile I've personally shipped multiple apps and professionally we've done HUGE things in these past 6 months using LLM tools.
Sounds like the aforementioned rockstar dev may have found their way to comment and miss the point.
When I was less self aware, I'd say similar things: my coworkers/manager can't accept that I write perfectly good code at a faster pace. Doesn't matter whether it's good or bad code-- the coworkers have to collectively understand it in order for it to be maintainable.
Not sure what I'm going to link to in my professional life, it's all private repos. We have a large microservice architecture in AWS. We've made major changes and the LLMs have helped every step of the way. Migrated our whole auth system from being regional, resulting in customers being limited to specific regions or managing their multiple accounts across regions, to a global authentication with data residency built into accounts so that they login to what looks like a global app now. No more uk.example.com, eu.example.com, ca.example.com and us.example.com. It's now just example.com, but data residency (and currently data processing too, but that's another thing we're working on) stays the same. This isn't some small app, this is the main product at a company with nearly a Billion in ARR.
For personal projects, only one thing could I actually show - vaicayo.com
This app was originally started pre-llm. I just wanted a centralized place for my wife and I to organize our vacations. I built out the basic crud for that a long time ago and we used it, but then llms got popular. I first integrated it into the app, now I could get it to generate vacation plans completely with the llm. It did okay.
Somewhere between 3-6 months after building out llm features claude code released or I became aware of it enough to start using it.
I rebuilt the whole thing. So what was once a spring boot app running in AWS ECS with alb + cloudfront (and yeah, some sqs+lambda python processes, s3 buckets for storage, aurora rds for db) is now a super lean apigw + lambda + dynamodb stack with a svelte frontend. I went from paying $20ish a month to $0. I also built a flutter app for android and ios that utilizes the same backend as the frontend webapp with feature parity. It's not really a production app, but it could handle it fine, it's completely cloud native and hands off to operate. And let me be clear about the rebuild, it's not a 1 for 1, I think all that I kept was the domain model.
For features, it's mostly just a crud app. You plan your vacation in it. Outside of that there's the ability to take pictures with the phone app that auto-sync (there's a bit of complexity here, the phone app only syncs pics when it's on wifi unless you change settings to allow syncing on cell network, images are cached locally with a ttl, uploads will run in the background and queue up, uploaded images automatically resize/compress and generate thumbnails from an s3 event lambda). The other more complex item is email ingestion, when I get a reservation email I forward it to the app and it automatically processes it (the only place I use an LLM in the app right now). If it can't discern what the email is or which vacation it goes to it goes in a travel inbox so the user can route it to the right vacation and object type. Oh I guess the paywall is a little complex. I don't advertise this thing but I have left user registration open if anybody ever wanted to use it. I did lock the email parsing behind a paywall and I limit photo uploads for free accounts.
So frontend, backend apis, flutter app for android and ios all built 100% by llm.
For code quality, the frontend is okay, the backend is pretty clean but could use some things split out into domains, and the flutter app has some work to do (recently found a couple code smells). But there's no issues adding features, shipping, etc. I literally finished adding some of the photo syncing features in the flutter app last night.
Other than that, I have created 5+ other personal projects that I wouldn't have without an LLM. I've made 2 godot games, a private scribbl.io clone with a few extra features that myself and my coworrkers play as a "happy hour" on fridays, tons of ci/cd build stuff and terraform (using my own personal modules, so I guess that's not 100% llm coded if you consider the modules), and then a couple other simple apps.
Would you mind talking about your experience making the 2 godot games? Which agent and model did you use? I've been wanting to dabble here and interested to hear stories.
Got distracted and didn't touch on the godot specifics.
I start the project in godot, then I talk to an agent to define my game and give details. I tell it to have a conversation with the end goal to be building a CLAUDE/AGENTS/GEMINI markdown file for future agents to help build the game.
I mostly used free assets for the artwork. I made some myself in aseprite. I utilized LLMs a tiny amount to generate some assets, but typically those are more of a jumping off point than game ready art assets. This has been what's slowed me down the most in making games.
I use any of the 3 big frontier models; claude, chatgpt, gemini
I only use the cli tools; claude code, codex, gemini cli (which is being phased out for antigravity cli soon)
I've generally had the best luck and enjoy working with claude the most, though that may be because that's the model we use at work (from aws bedrock, we pay per token and always have). Gemini and codex have flip flopped on 2nd place, though right now I'd lean Codex.
On my personal stuff I typically use codex or gemini because those two I have subscriptions, claude I still pay per token but through anthropic API like 90% of the time and 10% of the time through bedrock.
The job when picking up a codebase made by human or machine always involves reverse-engineering the design intent from code. That's especially hard for LLM-generated code because the path to runtime was so rushed.
> 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.
One of the things that annoys me is that we could know what the original intent was, and indeed the preferred form for modification: the prompt! Yet for some reason there's no standard/tradition/expectation that people commit all their prompting.
Perhaps I should start trolling people that your software is not truly Open Source if it's not Open Prompt.
In my opinion the problem rather is that most managers do not value elegance of the code, and most programmers are either too obedient or too clueless to dissent to management. Also, most team members don't want to understand highly elegant code and its inner beaty.
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.
I've said it before, I'll say it again, I'm convinced LLMs will be the thing to convince software engineers to get it together and create a licensing board.
Please write a manual on how to cleanup after AI rockstar managers who think they can code.
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.
> Please write a manual on how to cleanup after AI rockstar managers who think they can code.
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
It's the mandate from top-down. Of course it's a people issue, the problem is that the people creating this issue are exactly the ones paying us.
My manager got the mandate she needs to start coding, she doesn't want that, no one in our team wants that, she's a great manager exactly where she is right now. Nonetheless, we are helping her to code to show something for the higher-ups so she can keep her job, we really don't want to lose one of our best managers because some C-level is anxious about AI...
- show increase in errors and outages caused by this approach
- integrate manager changes into your CI pipeline (coding / reviewing / testing / documentation)
- discuss how your manager can do the changes they need to do without sidetracking all other work
Make it indeed about the money: coding by PM + fixing what was coded + dealing with fallout is greater expense than coding by PM + automated guidelines + reviewing what was coded.
That is - if the environment you're working in is reasonable and it's not a power play by your PM
I don't know why you assumed it was a PM thing, the mandate is for EMs to be more "hands-on".
On your points:
Manager changes are always going to go through the usual pipeline, we are 10k+ people so there's not even a way to go all gung-ho pushing stuff. They need to be reviewed, approved, etc.
But we don't want our manager to code, nor does our manager, so we are just helping to cross the bare minimum expected from higher ups. For my team it's not an issue with our manager's code (those will be at max small fixes, well-defined, the most trivial stuff), the issue is they are mandating managers to do it.
I don't know what size of company you work at, where I am at there is simply no incentive for me to do all the extra work to show execs/higher management the issues cropping up.
I don't even have access to them, I have to pass through other channels, those might compile reports from many people to try to present a case, if they get to present a case then there's a whole other discussion to happen at director/VP/C-level about what they want to do, and since it goes against their big mandate it most likely will just be thrown out.
In this structure I have no motivation at all to go out of my way to perform data gathering/analysis, wrapping it all in a nice concise document explaining what the data means, potential remediation, etc. just to become a footnote in someone else's document that ultimately will not change anything from the VP/C-level mandate.
I assumed that as it was hitting too close home (both PMs and EMs were expected to use AI, with PM trying to code in solutions that they didn't have expertise nor domain knowledge to deal with; EM was prototyping solutions that had access to prod DB that were shut down as soon as we found out). I can only symphatize nonetheless and thank you for giving your PoV.
Because most people, in most parts of the world, are not allowed to question whatever their superiors do? And, yes, unfortunately are also expected to clean up after said superiors' messes. Of course it's a people issue. AIs just make people issues worse in new and entertaining ways.
100%. You don't "clean up after them." You make them clean up their own mess. You refuse to let a mess into the system in the first place.
Same as it ever was.
The only difference now is that if you let it happen, it'll happen 100x as fast.
When I was mentoring junior devs, I would start by fully reviewing their code. If they had a ton of mistakes more than a few times, I would only review until the first mistake, and then reject it. Repeat, repeat, repeat, until they got the picture that I wasn't going to let mistakes through, and handing me a ton of mistakes was going to waste more of their time than mine.
I let the pain be their pain, instead of mine.
But good developers, I'd help them by doing a more thorough review and not wasting their time. Good developers were the ones that made an honest effort to follow the requirements to the letter and test their own work.
We further emphasized this by having a very simple coding test during the interview, and the only thing we cared about was whether they followed the requirements to the letter. There wasn't a lot left to the imagination, and the requirements were very clear. Anyone who missed them wasn't someone who would do well with us.
That very same test will help filter out a lot of AI-braindead candidates that don't check the AI's work as well.
Actually, I wish I still had the exact test so I could throw it against an AI and see what happens. I'm a little afraid that it would pass it too easily now. I'm not sure how I'd fix it to prevent them from just using AI.
The code is AI reviewed, and I was ordered to change repo setting so a single AI review is enough. I've tried suggesting a lot of things, but it is not on my paygrade to allow or disallow something, only recommend.
Rockstars, AI or not, were 'successful' because they defined how success looks like. They created that perception and called it success. Not many people would bother going beyond the perceptions. They don't know how success or good code looks like. Rockstars gave them the playbook.
In reality, sometimes I wonder if there is really anything beyond perceptions.
Story time! I Worked with not just a "rockstar" but what I suspect was a "superstar" for about three years at my last gig. It was a small company with about 3-4 developers at any given time and we worked on an embedded Linux product in a moderately safety-critical industry that had a messy ~25 y/o codebase and a custom, roll-your-own Linux distro on custom hardware. Our "superstar" had been with the company for ~10 years and due to really high turnover I was the most senior of the rest of the staff with 3 years. The manager of the software team claimed to have 10+ years of software development experience on his resume and LinkedIn, but would ask CS 101 questions in our software planning meetings.
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
You might think, with our superstar developer, a workflow like this would be possible. Honestly, I saw him do things (pre-AI) that were astonishing. He would work a weekend and add a feature I thought would take 2 weeks. He created a re-write of our main product and demoed a completely new product using the same hardware by himself in about 6 months. He would take feature requests not assigned to him and just do them before the assigned developer was even finished planning the feature. The sales team would come in with a pitch for an insane new feature idea (like add a Farsi version of the UI) on Friday, the rest of the team would attempt to push back on it, then he would check-in a semi-working version of that feature on Monday. For these reasons our manager loved him and would always ask the rest of the development team why we couldn't keep up. It was demoralizing and frustrating. At the same time, as a company, we were mostly unable to get very simple changes out the door. Most of the insane features we added died on the vine before getting to the customer (but the code would remain polluting the codebase). Any bug that was fixed would reveal 2 more serious show-stopping bugs. New software releases were regularly regressed: they would break one of our customer's use cases and because we never created basic functionality like OTA updates, we would fly a tech out with a flash drive to revert all the software. We worked on 3-4 new products an not a single one ever saw the light of day. Our company github was littered with dead, abandoned, duplicated repos.
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.
I think about him a lot when I think about companies going all in on productivity maxxed vibe coded AI. I think that under better management that restricted his impulses and gave him more structure, he could have been a great asset to the company. Unfortunately when let run wild over the company codebase he was an absolute menace and ultimately led to less actual useful work getting done and an erosion of customer trust. I think this might be the reason we are getting two diametrically opposed experiences with AI: it is either going to destroy your codebase or deliver features at an astounding pace, and I think the difference is the actual technical knowledge of who is managing these projects. My guess is that there are a lot of places with middling or non-technical management pushing AI coding that are going to be in struggle city in a year or so and not understand how they got there. "But AI was making us so productive!".
If you're just starting to learn programming, people will tell you that maintainability is important, and they'll mention John Ousterhout's concept of the "tactical tornado" as an anti-pattern.
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
I believe GNU Emacs was created in 1984 or 1985, and it's still going strong. I guess it's not easy to work on it due to the long history, but I understand it's been refactored as the developers went along.
Hmm, ~30 years ago the compilers that I was using were generating generally fine assembly/machine code. Some of the other tooling was more troublesome: cross platform high performance numerically stable code and C++ static template deduplication paid for a lot of beers around then, and I needed them.
Compilers are deterministic and they actually possess domain knowledge of what they are trying to do. AI models are non-deterministic, have no real domain knowledge due to lack of an underlying world model, and their way of "writing" software is to spew out something that looks like something that they have been trained on, then iterate on it long enough until it has reached the level of being barely runnable.
People say "determinism" but I don't think that's actually the property we care about. For instance you could imagine a compiler that makes heavy use of superoptimization with random search and it would still have the ineffable quality that LLM codegen lacks. I think what we're actually trying to say is that the compiler preserves the formal semantics of the source language in its output, whereas English text doesn't have any such formal semantics to preserve.
Has nothing to do with that. If someone is looking for something, they can find it anywhere. If you want to say "prevalent in [place name]... etc" The emphasis is on the tech culture. The factors are multiple. Parallel: Do you know about chauvinism, etc.?
Agreed. There's no place for racist slurs on HN, especially when they're posted from behind anonymous usernames. It's often the kind of thing people wouldn't dare say under their real name if their livelihood depended on it ;)
We've banned this account for posting a spate of abusive comments in recent days. You've been here long enough to know this is unacceptable, and when users act like this we have to assume they want to be banned. If you don't want to be banned, you can email us (hn@ycombinator.com) and commit to observing the guidelines in future. https://news.ycombinator.com/newsguidelines.html
> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of.
> 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?
I'll avoid trying to guess what the author meant, but I found it rather relatable. Some of these "rockstars" pick weird languages, niche database, esoteric frameworks and whatnot, not because they're needed, but because that's the rockstar thing to do at that moment. And then they leave and you're stuck managing a Cassandra database and a Rust application when everything else around you is MariaDB and Java, and you have to maintain an application in an abandoned JavaScript framework, even though dynamic frontend wasn't a requirement.
This isn't a problem with "rockstar" AI devs. This is a problem of management. Who would let someone come in and rebuild the core infra of their business without any planning or review?
This article feels is trying to justify their own inefficiencies (lack of library or language knowledge) instead of taking the time to learn from the rockstar and their technology choices.
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...
> Sometimes there's so much technical debt that it can never be paid off.
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.
Never mind the huge, untouched, unspoken-of debt to all the people whose work--literary, artistic, software--under various licenses, or without, it (rather THEY, the owners and co-conspirators) are taking and re-using, without attribution, without credit, nor payment of any form. Not even a thanks (because as soon as that is acknowledged it will enter the consciousness and then the question of injustice will dwell--and we can't afford to have people thinking about that).
> Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.
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.
Craftsmanship is not dead in other industries in the same way it is being talked about for software.
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.
Do you honestly think an ikea desk has "more expert craftsmanship" than a hand crafted by a woodworker desk?
Definitely. Expert craftsmanship in cost optimization, in shipping optimization, in production/factory design and optimization, in material sourcing, in durability testing, in design for mass market appeal, in marketing material, in documentation, et cetera.
In some ways, sure.
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.
They also double as a nice and cheap server rack!
https://wiki.eth0.nl/index.php/LackRack
Don't you think IKEA has expert engineers designing their furniture that will sell millions?
Programming is the equivalent to designing a factory, not carving out wood pieces.
Some programming is the equivalent to designing a factory, some programming is the equivalent to 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.
I'm not sure why this even needs to be the comparison?
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.
This is a great argument for software factories. Writing the systems that build the system.
Physical industries are very different than software. Leather shoes are made many times, 1x per customer. Code is created once, using the same product for all customers. This gives a lot more leverage on investing in a quality product.
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.
That's wholly the wrong perspective. The equivalent of "craftsmanship" in software would be how the shoe is designed, not its manufacturing. Software developers produce unique intellectual property. They don't manufacture units of software. Similar to book authors or musicians (not on tour).
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.
There's a really interesting angle here from machining.
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.
Slightly agree. :)
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.
Going to be awfully hard to market rote machine maintenance as craftsmanship, but there are some suckers out there
If you've ever watched an episode of "How It's Made" and seen how incredibly customized these machines are, it won't be surprising that the people who build them are proud of their work.
My skepticism of the marketability of this idea deepens
I'm not sure that I completely agree... my longest lived apps are the ones that were built with a KISS to the extreme mindset... make it as simple as possible and easy to replace as can be. Then it just lives forever.
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.
Thought experiment: would a junior developer armed with a modern day gpt-5.5 or opus 4.8 in 2015 would have been considered a 10x developer (assuming nobody knew they were using AI)?
If you want to play games like that, you could also flip it around and ask if the AI would have been eventually fired (assuming no one knew they were talking to a computer).
Not sure what that proves.
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?
Of course they do. Have you literally never run into a problem that the average developer can not solve, but a expert can solve? That is infinity times more productive.
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.
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?
I believe in a 10x because it's everywhere.
It doesn't mean more work it often means creativity.
For example when I was an EE I worked at a company that had spent nearly 8 months, 50k on consultants, and easily 3 peoples full time for a lot of effort plus the testing side.
I swapped that 800$ board out for essentially a lightbulb. Did identical work <50$ and was more reliable. That simple change was easily a 10x improvement if not more because the logistics of that one board was absurd.
I'm proud of that EE work but code is identical. I would never call myself a 10x developer but I've wiped entire code bases more than once.
Maybe I have "10x" moments? But to say this isn't a real phenomenon means you're in a super structured and political enviroment.
I probably had that kind of 10x moment yesterday. I spent 2.5 hours analysing a feature request and I eventually advised my customer to think very carefully about it: it might solve a problem but the implementation time is going to be long, even with an AI, because of actual development and the time we will spend in testing it. Furthermore the new infrastructure will have recurring costs higher than what it saves. My advice is not to proceed. 2.5 hours vs 25 or more. 10x.
For "in the moment"s and short term projects, 10xers certainly exist. There's definitely things I can do in a week that would take juniors more than 10. But for bigger projects? Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years? I'd really doubt the latter and the amount of things I can do in a month that a junior can't do in 10 are a whole lot smaller than what I can do in a week that they can't do in 10
> Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years?
I briefly worked at an organisation where I was consistently and sustainably able to ship in two month blocks what other teams of 3-6 engineers at that organisation could not successfully deliver at all. I would consider myself around 75th percentile productive compared to the industry, but in that specific organisation I was at least 10x as productive as the median engineer - regardless of their seniority.
I think engineers tend to form clusters where everyone is roughly as intelligent/competent/productive as each other. Outliers tend not to join the cluster, or they leave quickly. I've seen this happen at the level of a company, but also in larger engineering orgs at the level of a team or group. High performers don't stick around when their median colleague is a low performer and vice versa.
Perhaps you've had the good fortune to work mainly in organisations with a high competency floor. Looking around, you may not see anyone who's 10x as productive as anyone else, but maybe you're ignoring that everyone is in the 90th percentile of the industry.
You can but not the way you're saying.
Once was part of a team where a mid level guy spent a year building/heavy maintenance of some catastrophe of a solution. They literally had the end users copy and pasting hundreds of commands from a generated excel sheet of a command per core (shudders). I spent ~2wks on a different architecture that was a massive improvement we abandoned their code base. He quit like 4 months later to join some faang. Granted that 2wks of work was on top of a distributed cloud infra that took me 6 months to build.
So yes, a skilled dev might skip entire months of work someone else would make.
What you seem to be describing is a companies skilled engineer designs something and passes down the spec. The guy making the spec is the 10x guy. For large projects it's even more pronounced. The article literally described someone who wasn't skilled they simply knew how to smooze the MBA's and a company with poor engineering leadership.
> I doubt even a staff level engineer is even a 10x above the junior
Its not about staff vs junior, its about smart vs dumb programmers. You don't get smarter with time, you just gain more experience.
> a problem that the average developer can not solve, but a expert can solve?
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.
I think the myth/claim of a 10x developer is true but only relative to said rockstar engineer's immediate environment.
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.
But mind you, I'm also saying that being a "2xer" is wildly impressive. I'm even saying that being a 1.1xer is impressive (because it is!). So I'm really not trying to diminish your accomplishments. The feeling of pride you should have for your accomplishments shouldn't be diminished because you aren't calling yourself a "10xer". That's not what's being said here.
Plus, my whole point is about sustained output. 10x and even 100x certainly exist in short tasks. I mean I can certainly produce a hello world program in python 100x faster than someone that doesn't know how to program. But over longer periods of time this gets to be much harder. Again, I don't want to diminish your pride, the story you explained is not a short task.
[0] That isn't to say that skill doesn't matter, it very much does. But luck is pretty far up there. It is behind skill in importance, but there's not a single (or even 2) factor that controls your life.
[1] This isn't luck, you can control this too. Stuck on a problem? Walk away. Go for a walk. But come back.
The research referenced in Fred Brook's The Mythical Man Month found that there was a 10x difference in programming task completion time between the FASTEST and the SLOWEST developers, but only a ~2.5x increase from the median to the fastest.
This! I've worked with a few developers I would consider net negative to their team and product, in that their removal would have increased 3-4 other team members productivity by say 20% each. Coincidently these developers were almost exclusively Indian immigrants. In organisation with poor corporate culture and the ZIRP (Zero Interest Rate Policy) days of hiring to signal growth and managers hiring to increase the number of reports (to signal importance) compounded the problem
Depends on whether they have one of the bosses that judge employees’ quality by the number of lines written.
No. I experienced this firsthand. Brought on a on level dev who was using Ai. Created slop, when asked how it works, he just said “it’s all in the documentation” Lots of good documentation, but that’s bot what I needed. I needed an engineer that understood and knew what he created. I’m no longer at that org.
[dead]
What really sucks about mass production is that it inevitably kills the middle tier of craftsmanship, whilst doing nothing to offer something of similar quality.
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 engineers are not artists nor shoemakers. They are factory makers.
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?
> 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.
It is definitely the fun part to me and scaling a factory is the challenge we all decide every day we write code.
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.
Great programmers learn all documents are high latency state-machines.
A "Report" is just a document feature projection.
People may initially think this is in err, then think again... =3
I remember when the Mac made everyone a publisher.
> In my most other "industries", craftsmanship is not _dead_, but it's been pushed to the wayside for (significantly) cheaper and more available alternatives.
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.
I still remember times when my work was mostly cleaning and refactoring old code written just to have higher LOC by devs from India paid in cents per line.
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
"software is _unfortunately_ becoming more and more "disposable"[0], in the same way other products are"
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.
You're confusing binaries with source code.
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.
> Builds change overnight, new versions every month with small updates.
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.
I don't think craftsmanship is dead, but I do think we've built a lemon economy.
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.
I hate how prolific this saying is. You can't know that you have all you need for your use case without first knowing more than you need. It's not something you asymptotically approach, you *have* to surpass it[1]. Without going beyond you, with no doubt, are just setting yourself up to live with unknown unknowns. It's absolute insanity that we say this bullshit with a smug look like we've discovered something profoundly intelligent.[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
More like a lemon tree economy. We can still talk about which trees to pick in order to not get lemons.
Craftsmanship does not have to die to have millions of software-engineering jobs displaced, right? I assume when people worry about the craftsmanship, they worry about that enough number of people would lose their jobs because AI coding has becomes sufficiently good.
Yeah, even though I like 'craftsmanship' here, stakeholders don't. I think "durability" is pretty good. 'Engineering standards' perhaps. I think we'll start to see the groundwork laid for software engineering as a proper engineering field, where specific performance characteristics are required for certain stakes.
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.
[0] It's not incredibly, it's monopolies
Hah. What a dream. Instead they’ll hire a team of what is essentially interns and have them deploy mass amounts of minuscule features with 0 guidance because, “hey - it’s cheap as hell and does 75% of what it’s supposed to do.”
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!
This is Indian Jugaad mentality being imported into Software Development. English equivalent is Kludge.
https://en.wikipedia.org/wiki/Jugaad
> but anything built around long running business processes should not be treated in that way.
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.
Yeah someone should train these LLMs on straight compiled machine code/binaries and the output so they can start writing directly in binary.
That is like running Photoshop reliably on an encrypted image.
Not necessarily. There is going to be a direct deterministic mapping to functionality in unencrypted raw binary.
I like fixing code made by AIs and others (outsourcing code is similar as someone else said already). Last week we found out some client tried to vibe some departmental tool; the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on. Now we have to fix it: its basically free 10k-50k euros over and over again for this type of work. Very easy if you know what you are doing; impossible if you don't. Keep m coming.
In some ways they are giving you a spec and UI mocks to implement.
This is one of the things I keep thinking about. At the very least, these tools make prototyping and idea vetting remarkably cheaper.
Then we go back to the old “the prototype works; I’m the boss and I’m telling you to deploy it to production”
There's like three groups of developers you need:
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.
Ha, I'm a gardener then, on my 15th year of maintenance. So halfway there according to you. Slowly, very slowly, fixing the thousands of bugs the rockstar left behind 15 years ago.
It's easy to look at a newly made garden, its flowers all freshly planted and its paths all neatly laid out, and think it finished, but once you see one that's been carefully maintained for decades and how its plants have matured and grown together and how the steps have been worn by human feet, it's clear the project is merely off to a good start.
This comment made me imagine what would the guy maintaining my first deployed project at my first company thinks about me. Never had this thought ever cross my mind.
This is such a great mental model.
Prototyping is widely underappreciated. People think it's waste to throw away stuff but it's more costly to build upon shoddy foundations
The problem is those shoddy foundations can support a lot of weight before they finally fail. A prototype you write in a day - not a big deal to throw away. However if you have been working for a while that is a lot of effort/money.
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.
The day you implement the first edge case to your prototype you basically commit to using it forever or spending a lot of money to replace it.
Well, there's nothing as permanent as a temporary solution...
"So we all agree this is not ideal, but let's use it for now and focus on ..."
Heard it so many times.
More than half the time it is correct - until you figure out those things you are asking to focus on you won't know what really works. Going for ideal now just means when you get to those things you discover another thing you hadn't thought of in advance and so you are no better off.
Experienced developers in a domain can sometimes anticipate the issues, but experience only comes from failing.
The real answer is allowing some budget to fix things and then fixing them as you go along.
But... "time to market!", "we won't have cash by the time this gets implemented properly" etc etc are the usual suspects here.
Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame.
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.
It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code.
If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
> If you have a good architecture and keep good code hygiene
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.
Then redesign the architecture. No need to go for a full rewrite as it can be done progressively. One thing I’ve seen is that people can be afraid to delete code, even if it’s not used anywhere.
I agree, but I think you've not understood what the reply above is saying.
You will never get the chance of "customers requesting changes" if you never ship.
The company with the janky code that shipped will. And they will iterate and get better - as described by your process.
> You will never get the chance of "customers requesting changes" if you never ship.
Why does good code imply never shipping?
Managers and Developers have different thresholds for “good enough to release”. The former are not the one on call for bugs or the one that get blamed for outage, but they are the ones that get praised when projects are completed quickly. Anything that’s past demo level is good for them.
I'm not saying they're mutually exclusive. I'm just saying that we can't expect them to come as a packaged deal.
For example: Company A - janky code, ships quick Company B - great code, ships quick Company C - great code, ships slow Company D - janky code. Ships slow
The average survival rate will be in the following order: B > A > C > D
My point is company A will capture the market and iterate quicker than company C.
Company B is what you're probably thinking of , and what many people think they are building.
Company D is what most people are actually building.
Company C will win out in the long run over company B if they have capital and network.
I like this. It has a lot to do with the company building journey too. Some companies that I feel are probably the B types had a super clear product vision that quickly resonated with users. So the original architecture that fit their vision was probably easy to scale for the features that came as a natural progression of the product. Meanwhile, a company that builds a product and tries to pivot or found the original vision only partially what customers wanted, well these situations put you in the position where it’s probably easier to just force what you have to work for the basis of your iteration. Starting from zero is usually not as easy as it sounds. It’s more like you make a Hail Mary football pass, usually ugly and risky but can get quick results.
I don't think I've ever not learned a better way to write something after writing it. Sometimes it's small and insignificant, sometimes it "forces" me to start over. The funniest is when more than half the code deals with something that won't happen. The banana that is not a fruit clause.
100% - one of the biggest advantages of software is its mutability, so why not use it to prototype properly?
[dead]
You can prototype UX with a tools like balsamiq or taking photos of paper sketches with paper-to-app application. No need for code to share an idea. Especially from business to engineering or vice-versa.
Product Managers coding is like Developers writing marketing pitches.
Why not? I've seen both sides working out remarkably well. It is much more of a mindset thing than anything else.
One of the major concerns with prototyping, at least in my experience and based on the general vibe I've felt from others over the years, is that clients will generally do some variation of "You have a working prototype? So how many days until it is prod ready? No more than a few weeks, right?" and that will be their expectation. AI makes prototyping easier, but makes this specific drawback much worse. Expectations are going to be misaligned, leading to many disappointments, and likely some number of developers taking undue negative outcomes. I'm not even sure if it will normalize to reasonable expectations, given that this tension never seemed resolved even before AI was in the mix.
This is a very interesting thought. We complain about having to fix some MBAs vibecpded slop, but it actually might be faster, easier, and alot less painful than getting them to try to explain their vision to us and implement what they have in mind.
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
You are right, but at the same time, if no UX designer is involved in the loop, what happens when they've prompted a prototype that looks good - and therefore eludes them to think it's designed good as well? How do we convince them that we need to involve a UX designer to fix the application flow?
Have my angry upvote. :-)
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.
That's odd: all the other AI proponents on HN recently defended their decision to produce AI written code by saying the coding was never the hard part, it was the translation of business goals to a spec.
You're saying even that bit doesn't require them.
Not in some ways. The value of working code that meets the requirements and generates revenue is very high, it's a gift.
This X a 1000.
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.
What is "IR"?
Incident Response
Agencies that focus on this sort of work are going to make bank. We’ve already gotten some work like this, and it’s just going to keep coming as people think they can vibe code their products. Like you said, easy money.
Lots of people are gambling on AI with big bucks. Some of it is promising but all those bets won’t pay off. I like to think of this mindset as being the human slot machine that people are shoving money into.
Without doxxing yourself or your clients, can you share more about how this plays out?
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?
Did you use AI to rewrite it?
Hopefully, as the alternative would be leaving money on the table.
Interesting!
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! :-) )
I'm sometimes puzzled by the way people use "circular" to describe an economic system pejoratively. (Not to suggest you are.) Seems like any worthwhile economic system is ultimately cyclical. Pulling resources into the loop is just a bonus....
Related "income tax when I earn the money, sales tax when I spend the money, taxes on my investment returns, it never ends!"
Yes indeed, because macroeconomics is ultimately a giant circle!
The problem with real economics is that it isn't, but since economists told themselves that it is, they have no interest in making it so.
Some of this is also going to die out, if the prediction of price increases for LLM tools and tokens holds true. In that case a lot of this software essentially becomes abandonware overnight because the actual maintainer was Claude or Codex.
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.
Are clients really paying for it? It’s really fascinating actually. Is it because the ”client” built it so they have sentimental value and sold it to themselves before you receive the request?
yep. exactly that
Nice the market is real and the problem is growing with the muti-agent work, The mess that AI do also create a nice opportunities until someone actually solves the ai result.
How much would it have cost to start from scratch?
Most devs will say less, but the reality is most of the time you build the wrong thing first, and the price you quote almost never gets what the client wants/expects and includes many overruns.
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.
As some already said; the real win is into having a business driven prototype; the work to gather those specs is already done and, generally, very costly when done in the traditional way. So from scratch if having to do all of it is more expensive; technical from scratch far less so.
So how does one find these sorts of clients?
We have be in business for 30+ years; clients find us.
Curious what your company is called (or website) if not secret, or privacy concern for you
why fix it when you can just easily re-write/generate it from scratch?
That is also fixing… The client does not care about technical things so indeed rewrite is usually the best way even if we do not tell we did (people are proud of what they made so they do not want to just get told it was thrown away).
> the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on.
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.
Well, this is not the first project that has this. Depending what llm/harness and how it is yielded, this happens, a lot. How often have you had Opus 4.x note; ‘485 failed tests, but those are not related to my changes so I will not dive into them’? You believe someone who does not know about tests or code or linting or compilers will push back on that? I know that’s not happening for a fact.
>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.
I have approx 40GB of docker containers spun up at any time in order to run the app I work on, and it only seems to get hungrier by the day. I have absolutely 0 problems imagining a single unoptimized Next app needing multiple gigs just to run, yet alone compile.
Linting is also trivial for LLMs. I’d argue linting is one of the easiest and best use cases for coding assistants.
This story doesn’t add up.
The person running the Ai needs to know to set up linting in the first place and have it be applied. It's not a default.
Ive had ai make code that doesn't pass a linter and make code look like hand aligned code.
Shameless plug - I've been working on a general repo linting tool alint [0], which helps keep a repo cleanly structured and hygienic - essentially a linter for everything in a repo that a language-specific linter doesn't cover. It also has some considerations for integrating/playing nicely with agentic coding [1]. This started as a replacement to a bunch of scripts I had in repos that did similar things - but more cohesive, readable and much faster.
[0] https://github.com/asamarts/alint
[1] https://alint.org/agent-friendly-linter/
You'd have to know what a linter is and tell the LLM to set it up though, right? Or just get lucky and have it suggest setting it up/set one up without asking.
The OP said that this was coded by a product person though. The product people coding and using these tools, who are spreading the pro-LLM propaganda, are not doing proper prompt engineering nor lint fixing.
> _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.
Oh sweet summer child...
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.
> No project "needs 10GB" to compile
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.
I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and understands all they do. I've had friends who go off on crypto related maths and I'm like "I passed that class, but know that I do not really know the subject you just talked about" ...
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...
And then you’ve got a third problem - that well north of 50% believe themselves to be in that last sentence of yours
Some people are very good at working with complex abstract ideas, but are terrible at signaling that intelligence to others. And some are fantastic at signaling intelligence and steering conversation toward domains of knowledge that they've studied (many political commentators come to mind), but don't seem to have processed those ideas very deeply.
It seems that way sometimes but maybe we're just biased as we tend to hang out among intelligentsia
Oh we can call that the 4th problem. The bias of the people perceiving the bias
[dead]
> 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.
One of the things I try to teach my kid is: You are going to have to deal with the fact that there are deeply stupid people all around you, without it affecting your mental health. Those stupid people might be in a position of power over you, they might be other kids in school (or coworkers, later), they might be the president of the country, they might be your neighbor, or they might just be obstacles on the road on your way to work every day. You need to learn how to cope and accept this, gracefully deal with them, and how to protect yourself from their stupidity when it might affect you. It's emotional regulation that smart people need to learn or they go crazy.
A lesson which I wish I had learned as a kid; I had examples to work from, but nobody taught me how to deal correctly. To cope and accept without it eating me up.
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…)
i hope you don’t actually refer to these others as “deeply stupid people” to your presumably young kids.
Of course not. I'm translating for HN
The older I get, the more I realize that individual variation in humans is truly enormous. Any trait you could pick is much more widely distributed than any individual human can see from their perspective.
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.
>video on youtube, of someone absolutely struggling at a task that had a built-in checklist
This sounds like Bog who records himself setting up Linux distros or configuring software
It certainly doesnt help that 50% of the population is below 100 IQ, and something like 15% of the population are below 85.
i feel fairly certain everyone has some set of activities or tasks they feel this way about
my wife and i have two non-overlapping sets haha you can imagine how that plays out
Same wrt my wife and I. She’s quite clumsy and to my assertion doesn’t always think things through. So it’s a bad combination for “accidents” to always happen which I think are very preventable and quite obvious to occur using her approach. A lot of it is just mental errors that I don’t make, but it’s not that I’m perfect I probably just make different mistakes (I think less volume too ;)
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.
Well, how hard should you beat yourself up over a mistake like that? If I forgot my groceries in the car, I'd just laugh about it being a silly one-time mistake. But if it happened twice I'd take it more seriously, and maybe make a note or something to remind me. I'm sure everyone has made some silly mistake like forgetting a jacket at a party or leaving a phone at home sometime. I think we should be a little extra forgiving toward others, because we'd so easily forgive our own mistakes
Does your wife have ADHD? She may not be physically capable of learning from her mistakes without the use of frameworks built to address the disorder.
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.
It's lonely being an outlier, especially in a trait that's so fundamental to how you see the world. Despite best effort, it's hard to relate to most people, and they especially find it hard to relate to you. The delta of lived experience is quite wide, often insurmountable.
I feel like this could be said about most human traits, on both ends of those traits’ axis. I’m not sure if that makes it insightful or obvious :).
>on both ends of those traits’ axis.
I somehow suffer from both simultaneously!
My smart friend said it's like everyone around you is slightly drunk.
Yup, I've known and met such people.
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 10x developer believes deeply that they are #2, but they are usually incorrect.
I would say there are two explanations for group 2.
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.
Or perhaps there is a 3rd explanation, spending all of your time with people much less intelligent is frustrating and unsatisfying, and being such an outlier, it's how most of your time is spent. Someone with a 142 IQ is to the 100 average in the same way that 100 average is to someone with a 70 IQ. We don't expect people with average IQ to spend all of their days with 70 IQ people (in a peer situation). (BLAH BLAH BLAH Multiple intelligences, IQ isn't a good measurement, etc)
If you're so secure in your intelligence relative to your peers, why are you responding to me?
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.
IMO if the person doesn't understand the ethical and practical benefits of humility, they are not that smart.
> painfully forefront of mind that they're smarter than most everyone around them
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.
These two sentences hit home:
> 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.
> Just getting the code to run on your laptop took a week.
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
And in the before times, you learned a lot and walked away with knowledge on the deps needed, connections, .env secrets, and cleaned it all up and documented it so the next dev would have an easier time doing it.
Yeah, that totally didn't happen the majority of the time.
Yes it did. That's how I learned a great many things throughout my career. I'm sure some people didn't pay attention or try to understand what they were doing, and didn't learn. That's on them. But most of us learned a lot that way.
I think it depends on how “before” we’re talking about.
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.
Bullshit I just pasted random shit from google in until it worked and then instantly forgot which combination of the 20 things I tried got it there.
Indeed, there were plenty of people doing just that. I imagine they get the most out of vibe coding. However, when it became a problem, an engineer was still required to fix it.
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.
The second tome I had to do that for the same project (new computer), I sarted taking very detailed notes when doing this kind of unpleasant, supposedly one-off things.
You're not alone on this, I've also felt the same way, and those knowledge often lives in people's heads or random slack threads, and with AI code it's even worse It just generated what looked reasonable at the time.
I kind of envy people who need to clean up after others. At least you're puzzling.
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.
You are not alone. I was in this exact same position at MSFT and I put in my resignation. I am an L63 but the work I was doing, was something an L60-L61 could do and I frequently felt I was in one of those Bullshit jobs (courtesy of David Graeber). I was paid handsomely but once the sign on stock ran out, I saw that I was staying in the job just for security. I felt like one of those Hooli engineers who were sunbathing at the Hooli office terrace waiting for their stocks to vest. I am only 9 years into my career and I didn’t see that as the optimal thing for my career rn.
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.
> I am an L63 but the work I was doing, was something an L60-L61 could do
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?
Have no idea why people here are picking up on MSFT’s levelling system? I didn’t invent it.And it actually starts at L59.
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.
>Have no idea why people here are picking up on MSFT’s levelling system? I didn’t invent it.And it actually starts at L59.
Because it's standard arrogance by developers not realizing that Microsoft Level system is actually pay bands and because it was developed in 80s, leveling system COVERS all jobs because pay systems didn't support different pay bands back then. So there are lower levels then 59, for things like janitors, secretaries and others who don't make as much as SWE.
It’s not like the op invented Microsoft’s leveling system. It looks like junior engineer is 59 and 63 is something like senior engineer. I know at google there is a very meaningful difference in the work and responsibilities expected between our equivalent of 63 (L5) and 61(L4).
Believing in that system so much to say something like that might be worse. Noting against the OP, that kind of Stockholm Syndrome can be found in my past as well.
Not sure I understand. Is your contention that the distinction between senior and non-senior engineers is fake and everyone's doing basically the same thing? Or are you just objecting to the (arbitrary) names Microsoft uses for them?
False dichotomy. Of course not everyone has the same experience/skills, but any corporate system of putting individuals to tiers has little to do with experience/skills.
That's just not accurate. I've seen these systems run at multiple companies, and in every case they had a lot to do with skills and experience. It's true that they're not a perfect classification, and I think it's defensible that some people prefer a system where this kind of leveling doesn't happen.
But the tradeoff is that career advancement becomes less legible in a way that other people often find frustrating. Why does Alice get paid 3 times as much as me to work on cooler and more important stuff? "Alice is L7 and I'm L4" is often an easier answer to accept than "Alice is a better engineer than I am" or "People with Alice's experience have more options than I do".
> That's just not accurate. I've seen these systems run at multiple companies, and in every case they had a lot to do with skills and experience
> I am an L63 but the work I was doing, was something an L60-L61 could do
So you and OP believe that, these systems are good indicators of skills, so much that the last statement sounds normal?
I was thinking like that once, as well, but I got disillusioned. These stuff tend to be gamed.
> Why does Alice get paid 3 times as much as me to work on cooler and more important stuff? "Alice is L7 and I'm L4" is often an easier answer to accept than "Alice is a better engineer than I am" or "People with Alice's experience have more options than I do".
Sure, that's why these system exist. They justify pay, that's all there is.
> So you and OP believe that, these systems are good indicators of skills, so much that the last statement sounds normal?
I do. I think it's good not to box people in, where certain work is only for (my company's equivalent of) L63s and an L60 isn't even allowed to try. But when I do see L60s try, they usually need someone to come by and intervene, because there are critical skills that come with seniority that they don't yet have.
To be more concrete, one thing I often notice in junior engineers I mentor is that they're very "task brained". They understand their job to be nothing more than a sequence of development tasks, so they struggle to understand what's happening or how to help when it comes time for important things that aren't tasks. One guy I knew was frustrated that he didn't understand how priorities are set, and yet would never read the customer stories in his email that the company used to set priorities.
> So you and OP believe that, these systems are good indicators of skills, so much that the last statement sounds normal?
Op here, yes I do believe, the levels aren’t perfect though. I believe in them because I was once L60 and L61, I knew intimately what was expected of me then and I can assure you the work I was doing as an L63 could be done by someone few levels down, which is to say I was underutilised. The team was also not the right fit for me.
Levels tell you two things, the scope and autonomy you get in your work and more importantly compensation. From the compensation view point, it does tend to be “gamed” frequently by developers hired from outside who might be out earning devs promoted within.
I think they measure different things. The ladder levels have to do with the type of jobs you can accomplish in a large organization. I actually find they translate reasonably well to nontechnical roles in corporate structures. It is of course tempting to think that good engineers will be high level in those ratings, but that’s really not what is being measured by levels. A certain proficiency is required, but it’s mostly about responsibility and ability to take on tasks of a certain scale or organizational complexity.
All this to say it is absolutely reasonable for the OP to complain that they are being underutilized at the role of senior being given small byte sized projects of for no other reason than that this would prevent future growth.
[flagged]
Entry-level software engineering at Microsoft starts at L59.
I learned in my 30s that most of the software profession works on boring projects. Uninteresting, low value code, for a barely-working product, used by customers who don't really care, in a low-stakes market that doesn't reward excellence, rigor, or quality. If you can find the rare company where this isn't the case, go for it!
What a flex.
At first I thought "medior" was a strange typo for "senior", but on seeing it twice I had to check - apparently it's used in some parts of Europe to mean "mid-level"
It's a Spanish/Portuguese thing, so south America also. I kind like it even though I was originally nonplussed by the term.
I've never heard it before, but immediately understood it and found it a useful term for something I didn't have a single word for.
Very normal in The Netherlands, was kinda surprised to learn it's not a thing in English speaking countries?
> I just cannot push myself to care about the code this company makes.
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.
> basically threatening me to take more ownership, do more work, for the same pay
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.
I'm not the best friend. I often don't do my part to hold up my end of social contracts. That said, I'm a fairly decent low-commitment penpal. The internet is the place where I vent as well, and it often feels like a void. It doesn't scratch that therapuetic itch and therapy proper doesn't appeal to me.
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.
Take a good look at the codebase you're working on. My guess is there's plenty opportunities to clean up after others, or even yourself.
I love this kind of comment. It's so human. Good luck, friend.
For a boring codebase how is your company not trying to throw tokens at it? Not saying its the right choice but definitely the trend I am seeing.
Perhaps they don't like slot machines
The first few sections hit me. I think that I used to be a “rockstar”, until I realized it wasn’t a good thing. Perhaps I could get things done 10x faster than my colleagues. But at some point I realized it wasn’t because I was 10x more productive than a normal person; it was that I worked in a way that made the normal people around me 1/10 as productive.
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.
I've definitely shot my own foot off in the past by implementing things in a rockstar manner. In my case, it typically involves me over-abstracting something that really doesn't need it. Or building something for use-cases that never actually happen. So I have to try to keep YAGNI and KISS in mind whenever my mind wanders into over-abstraction territory.
Copy paste is a very, very under appreciated tool when it comes to programming.
You can always abstract later, but once you start it’s terribly difficult to reverse.
The ironic rockstar comparison is very good. The classic rockstar only cared about "new" technologies and wrote spaghetti code, the new 100x AI rockstar can do more damage.
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.
I’ve cleaned up after outsourced code and it has a different flavor to AI rockstar code. In the former, you can see that the developer only care about the current ticket. After every merge, it’s a flurry of bug fixes, because they always break something unrelated. And that’s due to bad design, you will see a lot of copy pasted code and unused code.
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.
This is such a low value article lol
I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
there is certainly code that sucks; but the article strikes me as someone conflating "code that sucks" with "code that is complex and big and takes a while to get used to".
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".
tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes.
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.
Almost all opinion pieces are like that. They lack information density, but some readers (like me) like them that way. Otherwise, I'd only read one-line summaries.
I guess some people don't like articles that don't deliver a skill.md to solve a problem.
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.
I mean, go look at the author's linkedin and github. They're a "dev" with 20 years of 1 year of experience. Not a software "engineer"
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.
There is no universally accepted distinction between developer and engineer.
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.
This isn't about distinction between literal titles. But continue missing the point.
Yeah it is. The meat of your post is textbook gatekeeping. "This is a dev, not an engineer."
You make up an false dichotomy. The differentiation between the title and the supposed skill level based on title, is neither true nor helpful to make your point.
There's no false dichotomy. You're just choosing to miss the point to argue semantics.
Well you could make your point clear, instead you keep acting like I am hostile.
I was such a fool to lean hard into two production engineers to build the infrastructure around the two very profitable projects I built. I could have made so much more money spaghetti coding it all like a 10x boss and then jumped to Anthropic for one of those sweet 9-figure comp deals. Stupid, stupid, stupid me.
At least that's my takeaway here.
Don't call them rockstars - call them "resume-driven developers."
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.
Or people with not enough time, not enough resources and too much overtime already to kill off any happyness in creating the product.
As much as it's true that a novice will generally use AI to build a sloppy mess, I've also had success unsloppifying through some careful prompting.
Yeah, v1 is sloppy, then I tell the LLM to clean it up. Every 1 prompt of building tends to require 1-5 prompts of clean up. Simple, fast, clean good code.
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.
> Every 1 prompt of building tends to require 1-5 prompts of clean up. Simple, fast, clean good code.
I have found this to be very effective as well. However, it's so easy to do, I can't imagine they won't build it in.
The harnesses will improve and the loop of "self-review, judge what needs clean up, do the refactoring, repeat until clean" will get included in the one-shot. They are already doing this somewhat, they'll just get a lot better at it and as the models get faster and cheaper to run, the refactoring churn at the end of each task won't even create a noticeable delay.
I do not think the high-level "taste" knowledge that I've built up -- when to break something off into its own service, what to put in the DB vs cache vs queues vs blob storage, how to isolate important logic in pure functional layers so it can be tested and validated independently -- is any more "unlearnable" to AI than the stuff I previously considered impressive that's now one-shottable like "write a Prolog implementation from scratch".
They have definitely built some of it in.
And yes, right now you still need the architectural and system design knowledge because the LLM will fuck that up. We'll all find out if that continues being needed in the future. From what I understand about LLMs and how they work, I doubt it, but also, yeah, I doubted it would've gotten this far when I think back 2+ years ago.
Also, maybe I should be clear, I pretty much never one-shot things. My sessions with claude or other cli tools always starts with a bit of a conversation until we converge on a good plan, claude builds the code, we discuss some more, then we iterate.
The chasm is 1-5 prompts wide?
Knowing what you're doing holistically is the chasm.
The distinction between developer and engineer is obviously that one adds "make no mistakes!!!1."
I wish I had current-day AI (and a big credit card) for my previous job, they had a big legacy mess made by a productive but not very good developer, but my job was to rebuild it.
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.
Any tips on how you unsloppify things? Are you using things like claude.md/copilot.md (or similar) to guide better, do you have specific types of prompts that you run, or do you adjust your code review practices in some way to more efficiently review lots of slop code?
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.
I accept that for every prompt of building I'm going to have 1-5 prompts of refinement.
Once the LLM tells me "Okay, it's done, everything works" I always as it to do a thorough review, I tell it to split up the work among sub-agents with each one taking on a specific responsibility (look for code smells, look for bad architecture, review the data access model, DUPLICATE CODE, testability and unit testing, etc.)
After a certain number of revisions and reviews you'll come to accept the shortcomings it comes back. Usually there will be specific design decisions you made that the LLM keeps bringing up, once the review only brings that up and maybe some other minor issues it's time to move on.
I don't overly rely on markdown files and directions. I don't rely on tooling around it either. I just don't trust the LLM when it says "all done", tests pass, and deployment works. I make it to multiple reviews and iterations even when it thinks it's done.
I also ask it to explain the system back to me. Obviously it should understand the system just by reading the code. But somehow, explaining the system back to me seems to make it more effective. Then I'll ask it questions about how I should make changes to the system. Sometimes I'll agree, sometimes I'll disagree and offer an alternative and ask it to assess the alternative. Having this entire conversion in its context seems to make it way more effective at refactoring/unsloppifying code.
> Any tips on how you unsloppify things?
Understand what you're writing. If you never build up the mental model of what the code is doing you'll never be able to discern what is slop and what isn't. There are no shortcuts.
Piling more prompts on might get you to the same end result, but without understanding you'll never know when you're there.
Absolutely. I really don't think the future will be humans reading and picking apart an AI-generated codebase, there will be tech debt agents or whatever running overnight.
I think you misunderstand why tech debt lingers around. It's not a capacity or capability problem.
Organisations just don't want to deal with the accountability involved with "touching cold code". Whether it's a human or "AI agent" doesn't change the "It worked in prod, you touched it, you broke it, never touch anything again" dynamic.
That's one dimension of it, but in the context of this thread we are talking about how maintainable a codebase is for other humans. If your codebase is messy you depend on a few key employees and it might be hard to onboard new ones, so there has always been financial incentives to reduce tech debt.
> so there has always been financial incentives to reduce tech debt.
Yes. In practice, this does not weigh against organisational resistance.
AI really makes it worse by adding an explicit numerical cost to doing anything.
Um, no, actually AI makes it better because the cost is lower now. I'm not sure what point you're trying to make here, obviously organizations already fight against tech debt all the time through a variety of means?
The point there is that it is MUCH easier to get corporate to agree to something when the cost is nebulous and being paid anyway. If you get a senior dev to clean up some tech debt, how much did that cost the company? The dev will have some multiple things at the same time, so you can't cleanly assign a number of hours, maybe multiple people are involved. It's practically just an unknowable. Practically, $0.
Anthropic will sent a concrete number bill.
Exactly this. When I reject a refactor PR (or ideally, _before_ there's a PR), it's not because it's a bad idea, per se.
But there's risk associated with every change, and it takes time to review, QA, monitor the rollout, communicate to stake holders, etc.
The refactor itself may be the smallest part of it.
So your proposal to handle tech debt created by "AI" being unable to do good engineering is... throw more AI at it? There's a saying about the definition of insanity which comes to mind.
or linters
Code that is written will have to maintained often by someone else than who wrote the code. So if one write code nobody else understands its an eventual maintenence failure.
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
Its never been quicker or cheaper to build something with bad foundational assumptions and principles. Its never been easier to add features whilst not recognizing that it comes with added responsibility. And it will never be too late to hire me for your V2 migration project.
I think this is fine? Code used to be very expensive to generate, now it is cheap. Building glue logic between well-defined, well-documented APIs has never been easier or faster. There is a time and place for throwaway code that quickly automates a task. It is fast food to fine dining -- not everything needs to be a Michelin star experience.
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.
I think an important caveat is that LLMs are prone to writing unnecessary code, i.e. there's almost a superfluity to it, that at the same time makes it less straightforward and more prone to unnecessary side effects, which it does catch and handle, but that again expands code further.
Then you add an agent that goes through the code and simplifies it. Before every sprint, you get the agent to simplify whatever it can without losing fidelity.
It's really that simple.
I should probably know better than to interact with a 3 month account called "freediddy", but here we go.
> Then you add an agent that goes through the code and simplifies it
Can you? I just asked Opus to generate a sum function.
Then I asked if it could simplify it further. I would expect it to say this is simple enough, or just use the actual `sum` function, but it did this. That is, at best, a useless but harmless change.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.
> If you ask it to simplify something, it will make changes whether it needs to or not.
This is false. You can prompt it to only make changes that will have a material effect on the performance. You can create performance tests and have it run the test after every change and if nothing changes then back it out.
You're not thinking creatively enough about how to use AI to your advantage.
> You can prompt it to only make changes that will have a material effect on the performance
Nobody was talking about performance. There's too much handwaving in your comment to really go further.
"Just have a stochastic machine redo the code with no oversight"
This is an utterly terrible idea.
There's always oversight, that's just something you wrongly assumed.
One argument I heard from a college that the experimental llm written code (not production ofc) should be "write only" - you specify the requirements and constraints and let the machine figure it out - you specifically avoid "fixing it" or "cleaning it up" or reviewing the code because it disrupts the state of this discrete optimizer (over code). Not saying that it is right, or that it should be applied in prod, just noting that this is one potential way to go for non-critical code with clear "win conditions".
I kind of resemble the Rockstar portion mentioned... that said, I'm a massive fan and prominently defend KISS/YAGNI over most other principals... Not the there are never abstractions, but IMO, abstractions should make the rest of development easier and not just hide the common points of use/access behind painful boilerplate or interfaces.
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.
Oh, yeah.
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.
So far my take has been that there is code that isn't very important, in the sense that if it works it works, it won't be modified or extended much if at all, and it's easy to verify that it works as expected. This type of code I'm happy with letting the AI go wild on.
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 never seen code that is unimportant. It’s either being used or not. If it’s boilerplate, it can be abstracted away. There are domains that are riskier than others (debug logging vs crypto for auth), but sometimes bugs in a somewhat safe place can lead to some catastrophic issues (you do not have to break a crypto algorithm if the key can be leaked via logging).
As I said, I think it depends on what's being made.
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.
IMO that is not a rockstar developer, but a junior developer rocking LLM agents.
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.
This is why I always work at a new company at least 6-12 months before making any major changes. I use that time to get into the flow of how things are being done (even if I think they are not efficient). I may make some suggestions but that's it.
Of course, I'll probably never get hired again anywhere so it doesn't matter anymore.
In 6-12 months you could ship a new product or a large feature. This strategy might actually put you on a performance improvement plan instead.
A company/manager that would PIP you during onboarding doesn't understand the craft and does not deserve you.
I heard this kind of rockstar stories a lot from my friends but I never encountered one in real life. I worked in small and big companies and no one with allowed to use any obscure language or tooling. I count myself lucky.
You need a CTO to lay down the golden path.
.NET 4.8 only, vanilla JS only, MSSQL on-prem only, IIS only, no Azure ever.
I'll see myself out and return when I locate my "Developers, developers!" T-shirt, but I might find another job first...
I’m sure the general premise around AI-generated code is accurate. That being said, I’ve definitely had interesting moments where e.g. Claude produced code that matched the pre-existing codebase quite nicely, and slowly started building up its memory of how new pieces fit into the codebase in an idiomatic way. Then again, it started to throw in Tailwind-based CSS classes all of a sudden, because it assumed that Tailwind had been set up (it wasn’t).
This is where determinism is useful to help avoid these. A tool like Archiet does the determinism side of things and generates working solutions, which can then be given to a human or AI to sort out any gaps. This saves time, tokens and the need to clean up after AI rockstar developers.
Archiet also ships with the right architecture documentation, without the right architecture or specs-driven documentation, AI rockstars need clean up.
> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of.
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.)
The point is that developers like this purposefully introduce new languages and frameworks that only they (and maybe not even they) fully understand, so they make themselves harder to replace and ensure that they appear ahead of the curve. (Then they get bored and leave anyway.) It's totally valid to introduce new technologies when the problem calls for them, but doing it in a way that's purely detrimental to the rest of the team is very selfish.
Exactly my point. Learning stuff is fun. But if you're going to introduce new technologies or programming languages into a system, you need to make sure it suits the skills and experience of the rest of the team. Rewriting the company's admin dashboard in Elm, not letting anyone else work on it, and then quitting - that's just cruel. (Elm's cool, but you know what I mean..)
There's a difference between introducing new things because they are a well thought out appropriate choice and completely ignoring the standards of the company because you want to do resume driven development. I believe the author is talking about the latter.
I've worked with folks like the ones he cites. I've been jealous of their ability to absorb new things, but then you realize they're absolutely allergic to any kind of maintenance or responsibilities beyond "build, build, build".
Just look at the author's accolades. They are very light.
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.
Like many other critiques along this line, I think the answer is: Yes, for now. For example, in my own code base, I have an agent dedicated to maintaining a sane data model. This agent reviews the plan in advance and again during code review. And then I review the code myself. This seems to be sufficient for my work, at least. YMMV. It was a good post though. I enjoyed the take and the writing.
If you're reviewing the code yourself, then I don't think this article is about you.
Exactly right.
>Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine.
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.
The fact that LLMs fundamentally do not, and cannot, have understanding or reasoning. I don't think you can produce craftsmanship through sheer volume of throwing stuff at the wall and seeing what sticks.
It’s literally no different than how to clean up old projects over the last 30 years of software engineering
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
That's because the businesses got into the habit of new C level means new project, obviously the old code is bad.
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)
Yep, I worked at a small company that got bought by a bigger one. We had a solid if aging product to support which was one of the big players for the niche. Once there was a leadership change, 2/3 of the devs got put on building a replacement software. Then in a couple of years our subgroup got spun off and sold to PE and the v2 project was shelved for another brand new design to align with the new ownership. I left just before the spin-off, but witnessed how the original software slowly rotted away and all of the marketshare dominance we had for that area slipped away.
Devs love new tech and the product people love something new to put their stamp on, but chasing that high can be ruinous.
I think that’s actually the product incentive structure inside Google iirc
I think that’s right
I have seen over the past decades this concept of just reusable throw it away code becomes the norm and that’s why also I’m always surprised to look at people complaining about AI development and it’s like yeah it’s just the same as all other development at this point everything‘s just frameworks and throwaway code
I’m not even mad at it but it’s just one of those things where people are like “I’ve never dealt with anything like this”
But it’s the majority of operational software engineering since more or less forever
I think its also the pyramid of age - as you work in this field a lot of people burn out, the field was significantly smaller in the past and has shown huge growth, and the young say "yes sir!" and work nights and weekends on the fucking stupid idea while the older folks push back.
So in general most of the people have worked on a bunch of greenfield development, thought of the project 2 years old as aged out entirely, and never thought you might "maintain" something at all.
In my experience, this is because a modern engineering organization is laser focused on delivering value. Value rarely aligns with refactoring an existing, working implementation. If need the data, you build an integration on the output data. If something isn’t working well enough, you fix that one thing, you don’t refactor half the application.
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.
The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:
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.
It's different because LLMs can generate code that immediately needs to be refactored at speeds that were unfeasible before. There was a practical limit on the amount of technical debt that could be created in a day before, now that limit is 10x or 100x higher. It can be generated far faster than it can be fixed.
Then code factoring was never the key problem was it?
It was organizational discipline
Again this is the same problem previously…organizational lack of discipline means you get some diva to build some un maintainable thing and then you have to go back and refactor it later
The problem is the same the speed is different I acknowledge but both our organizational problems and have nothing to do with writing code or technical
If a neighbor leaves their dog's poop in my yard I have a problem. If someone builds an industrial scale dog poop delivery mechanism that delivers tons of dog poop to my yard every day I have a different problem even though the underlying basics are the same.
I think we’re in agreement
The problem moves from situation to structure
> how to clean up old projects
What’s “new” is indeed the “new” bit in cleaning up new projects.
You're just witnessing "Software Developers" cry out over LLMs.
"Software Engineers" are embracing LLMs and getting shit done same as before.
AI codes worse than even the most egotistic prima donna. I see future business opportunities in cleaning up the mess being created now.
Okay so "belt and suspenders" is an LLM-ism, it's not just me who recently learned that expression.
No that expression has been around a long time.
In the UK we call it 'Belt and Braces'
https://wordhistories.net/2018/12/13/belt-braces/
We are always the rockstar of someone else
Opening paragraph is not the profile of a rockstar developer.
At least not the rockstars I had the pleasure of working with.
"I am a rockstar developer and this characterisation is unwarranted" -- thought bubble emoji
Don't worry about losing your job to AI. We will have a lot of mess to clean up.
One thing I’ve found helps is leaning a bit more towards a modular almost microservice like model with clearly defined interfaces. Gives you a bit better control than a huge unified ball of AI spaghetti code
Is the "Cleaning up after hundreds of AI rockstars" part a description of an actual experience? I don't feel that it is. I would expect much more swearing if it were the case.
It could be but there’s always been so called “10x developers” who just make 10x messes. I think it’s the continuation of an existing phenomenon.
https://www.tyleo.com/blog/the-terminal-star
This is a confusion that you could not have predicted, but primed by your comment, I expected "terminal star" to refer to a suggested predecessor of the AI rockstar. No, it refers to the animated Claude Code star :P
This was my take as well.
I don’t think the analogy between rock star developers and LLMs bears out here. Like any other tool, AI abides by the basic reality of garbage in/garbage out. If you don’t make sure the LLM has sufficient context then you get what you get. Same point with vague prompts.
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.
The post seems to not address the fact that different product phases exist which in turn affect the software. Similarly, teams are different and get assembled for different purposes. There is also a difference if software was created in the past 24 months vs past 10 years. It is very easy to attack decisions made which look messy now, because many reasons. Everything looks obvious in hindsight. And then making it ad-hominem like does not sound smart, it is a clickbait, the issues are usually more complex.
this resonates with me, but fortunately one difference between LLMs and rockstar developers, is that LLMs will at least _try_ to explain what they are doing, and why something has to be certain why. I've gotten quite a lot of mileage from being a five-year-old with Claude and just asking "why" until I'm satisfied
[flagged]
This is why I like a bit of 'wet-kiss'es while working on projects.
This article feels written by AI.
This cascades of short sentences are a giveaway.
100% wasn't. I use Derek Sivers' approach, search "writing a sentence per line", and I try to keep my sentences short intentionally. If you view source on the HTML you can see the line breaks.
Sometimes I wonder if any of this will even matter in a few years. How many of us compile code and then have to clean up the assembly, or even worry about what a compiler generates as long as it's correct?
We are finding out that ram is neither cheap and unlimited.
A great many people do that.
Don't bother, they love AI slop here on HN, and will cope hard on the comments
I realized recently that this all has an unsavory element of ego to it. It doesn't help that LLMs have basically been trained to talk like they're performing in a movie, getting creative with techno-babble that sounds both plausible and exciting. I recently had to review some slop where the LLM was using terms like "event storm" to describe how some callbacks work, or "gating-solve" to describe a simple change to an if statement. Combine that with their sycophantic tendencies, and it really can make you feel like you're a star hacker in a Hollywood movie.
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.
Funny, the element of ego I'm seeing are the devs that can't accept that LLMs write perfectly good code at a faster pace. It's always "slop" this or "vibe coded" that. Meanwhile I've personally shipped multiple apps and professionally we've done HUGE things in these past 6 months using LLM tools.
Sounds like the aforementioned rockstar dev may have found their way to comment and miss the point.
When I was less self aware, I'd say similar things: my coworkers/manager can't accept that I write perfectly good code at a faster pace. Doesn't matter whether it's good or bad code-- the coworkers have to collectively understand it in order for it to be maintainable.
Oh really? Link them.
Not sure what I'm going to link to in my professional life, it's all private repos. We have a large microservice architecture in AWS. We've made major changes and the LLMs have helped every step of the way. Migrated our whole auth system from being regional, resulting in customers being limited to specific regions or managing their multiple accounts across regions, to a global authentication with data residency built into accounts so that they login to what looks like a global app now. No more uk.example.com, eu.example.com, ca.example.com and us.example.com. It's now just example.com, but data residency (and currently data processing too, but that's another thing we're working on) stays the same. This isn't some small app, this is the main product at a company with nearly a Billion in ARR.
For personal projects, only one thing could I actually show - vaicayo.com
This app was originally started pre-llm. I just wanted a centralized place for my wife and I to organize our vacations. I built out the basic crud for that a long time ago and we used it, but then llms got popular. I first integrated it into the app, now I could get it to generate vacation plans completely with the llm. It did okay.
Somewhere between 3-6 months after building out llm features claude code released or I became aware of it enough to start using it.
I rebuilt the whole thing. So what was once a spring boot app running in AWS ECS with alb + cloudfront (and yeah, some sqs+lambda python processes, s3 buckets for storage, aurora rds for db) is now a super lean apigw + lambda + dynamodb stack with a svelte frontend. I went from paying $20ish a month to $0. I also built a flutter app for android and ios that utilizes the same backend as the frontend webapp with feature parity. It's not really a production app, but it could handle it fine, it's completely cloud native and hands off to operate. And let me be clear about the rebuild, it's not a 1 for 1, I think all that I kept was the domain model.
For features, it's mostly just a crud app. You plan your vacation in it. Outside of that there's the ability to take pictures with the phone app that auto-sync (there's a bit of complexity here, the phone app only syncs pics when it's on wifi unless you change settings to allow syncing on cell network, images are cached locally with a ttl, uploads will run in the background and queue up, uploaded images automatically resize/compress and generate thumbnails from an s3 event lambda). The other more complex item is email ingestion, when I get a reservation email I forward it to the app and it automatically processes it (the only place I use an LLM in the app right now). If it can't discern what the email is or which vacation it goes to it goes in a travel inbox so the user can route it to the right vacation and object type. Oh I guess the paywall is a little complex. I don't advertise this thing but I have left user registration open if anybody ever wanted to use it. I did lock the email parsing behind a paywall and I limit photo uploads for free accounts.
So frontend, backend apis, flutter app for android and ios all built 100% by llm.
For code quality, the frontend is okay, the backend is pretty clean but could use some things split out into domains, and the flutter app has some work to do (recently found a couple code smells). But there's no issues adding features, shipping, etc. I literally finished adding some of the photo syncing features in the flutter app last night.
Other than that, I have created 5+ other personal projects that I wouldn't have without an LLM. I've made 2 godot games, a private scribbl.io clone with a few extra features that myself and my coworrkers play as a "happy hour" on fridays, tons of ci/cd build stuff and terraform (using my own personal modules, so I guess that's not 100% llm coded if you consider the modules), and then a couple other simple apps.
I enjoyed hearing about the stuff you've done.
Would you mind talking about your experience making the 2 godot games? Which agent and model did you use? I've been wanting to dabble here and interested to hear stories.
Got distracted and didn't touch on the godot specifics.
I start the project in godot, then I talk to an agent to define my game and give details. I tell it to have a conversation with the end goal to be building a CLAUDE/AGENTS/GEMINI markdown file for future agents to help build the game.
I made a [single player top down naval game](https://www.youtube.com/watch?v=FQUTbeQ8-oA) and an online multiplayer game (that I'd like to keep to myself for now).
I mostly used free assets for the artwork. I made some myself in aseprite. I utilized LLMs a tiny amount to generate some assets, but typically those are more of a jumping off point than game ready art assets. This has been what's slowed me down the most in making games.
I use any of the 3 big frontier models; claude, chatgpt, gemini
I only use the cli tools; claude code, codex, gemini cli (which is being phased out for antigravity cli soon)
I've generally had the best luck and enjoy working with claude the most, though that may be because that's the model we use at work (from aws bedrock, we pay per token and always have). Gemini and codex have flip flopped on 2nd place, though right now I'd lean Codex.
On my personal stuff I typically use codex or gemini because those two I have subscriptions, claude I still pay per token but through anthropic API like 90% of the time and 10% of the time through bedrock.
> You can lead the engineering, and guide the LLM to generate small snippets at a time.
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.
The job when picking up a codebase made by human or machine always involves reverse-engineering the design intent from code. That's especially hard for LLM-generated code because the path to runtime was so rushed.
> 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...
One of the things that annoys me is that we could know what the original intent was, and indeed the preferred form for modification: the prompt! Yet for some reason there's no standard/tradition/expectation that people commit all their prompting.
Perhaps I should start trolling people that your software is not truly Open Source if it's not Open Prompt.
In my opinion the problem rather is that most managers do not value elegance of the code, and most programmers are either too obedient or too clueless to dissent to management. Also, most team members don't want to understand highly elegant code and its inner beaty.
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.
The photo in the article looks like AI slop but isn't - it was taken in 2019. It took me awhile to convince myself everything in it was real.
> Building software that lasts
Nah. Now everyone can build single purpose, single use, throw away software.
Then reconstitute it later, even if slightly different. Nobody cares because it's small.
I've said it before, I'll say it again, I'm convinced LLMs will be the thing to convince software engineers to get it together and create a licensing board.
Somebody wake me up when the ABET SWE PE is back.
That makes as much sense as having a licensing board for hammers or socket wrenches or welders.
Please write a manual on how to cleanup after AI rockstar managers who think they can code.
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.
I run a whole ass month long class on exactly this
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
> Please write a manual on how to cleanup after AI rockstar managers who think they can code.
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
It's the mandate from top-down. Of course it's a people issue, the problem is that the people creating this issue are exactly the ones paying us.
My manager got the mandate she needs to start coding, she doesn't want that, no one in our team wants that, she's a great manager exactly where she is right now. Nonetheless, we are helping her to code to show something for the higher-ups so she can keep her job, we really don't want to lose one of our best managers because some C-level is anxious about AI...
Even if it's a mandate top-down, you can:
- show increase in errors and outages caused by this approach
- integrate manager changes into your CI pipeline (coding / reviewing / testing / documentation)
- discuss how your manager can do the changes they need to do without sidetracking all other work
Make it indeed about the money: coding by PM + fixing what was coded + dealing with fallout is greater expense than coding by PM + automated guidelines + reviewing what was coded.
That is - if the environment you're working in is reasonable and it's not a power play by your PM
I don't know why you assumed it was a PM thing, the mandate is for EMs to be more "hands-on".
On your points:
Manager changes are always going to go through the usual pipeline, we are 10k+ people so there's not even a way to go all gung-ho pushing stuff. They need to be reviewed, approved, etc.
But we don't want our manager to code, nor does our manager, so we are just helping to cross the bare minimum expected from higher ups. For my team it's not an issue with our manager's code (those will be at max small fixes, well-defined, the most trivial stuff), the issue is they are mandating managers to do it.
I don't know what size of company you work at, where I am at there is simply no incentive for me to do all the extra work to show execs/higher management the issues cropping up.
I don't even have access to them, I have to pass through other channels, those might compile reports from many people to try to present a case, if they get to present a case then there's a whole other discussion to happen at director/VP/C-level about what they want to do, and since it goes against their big mandate it most likely will just be thrown out.
In this structure I have no motivation at all to go out of my way to perform data gathering/analysis, wrapping it all in a nice concise document explaining what the data means, potential remediation, etc. just to become a footnote in someone else's document that ultimately will not change anything from the VP/C-level mandate.
I assumed that as it was hitting too close home (both PMs and EMs were expected to use AI, with PM trying to code in solutions that they didn't have expertise nor domain knowledge to deal with; EM was prototyping solutions that had access to prod DB that were shut down as soon as we found out). I can only symphatize nonetheless and thank you for giving your PoV.
[dead]
Because most people, in most parts of the world, are not allowed to question whatever their superiors do? And, yes, unfortunately are also expected to clean up after said superiors' messes. Of course it's a people issue. AIs just make people issues worse in new and entertaining ways.
100%. You don't "clean up after them." You make them clean up their own mess. You refuse to let a mess into the system in the first place.
Same as it ever was.
The only difference now is that if you let it happen, it'll happen 100x as fast.
When I was mentoring junior devs, I would start by fully reviewing their code. If they had a ton of mistakes more than a few times, I would only review until the first mistake, and then reject it. Repeat, repeat, repeat, until they got the picture that I wasn't going to let mistakes through, and handing me a ton of mistakes was going to waste more of their time than mine.
I let the pain be their pain, instead of mine.
But good developers, I'd help them by doing a more thorough review and not wasting their time. Good developers were the ones that made an honest effort to follow the requirements to the letter and test their own work.
We further emphasized this by having a very simple coding test during the interview, and the only thing we cared about was whether they followed the requirements to the letter. There wasn't a lot left to the imagination, and the requirements were very clear. Anyone who missed them wasn't someone who would do well with us.
That very same test will help filter out a lot of AI-braindead candidates that don't check the AI's work as well.
Actually, I wish I still had the exact test so I could throw it against an AI and see what happens. I'm a little afraid that it would pass it too easily now. I'm not sure how I'd fix it to prevent them from just using AI.
The code is AI reviewed, and I was ordered to change repo setting so a single AI review is enough. I've tried suggesting a lot of things, but it is not on my paygrade to allow or disallow something, only recommend.
No, no, much better: make it a SKILL.md ;)
Rockstars, AI or not, were 'successful' because they defined how success looks like. They created that perception and called it success. Not many people would bother going beyond the perceptions. They don't know how success or good code looks like. Rockstars gave them the playbook.
In reality, sometimes I wonder if there is really anything beyond perceptions.
Sure there is. Actually getting to the moon.
Nice Blog!
Story time! I Worked with not just a "rockstar" but what I suspect was a "superstar" for about three years at my last gig. It was a small company with about 3-4 developers at any given time and we worked on an embedded Linux product in a moderately safety-critical industry that had a messy ~25 y/o codebase and a custom, roll-your-own Linux distro on custom hardware. Our "superstar" had been with the company for ~10 years and due to really high turnover I was the most senior of the rest of the staff with 3 years. The manager of the software team claimed to have 10+ years of software development experience on his resume and LinkedIn, but would ask CS 101 questions in our software planning meetings.
The basic workflow adopted by our manager was thus:
You might think, with our superstar developer, a workflow like this would be possible. Honestly, I saw him do things (pre-AI) that were astonishing. He would work a weekend and add a feature I thought would take 2 weeks. He created a re-write of our main product and demoed a completely new product using the same hardware by himself in about 6 months. He would take feature requests not assigned to him and just do them before the assigned developer was even finished planning the feature. The sales team would come in with a pitch for an insane new feature idea (like add a Farsi version of the UI) on Friday, the rest of the team would attempt to push back on it, then he would check-in a semi-working version of that feature on Monday. For these reasons our manager loved him and would always ask the rest of the development team why we couldn't keep up. It was demoralizing and frustrating. At the same time, as a company, we were mostly unable to get very simple changes out the door. Most of the insane features we added died on the vine before getting to the customer (but the code would remain polluting the codebase). Any bug that was fixed would reveal 2 more serious show-stopping bugs. New software releases were regularly regressed: they would break one of our customer's use cases and because we never created basic functionality like OTA updates, we would fly a tech out with a flash drive to revert all the software. We worked on 3-4 new products an not a single one ever saw the light of day. Our company github was littered with dead, abandoned, duplicated repos.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:
I think about him a lot when I think about companies going all in on productivity maxxed vibe coded AI. I think that under better management that restricted his impulses and gave him more structure, he could have been a great asset to the company. Unfortunately when let run wild over the company codebase he was an absolute menace and ultimately led to less actual useful work getting done and an erosion of customer trust. I think this might be the reason we are getting two diametrically opposed experiences with AI: it is either going to destroy your codebase or deliver features at an astounding pace, and I think the difference is the actual technical knowledge of who is managing these projects. My guess is that there are a lot of places with middling or non-technical management pushing AI coding that are going to be in struggle city in a year or so and not understand how they got there. "But AI was making us so productive!".If you're just starting to learn programming, people will tell you that maintainability is important, and they'll mention John Ousterhout's concept of the "tactical tornado" as an anti-pattern.
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
I believe GNU Emacs was created in 1984 or 1985, and it's still going strong. I guess it's not easy to work on it due to the long history, but I understand it's been refactored as the developers went along.
I think those people are great. They work silently behind the scenes for the sake of others.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[flagged]
[flagged]
Hmm, ~30 years ago the compilers that I was using were generating generally fine assembly/machine code. Some of the other tooling was more troublesome: cross platform high performance numerically stable code and C++ static template deduplication paid for a lot of beers around then, and I needed them.
[dead]
Compilers are deterministic and they actually possess domain knowledge of what they are trying to do. AI models are non-deterministic, have no real domain knowledge due to lack of an underlying world model, and their way of "writing" software is to spew out something that looks like something that they have been trained on, then iterate on it long enough until it has reached the level of being barely runnable.
People say "determinism" but I don't think that's actually the property we care about. For instance you could imagine a compiler that makes heavy use of superoptimization with random search and it would still have the ineffable quality that LLM codegen lacks. I think what we're actually trying to say is that the compiler preserves the formal semantics of the source language in its output, whereas English text doesn't have any such formal semantics to preserve.
[flagged]
I don't think you know what deterministic means
[flagged]
[flagged]
It's not ok to post slurs to HN and we ban accounts that do it, so please don't do it again.
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Has nothing to do with that. If someone is looking for something, they can find it anywhere. If you want to say "prevalent in [place name]... etc" The emphasis is on the tech culture. The factors are multiple. Parallel: Do you know about chauvinism, etc.?
Agreed. There's no place for racist slurs on HN, especially when they're posted from behind anonymous usernames. It's often the kind of thing people wouldn't dare say under their real name if their livelihood depended on it ;)
Nah man that's not it
[flagged]
[flagged]
[flagged]
Bet. Link it lol.
[flagged]
We've banned this account for posting a spate of abusive comments in recent days. You've been here long enough to know this is unacceptable, and when users act like this we have to assume they want to be banned. If you don't want to be banned, you can email us (hn@ycombinator.com) and commit to observing the guidelines in future. https://news.ycombinator.com/newsguidelines.html
[dead]
[flagged]
Yeah, that's what I thought lol
> Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of.
> 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?
I'll avoid trying to guess what the author meant, but I found it rather relatable. Some of these "rockstars" pick weird languages, niche database, esoteric frameworks and whatnot, not because they're needed, but because that's the rockstar thing to do at that moment. And then they leave and you're stuck managing a Cassandra database and a Rust application when everything else around you is MariaDB and Java, and you have to maintain an application in an abandoned JavaScript framework, even though dynamic frontend wasn't a requirement.
This is a guy who has 20 years of 1 year of experience. His blog includes his linkedin and github, just give it a look over.
Programming is for humans first. Cleanness and code quality is judged according to that.
This isn't a problem with "rockstar" AI devs. This is a problem of management. Who would let someone come in and rebuild the core infra of their business without any planning or review?
This article feels is trying to justify their own inefficiencies (lack of library or language knowledge) instead of taking the time to learn from the rockstar and their technology choices.
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...
> Sometimes there's so much technical debt that it can never be paid off.
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.
> There is no such thing as technical debt in the age of AI.
Producing new technical debt quickly doesn't mean there's no more technical debt.
Never mind the huge, untouched, unspoken-of debt to all the people whose work--literary, artistic, software--under various licenses, or without, it (rather THEY, the owners and co-conspirators) are taking and re-using, without attribution, without credit, nor payment of any form. Not even a thanks (because as soon as that is acknowledged it will enter the consciousness and then the question of injustice will dwell--and we can't afford to have people thinking about that).
[flagged]