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.
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 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.
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.
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.
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.
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.
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! :-) )
> 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.
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.
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.
> 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
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...
> 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. It’s especially unhealthy for my close family relationships as I just see so much of it that I could nag them to death.
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 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?
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?
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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
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?
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
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).
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
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...
> 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.
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.
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.
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.
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 college 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.
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.
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
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
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.
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.
AI is absolutely deterministic, just as much as a a car is, with a human driver (who is also soon going to be replaced with AI anyway) .. I ship more, fix more bugs, audit my code for security more and thoroughly enjoy not just the process of building, but also the asymmetric power i wield by out executing my well funded competitors with 100 developers and 10 testers dnd 5 devops and 10 full time sales staff.
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.
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”
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.
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.
100% - one of the biggest advantages of software is its mutability, so why not use it to prototype properly?
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.
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.
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.
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! :-) )
> 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.
>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.
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.
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.
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
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...
> 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. It’s especially unhealthy for my close family relationships as I just see so much of it that I could nag them to death.
And then you’ve got a third problem - that well north of 50% believe themselves to be in that last sentence of yours
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 :).
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?
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?
Entry-level software engineering at Microsoft starts at L59.
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.
I really wish we never have stumbled upon it.
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.
I love this kind of comment. It's so human. Good luck, friend.
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.
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.
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.
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.
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.
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.
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.
or linters
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.
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.
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.
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.
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
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.
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
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).
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 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...
> 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.
Programming is for humans first. Cleanness and code quality is judged according to that.
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.
This is why I like a bit of 'wet-kiss'es while working on projects.
AI codes worse than even the most egotistic prima donna. I see future business opportunities in cleaning up the mess being created now.
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.
"I am a rockstar developer and this characterisation is unwarranted" -- thought bubble emoji
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
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.
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 college 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.
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.
> how to clean up old projects
What’s “new” is indeed the “new” bit in cleaning up new projects.
> 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.
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
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...
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
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.
No, no, much better: make it a SKILL.md ;)
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
30 odd years ago this post would have been titled "Cleaning up after compiler generated assembly" ...
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.
thank you my elder statesman .. i hallucinated .. maybe ~40 or ~50
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.
good, "this underscore user". stay in that lane.
AI is absolutely deterministic, just as much as a a car is, with a human driver (who is also soon going to be replaced with AI anyway) .. I ship more, fix more bugs, audit my code for security more and thoroughly enjoy not just the process of building, but also the asymmetric power i wield by out executing my well funded competitors with 100 developers and 10 testers dnd 5 devops and 10 full time sales staff.