Introduction
We can’t just throw code together until it appears to work; we must concern ourselves with the structure of code. Paradoxically, concerns for structure and “quality of code” are often the fastest ways of getting something to work. When programming is done well, such concerns minimize the need for the most frustrating part of programming: debugging; that is, good program structure during development can minimize the number of mistakes made and the time needed to search for such errors and remove them.
…It is very tempting to dash ahead, focusing on the parts of programming that… are concrete and immediately useful and to ignore the “softer”, more conceptual parts of the art of software development. However, good programmers and system designers know (often having learned it the hard way) that concerns about structure lie at the heart of good software and that ignoring structure leads to expensive messes. Without structure, you are (metaphorically speaking) building with mud bricks. It can be done, but you’ll never get to the tenth floor (classical mud bricks lack the structural strength for that). If you have the ambition to build something reasonably permanent or something large, you pay attention to matters of code structure and organization along the way, rather than having to come back and learn them after failures.
Bjarne Stroustrup – Programming: Principles and Practices Using C++ (Third Ed.)
In the last part, I analyzed the folly of programmers delegating coding. Now it’s time to wrap up the series with why programmers are interested in doing that in the first place.
“Learn to code” was a mistake.
Remember that? It was a popular retort in the late 10s, eventually becoming a sarcastic taunt aimed at recently laid off people by their adversaries. Somewhere in the last 15-20 years of so, the “hot career” that everyone wanted to get into because the day-to-day work was comfortable and it guaranteed good pay and job security became computer programming. It used to be professionally degreed and licensed fields, such as doctors and lawyers. But that requires not just going to years of expensive school (4 years of undergrad, usually 2 years for the professional degree, and often years of some kind of residency after that) but being a good enough student to make it through all the certifications. Ideally those filters are in place to properly remove the people who are simply not qualified to do the job (they aren’t “smart” enough, or able or willing to pay enough attention to detail, or memorize enough source material, etc.).
The whole point of making professionals do all of that is to filter out most candidates. Obviously everyone would love to make a doctor’s or lawyer’s salary for work that’s entirely in an office. That means it attracts lots and lots of people who only care about money and, to be honest, would like to be lazy and avoid any strenuous labor. So we decided we need to filter those people out, which ends up being the vast majority of people who try to enter the field, in order to prevent people from abusing the career. Unfortunately the real world isn’t so neat. School has gotten so absurdly expensive people are now questioning if doctors/lawyers are even financially secure (they may make >$200k/year but have to pay off enormous student loans for most of their working years), and people have increasingly noticed for decades that universities tend to produce a specific type of obedient walking encyclopedia (basically a “meat LLM”) rather than genuinely intelligent, capable and invested graduates. This can end up filtering out some of the best people, but especially filters in a lot of the kind you don’t want and crowds out the good ones.
And then there’s computer programming, which is unique in two ways. First, there is no hard requirement for school. There is no licensure, no professional degree (the closest thing is a bachelor’s degree in computer science) and a lot of HR departments at corporations only require some bachelor’s degree (or even a lesser college degree like an associate’s), if they have a hard requirement at all. A lot of them only require this for candidates with no professional experience, which sounds like a Catch 22 for people without degrees, but startups, paid internships, etc. are opportunities to gain professional experience without that requirement, and then once you have a couple years, whether you have a degree or not (and what it’s in) stops mattering.
Here I am, 15 years into a software engineering career, and I have a bachelor’s degree in physics. I took two courses from the computer science department and nearly flunked one of them (also, I had written code to mod video games for years and was trying to build a video game console emulator as a side project).
Second, it is a 100% desk job. Doctors and lawyers often have to do things that go beyond just sitting in their offices, working on documents and talking to people. But this is all programmers do. They just work at computers all day. This not only makes it the pinnacle of a cushy “white collar” job, it also means it can done entirely remotely, which led to programming jobs starting to go remote even before the COVID pandemic. The job is similar to other types of engineering in that way (all engineers just produce design documents), although engineers in other fields may need to go “on site” if their designs are driving manufacturing. But those fields have harder requirements for engineering degrees (which, unlike computer science, are not part of the Arts & Sciences schools at universities, you have to decide to enter the engineering school).
So computer programming is basically the only option for people who are either too old or don’t have the time or money to spare to go back to school and earn a new degree, and start making good money working 100% at a desk either in an office or more likely from home. Especially to anyone who doesn’t actually know what programmers do (there’s a reason it’s a high paying job), this sounds like a fantasy come true, so a lot of people who otherwise have absolutely no interest in computer science, programming or even computers at all, but just want this nice career, decided to enter the field… and the main filter to try to screen out unqualified or even fraudulent candidates is mostly technical interviews, which people have put considerable effort into gaming.
The problem is programming as a job is basically a full time job of solving complex logic puzzles and math problems. Does getting paid a lot to sit in front of a computer compared to working in service or construction sound nice? Well, what if I told you it’s going to be like you’re back in school, but your classes are 8 hours long, it’s all math class (no English or history or art, etc.), and you have people breathing down your neck to correctly solve it yesterday please? For most people I’ve met, who readily volunteer to me they hate math, I can assure you “this is the most comfy job ever, you’ll love it!” would be a Faustian deal worthy of a Twilight Zone episode that ends with them screaming, “NOOOOOO!!!!” as the twisted irony settles in.
In the 10s, an industry arose specifically to facilitate this career switch, in the form of “coding bootcamps”: short, intensive training programs for people with no background in coding to quickly get up to speed enough to perform at an entry level programming job. Unlike professions like doctors or lawyers, where concern with quality and correctness have consistently trumped concerns with quantity (healthcare and legal representation are famously expensive, often ruinously, so there’s a clear supply issue, but we’ve all decided opening up the field to shoddy practitioners to drop the price isn’t a good idea), there was a huge demand for more programmers, so quickly training a lot of people seemed like a good idea and the companies who employ programmers supported it. They were struggling to find people.
What’s going on now with “AI Programming”, which doesn’t mean programmers adding AI to their tool belts and pulling it out on occasion when a particular task calls for it, but rather a revolutionary overhaul of the field to something entirely new (to the point corporations whose executives have full blown AI psychosis are retitling their software developers, no longer calling them “engineers” or “developers” but some new word, to indicate everything they do is now completely changed) that involves no “programming” in the traditional sense (“coding”), is a completely inevitable and predictable consequence of this rush (or, if you’re less charitable, invasion) of warm bodies into the field of programming whose only reason to be there is to get paid highly to sit in front of a computer for 40 hours/week.
People have been noticing the degradation of the software development field for a long time, and this has led to throwing out the word “gatekeeping” as an attack on any attempt to defend against or reverse it. Well, I’m a gatekeeper. I’m sorry, but everyone shouldn’t be a professional programmer, and I think a pretty good litmus test for that is if someone so intensely hates coding that he will do literally anything (including build elaborate Rube Goldberg machines out of expensive and unreliable “AI agents”) to avoid doing it as much as possible. Someone who feels that way about coding making himself do it for a full time job sounds like torture. I don’t think I’m being “mean” by telling those guys, “hey man, I don’t think this job is well suited for you”. The issue is they don’t have any other career options, and that’s the real problem that’s becoming a crisis in our society. Ironically, the “AI Revolution” would solve that, so it’s quite unfortunate that revolution is fake.
AI Programming Is the Latest Version of “Code Quality Doesn’t Matter”
When AI programmers are confronted about the quality of code that chatbot-driven coding produces, on rare occasion they will insist chatbots write high quality code that outdoes anything human programmers could do. The things are just geniuses. But more importantly, however good the code they write today is, it will be even better in six months (“just one more model, bro”). I remember one of them said something like, “just wait until AI is writing code more optimized than John Carmack’s Doom engine code”. So this is just AI cultists who think AI is God the App and it’s going to “wake up” any day and tell us all the secrets of the universe. They never present any examples or explain why they think this is true, it’s just the same “AI is AI, it’s magical and will just keep getting better” psychosis as “it’s going to replace all office work and usher in a post-scarcity utopia, unless it’s the bad kind and it turns us all into paperclips”.
The much more common response is rather: “okay maybe it writes sloppy code, but have you seen the code humans write? It’s a bunch of slop too!” That argumentative strategy tells us everything we need to know. Contained within it is two implications:
- Either all, or the vast majority, of computer programmers write low quality slop code
- It doesn’t matter and isn’t a problem that most code is low quality slop
The first point is curious because whenever someone argues this, you should ask them: does that include you? Their answer either has to be “yes, therefore I’m an incompetent programmer”, or “no, I’m a very special and rare talent that rises above almost everyone else”. Neither one of these are a claim they’re probably excited to make out loud and stick to. The second one is at least reasonable but it requires evidence, and we all know the irony of Dunning-Kruger that everyone thinks they’re a rare genius, but if everyone thinks that, obviously it’s not a rare belief, so the vast majority of them must be delusional about themselves.
The mostly likely reply you’ll get from an AI coder is the first: “yes I’m incompetent”. They have this really weird tendency to denigrate themselves in order to praise the AI God. When they show you some completely wrong, useless pile of slop the chatbot blurted out and you tell them it’s wrong and useless, they will reflexively reply with, “well that’s my fault for not knowing how to prompt it better!” (as Pivot to AI‘s logo says, “it can’t be that stupid, you must be prompting it wrong”), as if the whole point of their existence is to lower themselves at the feet of AI and say “I’m not worthy”. In case you still don’t think this is some kind of weird religion…
But the first point isn’t the important part. It’s the second point. If switching from human coding to AI coding is merely preserving the low code quality but doing it faster or cheaper, then apparently code quality doesn’t matter, or at best it matters but is less of a concern than being fast and cheap, and that implies that code quality is independent of how quickly and cheaply development work can be done.
AI coders are coders who believe code quality isn’t what determines the speed, cost and efficiency of managing a software product.
They readily admit chatbots are not somehow solving the low code quality problem (which they concede is not only a problem but a ubiquitous problem), at best they are sidestepping it by removing the humans who are the only ones slowed down by low quality code. This is the critical point we need to understand: AI coders think improving code quality is either not a priority or actively distracting and a waste of time.
This is not new (how often do I say that!). A subset of people who either do programming professionally, as part of open source projects, or as a hobby in personal projects, have always believed that code quality is an irrelevant distraction and burden on programming that just slows it down and overcomplicates it. They like to say things like, “just make it work” or “it doesn’t matter how pretty it is”. If they believed this in 2022, they still believe it in 2026 and love that AI has finally and officially freed us from ever having to talk or worry about code quality, which it does by making “coding dead” and then “code reviewing dead”. You can’t possibly worry about code quality if you’re never even glancing at the code!
(As I explained in the last part, no that’s not true, the problem of quality and design just reemerges in the “agentic coding” artifacts that people do write and review themselves, i.e. the prompts, skill files, spec files, etc.)
The point is this isn’t something that AI caused. AI just revealed or (since it was already revealed to those of us in the field paying attention to it) amplified it. The programmers arguing that code quality doesn’t matter have had to debate programmers like me who argue the opposite this whole time, and since they haven’t changed our minds, they do what salespeople always do and “throw mud at the wall and see what sticks”, just trying every possible avenue that leads to the foregone conclusion to see if we find that one persuasive. So when AI showed up, this just provided a new avenue to argue this point. They already believed the conclusion, they just see this as hopefully an opportunity to get those of us who don’t believe it to either start believing it, or at least shut up about it.
Also, they now have product departments and executives backing them, which has given them confidence to argue against more senior and lead engineers knowing they have the grace of the people who are all the engineers’ bosses. This didn’t change their minds about anything, it just made them louder and bolder. And it created a feedback loop where product people/executives latched onto these types of programmers, who told them what they want to hear (that maintenance and long-term investment into software isn’t a thing, and being ultra-shortsighted and shoving in features as fast as possible to max out next quarter earnings is actually the best way to do run a sustainable business… in this way it’s just continuing what Agile Inc. consultants started), and then went onto LinkedIn or to conferences and repeated it, and further emboldened programmers who already felt that way to start being louder.
Yes, Code Quality Does In Fact Matter
As I stated, I am one of the programmers these guys have to argue with. I couldn’t summarize my perspective on software engineering more succinctly than “code quality is everything”. I really shouldn’t have to argue this. I have heard some variation of the phrase, “the problem with programmers is they care too much about the code, when it’s the product that matters” more times than I can count. This is an astounding thing to utter and I don’t think I even fully appreciate how incredible it is.
Programmers saying “code quality doesn’t matter” is like:
- Chefs saying recipe quality doesn’t matter
- Home builders saying architecture doesn’t matter
- Lawyers saying the accuracy of their legal case doesn’t matter
- Doctors saying how carefully they listen to their patients doesn’t matter
“All that matters is that it works” is a thought-terminating cliche. It’s an empty tautology, because “matters” and “works” are essentially synonyms. Yeah, sure, the goal of making things is to make things that do what the thing is supposed to do. You understand there is no insight in that whatsoever, right? It’s like saying the Law of Identity (A is A) like it’s some kind of profound bombshell revelation about the world.
If a chef uses bad recipes, his food will suck. It won’t “work”. If home builders use bad architectural designs, their homes will suck. They won’t “work”. If lawyers make cases with bad arguments, they will lose cases. It won’t “work”. If doctors don’t listen to their patients, they’ll miss symptom details and misdiagnose them (and then mistreat them). It won’t “work”.
If you write low quality code, your software will suck. Software is rapidly iterative and incrementally modified, so that very often takes the form of “you got the first iteration out the door, but now you can’t increment on it”. “Works” in software doesn’t mean you delivered version 1.0. Your work isn’t done at that point. And when it comes time to deliver version 1.1, you have to go back into the code you wrote for version 1.0, and suddenly it matters not just that version 1.0 code satisfies the requirements of version 1.0, but that it can be easily and safely modified to satisfy the new requirements for version 1.1. So “works” is not the same thing as “satisfies today’s requirements”.
The belief that code quality doesn’t matter is plainly absurd to anyone who has worked enough in this industry to see what’s going on. I have worked for several large corporations who own large, old (10-20 years) gigantic piles of low quality spaghetti code, and the low quality of that code is a constant source of anxiety and frustration at every one of these companies (I mean for the business guys, not the coders). They all have growing backlogs of bugs that keep coming back (“regressions”). They regularly schedule “bug bashes” where they halt all forward progress on the system for a period to have the entire (meaning dozens to hundreds of programmers) organization do nothing but try to fix these bugs. This always backfires.
The attempts to rapidly fix a bunch of bugs inevitably causes more bugs, and the backlog of bugs ends up larger after every “bug bash”. Feature work proceeds at a snail’s pace. It’s very difficult to make changes (“adding a button will take a month”), and very risky because it will probably introduce a lot more bugs. Companies hire expensive consultants specifically to deal with low code quality and teach the organization how to deal with it. Even if said consultants are incompetent and just make it worse, the fact an attempt was made at all to deal with it tells you the business takes it very seriously.
In fact, what a lot of these big companies are doing is trying to rewrite their flagship products from scratch. Why would you do this!? Why would you waste so much time and effort recreating what you already have!? The answer is because the business is sick of trying to do any work on the systems they have and want to just wave away all the tech debt they’ve accumulated. They get further misled by rewrites because they proceed very quickly and smoothly at the beginning, encouraging the belief that this is just how things will be in the rewritten product once it is production ready.
They don’t understand that it was their corporate culture and practices that caused such a drop in quality in the first place, and since the rewrite is expensive to develop, serves zero customers (and thus makes zero revenue) and will not serve any until it reaches “parity”, it is very urgent to get it to parity, so guess what? It gets rushed! Developers are pushed to do things as fast as possible, under even more pressure than they were under the first time they did it. The result is an even worse product with even lower quality as it starts to approach parity, and once the reality that work on this product is even slower and more unstable than the live one becomes clear, the most likely fate is for it to be cancelled, making the entire effort a waste of time. Even worse, if they try releasing it to a few customers, they still realize it will never replace the original product, but they don’t want to cut off those customers so now they have to maintain both! And since they deliberately didn’t reuse any code from the original system (that would be polluting the new thing with all that old tech debt), they have two copies of all their business logic to try to keep in sync!
Software companies being either unable or unwilling to produce decent quality code is not “fine”. The fact it’s what most of them have been doing for decades (i.e. that it is normal) is not the same as it being okay. Yes, it’s normal. Low quality code is the typical case. And so is everyone inside these companies running around like chickens with their heads cut off, talking about how things are “on fire” all the time, wishcasting ridiculous deadlines without involving engineers at all (because they know what the engineers will tell them), and blowing massive amounts of money on attempts (that usually fail) to do something about it.
In fact, and this is the ultimate irony here, the reason why software executives are so obsessed with AI is because they think that’s their magic wand to wave this all away. The narrative being presented inside of software companies that are “embracing AI” and insist it’s “the future” isn’t some super-optimistic vision about making ultra-fancy futuristic software that people will be amazed by. No, the narrative is what we’ve been doing isn’t working and we need to change. I’ve even heard, direct quote, “the human software development lifecycle doesn’t work”. The reason they want the chatbots so badly to save them is because they have something to be saved from. Their businesses are slowly failing, they’re losing customers, it’s too expensive to keep their systems alive, much less do active development on them, and this is all because the quality of their codebases is so bad!
So if adopting AI coding is going to do nothing to solve the quality issue but just speed up the pace at which low quality code (i.e. tech debt) is produced, it’s just going to accelerate the decline of these systems! I believe this is the most likely fate of companies who do this for too long. They will throw chatbots at their legacy slop codebases, which will ensloppify them so much more that they become unusably unstable. Whether that makes all the customers leave or not depends on the competition, and the competitors are probably all doing the same right now, but SaaS is always competing with Excel spreadsheets, so it’s a matter of whether all the options get so bad it’s genuinely worse than just doing it all with Excel (hopefully Excel isn’t being ensloppified too).
To whatever extent these products are still going when everyone wakes up from this bender with a throbbing headache, the need for highly skilled “AI slop cleanup” programming shops will skyrocket. The best way to make it obvious how important code quality is, is for everyone to ruin the quality of their code to the point it causes a calamity, so… I guess there’s a silver lining to this.
The Equivocation of Passion and Vanity
By repeating the “what matters is it works” empty tautology every time they get into this debate, these guys are implying people like me who argue code quality does matter don’t care about software working. They’re arguing we care about something else. They think our fixation on code quality is an aesthetic indulgence or fetish, like we just open code editors and stare at “high quality” code, getting some kind of thrill or titillation out of just looking at it, and all code quality does is tickle our fancies.
The accusation that programmers who care about code quality just have a “fetish” for “pretty” code is much more significant than I think people realize. They will even call the belief that code quality matters programmer vanity. They claim we’re just using code quality to congratulate ourselves for being so smart and talented at programming (and better than other programmers) instead of caring about the companies who employ us, their software products or the customers who use those software products. So, we’re just selfish, self-indulgent, arrogant weirdos with a sexual attraction to “pretty code” and we want to turn the profession of programming into a self-serving way to get paid to indulge our weird fetish and feel good about ourselves.
When you say all this out loud, it really begs the question: are these guys sure this isn’t just a silly, ignorant and rather unfair straw man? Because it sure sounds like it when it’s all laid out plainly.
This isn’t just about programming. This is a general characterization of passion as vanity. The equivocation of these two behavioral traits is astounding, and once you realize that’s what this is, it quickly follows that a more likely explanation is this is what impassive and disinterested people think of people with passion. The idea that people being passionate (highly motivated and enthusiastic) about doing certain types of work causes them to poorly execute that work (and instead get distracted with aspects of it that don’t matter) is very bizarre. It’s like saying Isaac Newton being so weirdly obsessed with physics he was thinking about gravity while sitting under an apple tree relaxing would cause him to never reach any genuine insights in physics and instead just write a bunch of pretty equations down, stare at them and touch himself.
No, most of us understand the people who get that weirdly enthusiastic about things the rest of us consider to be tedious schoolwork we couldn’t wait to get done with are exactly the ones you want to pay to just sit around and follow that passion all day, because they’re the most likely ones to discover the next breakthrough. And also, that making the people who find the subject uninspiring, uninteresting and a chore to work on are not likely to do good work in the area. They are rather likely to just phone it in and do the least amount of work to check the box and free themselves of having to be further burdened by it (since, after all, they consider working on it to be a burden).
I mean, does the idea that some nerd can’t sleep at night because he’s stuck on the math problem he’s trying to solve and can’t let go of it because he’s so passionately obsessed with math thwarts his ability to eventually solve that problem, compared to the guy who “hates math” and couldn’t be happier to be out of school and never have to do it again, really make sense to anyone? Is this really what people are trying to argue, here?
To whatever extent programmers who really do enjoy and get obsessed with the craft of software development get some kind of emotional satisfaction out of authoring high quality, well-designed code, this is a consequence of their passion for the work. But why are they passionate about it? Or rather, what exactly are they passionate about? Why does “high quality” code tickle their fancy but “low quality” code doesn’t? They derive satisfaction from code being “high quality” because high quality code is valuable. It does the job, it accomplishes what software development seeks to accomplish, which is build working software, so effectively. It is this feature of code, so effectively and powerfully doing its job, that provides the “beauty” programmers find so desirable.
Math nerds don’t think wrong proofs are “beautiful” because the symbols are arranged in highly patterned ways. Whatever “beauty” might emerge from the patterns suddenly and completely disappears if it’s incorrect. And the reason why a succinct and patterned proof is more “beautiful” than a convoluted and meandering one is because it expresses the underlying truth more directly and thoroughly. It is never about viewing the positions or shapes of symbols as graphically pleasing like it’s a painting or something. That might be what people who “don’t get” being passionate about math think it is, but that’s only because they don’t get it.
Also, it is a blatant mischaracterization of passionate nerds to say they’re vain and just doing it to market themselves as smart and talented. This is exactly what I would expect people who LARP as passionate nerds to say as a “confession as accusation”: that’s what they’re doing by pretending to be passionate nerds, so they assume everyone else presenting an outward appearance of passionate nerddom must be doing the same. No, my friend, you underestimate just how weird passionate nerds really are. They’re not insecure people who just want to be popular and respected (a basic and widely shared human condition that “normal” people all understand and experience) and figured pretending to be passionate about technical fields is a way to achieve that. They really are, genuinely in the bottom of their hearts, obsessed with the thing. Math nerds are actually obsessed with math and think about it all the time. They’re not thinking about what you think of them all the time. They really, truly are thinking about math while they’re standing alone at the party sipping a drink. Yes, they’re that weird.
They aren’t staying up until 2am working on a problem so they can tell you about it later and make you think “wow, that guy’s really passionate about stuff, that makes him interesting”. It isn’t vanity. Yes, people who are very vain will LARP as passionate nerds, so now we have a problem of a bunch of imposters warping the perception of what passion even is, but that’s a problem because it warps the perception. Passion is about the thing you’re passionate about, not you. If it was always about you and not the thing, that was never passion, it was vanity. These are not only different, they’re almost opposites. We might say vanity is self-passion (being obsessed with and enthusiastic about one’s own reputation or value as a human being), which means it is specifically not a passion about things outside oneself.
The fact software company executives have been harassing (in many cases explicitly threatening to chase out, although I don’t think they really follow up on these threats) the subset of programmers on their payroll who are passionately obsessed with coding and lie awake at night thinking about how to improve the design of their products’ codebases to let it go, stop caring and just prompt chatbots all day is so bizarrely self-defeating. I can’t imagine a more incompetent attitude for an executive to hold. This is like a restaurant telling the head chef who’s passionate about cooking to get lost, or a movie director telling the artists who love drawing and were doing it as 8 year olds and have a bunch of side projects they do in their free time to get lost.
The comments on YouTube videos about what’s happening in programming have been filled all through 2026 with depressed coders talking not about how they were fired, they’re still employed, but they have been forced to stop investing into their work and just phone it in with chatbots instead, and this makes their job boring and unfulfilling (the term they’ve coined for what they now are is “meat proxy”). Congratulations, tech executives! Not only have you destroyed the talent pipeline for your own industry for years to come, you’re killing the passion in your most enthusiastic employees who actually got obsessed with your products and don’t just come in, move JIRA tickets around and take your money. I couldn’t sabotage a software company more effectively if you paid me an executive’s salary to try.
This equivocation of passion with vanity is about as reliable as an indicator of LARPing I can think of. Anyone who argues this either has no passions and doesn’t understand what it means to have one, or (more likely I think) he is a vain person who can’t imagine why people would exhibit behaviors for any reason except for self-congratulation. This is evident from the fact people who argue this are doing so (and this is certainly the case with the loudest AI boosters) in an attempt to sell themselves as better in some way, usually as more productive and efficient (i.e. “10x productivity”) than all those self-obsessed people who just like staring at their own creations.
This is a problem in programming because so many people joined the profession for no other reason than to make money, so they’re practically commanded to LARP as people who care about programming and what it takes to do it well. They don’t actually care about any of that, they just want to take the paycheck and go home, but they can’t say that out loud because then they destroy their own career prospects. They have to pretend to care, and this takes the form of arguing “caring actually means not caring and just half-assing all the work, since quality isn’t even really a thing here”.
“Code quality doesn’t matter, just make it work” is the calling card of the poser programmer. It is the confession that they don’t care about their craft, they’re checked out and just want to put in the minimum effort to get paid. Turning the highly technical and cognitively demanding job of computer programming into babysitting chatbots is just the logical conclusion of what poser programmers have always been out to achieve: to be called programmers and get paid as programmers without ever doing any programming.
Does AI Programming Somehow Force Quality to Improve?
Some proponents of handing the coding part of programming off to chatbots will pay lip service to code quality still being a concern. Funny enough, their argument usually works by badmouthing AI: basically chatbots are uncontrollable overpowered tools, like a machine gun with no mount but that fires so fast the recoil makes it impossible for someone to aim it, so the only thing you can do with it is “spray and pray”. On its own this is quite useless: such chatbots will write tons of code, some of it will be what you want, and much more of it will be what you don’t want.
But it can be made useful if you install a filter, usually in the form of an exhaustive suite of automated tests (see the graphic from the last part that shows how “testing” grows to replace “implementation”), but also if you robustly design a system with lots of compile time guardrails that will trip if something is broken. Then you can run a loop where the chatbot does something, it fails one of these tests, you discard it and feed the error back into the chatbot, and eventually it will converge to something that passes all the tests, and then you accept that. Since this is fully automated, the fact the chatbot has to make, who knows? 3? 10? 100 failed attempts before it finally succeeds is fine, because it’s still going to go faster than humans, can be parallelized, etc.
Well, that’s actually a terrible idea when you remember how expensive AI tokens are (all of the improvements in “coding harnesses” in 2025 and 2026 worked this way, the LLMs themselves peaked in early 2025, the harnesses try to define feedback loops like compiler errors, automated tests, analysis scripts, etc., and run operations in loops like this… it can work, pretty well if the guardrails really are robust, at the cost of an enormous amount of LLM inference). But regardless, the real question here is: how much effort would it take to write exhaustive automated tests for modern software (and I mean really exhaustive), and if you can do that, how much work would be left to implement it yourself?
I won’t get too into this here, but the short answer is: there is no such thing as exhaustive tests (especially once GUIs are involved, which the industry has widely decided are “not testable”, certainly not exhaustively) for modern software, so this is all moot. Whatever test suite you have, it definitely has gaps, and your “spray and pray” coding chatbot is going to very effectively find and exploit the gaps in it the same way they can “break out of” sandboxes and hack into other systems (brute force stochastic algorithms with megawatts of GPUs behind them always work this way).
But more importantly, I’ve also noticed the guys who argue this deal with the fact none of the large codebases they want to do this on have tests (or strong compile time guarantees) in the first place by using a chatbot to write all the tests! That makes the whole thing circular and pointless (the tests don’t have tests so you’re just spraying and praying the construction of your guardrails with no guardrails), but the fact writing tons of tests (which aren’t part of production code) is the strategy to make it work is still a concession the quality of the production code is going to tank. You can’t make the chatbot care about quality or architecture (you can try and beg it to care with skill files, but those are prompts, not guardrails), and the whole point of code quality is it’s a variation of code while holding the behavior it produces constant. The tests verify the behavior, not the quality. Installing guardrails in this way is a strategy specifically aimed at producing production code that is correct in terms of behavior as quickly as possible, with no concern whatsoever for its quality.
If you care about quality, you’re either going to have to write the code yourself (that’s literally what writing code means! It means thinking about and deciding what quality code is, and expressing that decision by writing it down), or describe the code you want so exactly (down to design and architectural details) to a chatbot that you’re using AI as an expensive and unreliable keyboard. There is no way to reconcile “I don’t write and don’t even read the code!” with “but the quality of that code is still important!”.
Conclusion
I don’t think people need to be programmers to be valuable as human beings or deserve to be paid high wages. That’s a bigger social problem we have to deal with: the growing class conflict between “blue” and “white” collar workers with an unjustifiable pay gap between them, that really boiled over during the COVID pandemic when most of the blue collar workers were either fired and left to starve while being told to not go outside, or told they’re “essential” and overworked while being exposed to what they were told was a virus so deadly it required shutting down society, and white collar workers sat at home getting food delivered to them and paid more than the people exposing themselves to the virus to be on their laptops. This created a huge amount of resentment that is now being expressed by gleeful excitement that knowledge workers are finally being torn down and humiliated by AI.
I empathize with people who became poser programmers. My intention is not to spread more resentment and ill will. Society puts way too much emphasis on intelligence as the most (only?) important measure of human worth (how fitting that it is now worshipping artificial intelligence) and this predictably encourages people to pretend to be highly intelligent. I have to deal with annoying people at work who make nonsense arguments about my craft and tell me the future of it is babysitting chatbots. But that’s a lot less of a tribulation than what a lot of people are dealing with these days (since the AI Revolution is fake, the economy is in poor shape and people are struggling to make ends meet). It would be absurd for me to call myself a victim of this and quite unhelpful to dress other people down with no attempt to understand their behavior. I can’t imagine having to pose as a programmer as a full time job is anything less than panic inducing, but apparently that’s less unpleasant than the alternative of working a different job.
My point is to commit to the truth. The wider social issues about financial insecurity, inequality and class conflicts are what is driving this, and we need to correctly understand that because degrading the meaning of software development down to the point anyone who doesn’t care about it and would hate to solve logic problems all day can do “it” isn’t going to solve any of those problems. Dismissing quality as a centrally important problem of all production and business is not helping anyone. We all work jobs and earn money so we can spend that money on goods and services. If everyone is phoning it in churning out low effort slop, we all suffer from it. This isn’t a world we should be helping to create.
The clear trend through 2026 is a growing disgust with AI among the public. This is hardly surprising. The experience most people have with AI is: as consumers it’s a gimmicky product that doesn’t really improve their lives, gets shoved into products they buy in unhelpful ways, and degrades the quality of things they buy by turning it into low effort slop, they’re forced to use it at work under threat of termination even if they think it doesn’t help, their bosses think it’s an excuse to compress deadlines and dump even more work on them with no extra pay, the news keeps telling them it’s going to take their job and career away entirely in just a short matter of time, and it’s powered by noisy, polluting and resource guzzling data centers that will ruin their local communities. Was this reaction really that hard to predict?
This is what committing to low quality, phoned in slop work gets you: it makes you a pariah. Don’t do it. Quality is what people want. Quality is what creates passion, which makes people enjoy their work. Quality is what gives a brand a good reputation and customer loyalty. Quality is what gives you long-term job security from a personal reputation of doing good work, even if one particular sweatshop fires you for not helping them churn out slop as fast as possible.
Quality is everything.