Summarizer

I'm sorry but "extensive documentation, scalable, high test coverage, perfect code style" seems to me to be the opposite of throwaway. It sounds like the kind of thing people will think surely must be very important and in use, because why go through all those hoops instead of doing a quick hack? But I guess we can just throw AI at the maintenance burden anyways..

You're not supposed to read the Jira ticket. You're supposed to paste the link along with instructions for your Claude agent to "do this ticket, no mistakes," then raise an MR for whatever it writes. The text is a wire protocol between agents. If a PM doesn't care enough about the requirements to write, or even read them, then would they even notice if the code works or not? Why would they care about that? What does "works" even mean if no human knows the spec? How quickly we become reverse centaurs.

Recently I reviewed some vibe-coded stuff and sent a list of issues and suggestions to the “author,” figuring he’d read it and then go through each one with Claude until fixed. Instead he didn’t read it at all, and just threw the whole thing at Claude Code as a big prompt. The result was… interesting!

As long as each part of the hierarchy understands what they need to know at their level and what they produce, I have no problem with "the whole hierarchy". You're saying this as if it's some rebuttal ad absurdum, when it's absolutely the case: when the higher layers don't understand what they do, we have a problem with that too, and that's been true since forever. Remember Dilbert and Office Space, and making fun of the ignorant middle managers and execs? In this case, what we're complaining about is coders not understanding the code they ship (because some AI wrote it and they don't bother to review it or guide the AI fully).

I watched a video of some (unemployed) programmer lamenting over the current job situation market. He had been coding for a good while, but had recently been laid off. The vid was mainly concerning the searching and interview process, but it also did highlight something I find somewhat true and important: Right now we're in a gold rush. Companies, that be established ones or startups, are in a frenzy to transform or launch AI-first products. You are not rewarded for building extremely robust and fast systems - the goal right now is to essentially build ETL and data piping systems as fast as humanly (or inhumanly) possible, and being able to add as many features as possible. The quality of the software is of less importance. And, yes, senior engineers with other priorities are being overshadowed - even left in the dust - if they don't use tools to enhance their speed. As the article states, there are novice coders, even non-coders that are pushing out features like you wouldn't believe it. As long as these yield the right output, and don't crash the systems, that's a gold star. Of course there are still many companies whose products do not fall under that, and very much rely on robust engineering - but at least in the startup space there's overwhelmingly many whose product is to gather data (external, internal), add agents, and do some action for the client. You need extremely competent, and critically thinking technical leaders on the top to tackle this problem. But we're also in the age where people with somewhat limited technical experience are becoming CTOs or highly-ranked technical workers in an org, for no other reason than that they know how to use modern AI systems, and likely have a recent history of being extremely productive.

15 YOE, here: Well, I just interviewed between October - Decemeber of last year, and since then, the company I joined has gone full vibe-coding and is changing to AI interviews. So...

You have described exactly the situation of almost all of my clients. And in some way it is good to see our business model validated as we help steer organisations at this level, also technically. I would only add that the quality of software has improved significantly. From my perspective, the bar for quality at most organisations like this is low, extremely low.

Companies that don't fall under that rubric are established and have actual money on the line if their software shits the bed. Software that handles actual logistics and transactions can't be treated to lots of LLM updates without some serious problems arising. Startups and B2B ones especially have always been cheap, cut corners, screwed up and apologized later, and most importantly just created hype and fluff to get investment that's rarely spent on building solid foundations. There's not much crap AI is writing for them now, as code or marketing material, that wasn't already just as junky when it was written by humans. That's been the mutually agreed upon game that startups and VC have played since the 90s. LLMs just distill the douchery and the flawed logic, and it's pleasant to watch their artifacts go down in flames.

The OP has an amusing side point - LLMs have automated sucking up to management. There is a large market for that. His main point, though, is this: I have a colleague ... who spent two months earlier this year building a system that should have been designed by someone with formal training in data architecture. He used the tools well, by the standards by which use of the tools is currently measured. He produced a great deal of code, a great deal of documentation, a great deal of what looked, to anyone who did not know what to look for, like progress. He could not, when asked, explain how any of it actually worked. The work was wrong from the first day. The schemas, and more importantly the objectives, were wrong in a way that would have been obvious to anyone with two years in the field. I've been reading many rants like that lately. If they came with examples, they would be more helpful. The author does not elaborate on "the schemas, and more importantly the objectives, were wrong". The LLM's schema vs. a "good" schema should have been in the next paragraph. That would change the article from a rant to a bug report. We don't know what went wrong here. It's not clear whether the trouble is that the schema can't represent the business problem, or that the database performance is terrible because the schema is inefficient. If you have the schema and the objectives, that's close to a specification. Given a specification, LLMs can potentially do a decent job. If the LLM generates the spec itself, then it needs a lot of context which it probably doesn't have. This isn't necessarily an LLM problem. Large teams producing in-house business process systems tend to fall into the same hole. This is almost the classic way large in-house systems fail.

My friend built a construction management SaaS entirely via Claude. It looked damned impressive, and it kind of worked to demo, but he is in no way a programmer, though he understood the problem domain very well. I asked a few basic questions: - where is the data stored? - How would you recover from a database failure? - does it consume tokens at runtime? - what is the runtime used at the back end? - why are the web pages 3M in size and take forever to load? He had no idea. It's a typical vibe coding scenario, and people like to paint this as why vibe sucks. I think however that all that is needed to bridge the gap is some very simple feedback from an expert at the right time. For example to someone who knows about databases, its pretty easy to look at a database schema and spot stuff that looks off - denormalised data, weird columns. That takes 10 minutes, and the feedback could be given directly to the LLM. Likewise someone who knows a little about systems architecture could make sure at the outset that some good practices are followed, e.g.: - "I want your help to build this system but at runtime I do not want to consume any tokens." - "I want the system to store its data in Postgres (or whatever) and I want documented recovery plans if the database craps itself". - "I want web pages to, as much as possible, load and render as quickly as possible, and then pull data in from the back end, with loading indicators showing where the UI was not yet up to date".

One of the riskier bets my team is currently making is that this is exactly what is needed, and nearly nothing more. We have LOB prototypes vibe coded by enthusiastic domain experts that we are supporting in a “port and release” fashion. A senior engineer takes the prototype and uses Claude code to generate a reasonable design, do an initial rough port (~80% functional, 100% auth & audit logging) and (hopefully) all the guidance necessary to keep the agent between the lines. Coupled with review bots and evolving architecture guidance etc. Then the business partner develops and supports it from there. For low stakes CRUD, I think it’s a reasonable middle ground. There truly is a lot of value in letting an expert user fine tune UX; and we’re only doing this with people who are already good at defining requirements and have the kind of “systems” thinking that makes them valuable analyst resources to the tech team already. Early results are encouraging but it’s way too early to draw conclusions. Personally I hate how badly internal users are served by the majority of their systems and am willing to take some calculated long-term governance risks.

The problem is that everyone has a different opinion. If you let a single user drive the design then that single user might love it, but everyone else will hate it. Bespoke designs are often really terrible. Have you ever shopped for a house? You know immediately when the previous owner had their stupid whims indulged by contractors with dollar-signs in their eyes. The house is ugly, non-functional and is not going to get the sellers price. The next owner will undo nearly all of the work, and the contractor will cash in on both ends. As engineers, we like to think we're the contractor in this scenario. But it's actually just an LLM.

Personally I hate how badly internal users are served by the majority of their systems and am willing to take some calculated long-term governance risks This, I think, is the LLM/vibe coded app’s current place to shine. Most internal systems don’t need massive concurrency or redundancy. It’s a webapp that reduces coordination cost between 20ish people. That’s something you can typically vibe code and deploy for ten bucks a month, and create real value.

Is CRUD low stakes? Even if all you do with the employee database is read and write employees, losing it or corrupting it is disastrous, potentially business-ending.

Some of it is, certainly, and those are the ones we’re supporting this way. I’m not talking about systems of record - more like custom project and task coordination systems that would alternatively exist in spreadsheets, in Monday.com or wedged into some larger system that is a poor fit and functions largely through side channels.

> That takes 10 minutes Verifying LLM output needs to occur every time LLM output is generated, so no it doesn’t just take 10 minutes. It takes 10 minutes + time to change the LLM input + 10 minutes to verify it worked * ~the number of times the code is generated. Which is why vibe coding is so common, if you actually care about quality LLM’s are a near endless time sink.

> I think however that all that is needed to bridge the gap is some very simple feedback from an expert at the right time. I don't think it's as simple as that. What will most likely happen is that the vibe coders will quickly eat up your time asking for validation and feedback if you are not careful. You are also now implicitly contributing to their project, which if it goes south, could come back to bite you. If the vibe coders are pushing code in the org, then they should become part of the formal review process like any other junior programmer. They should also be forced to do daily stand-ups, sit in meetings and explain their code like the rest of us.

Sounds like it was a prototype to validate an idea? I think at validation stage technical details like that shouldn’t matter. All that matters is there market demand for this. If yes, go and build it properly.

Sadly I don't think management would go and build it properly, this sort of thing happens frequently where the prototype is put directly into production because why waste time redoing something that already exists and works. Just got to clean it up a bit, round off some sharp corners, and put it into production post-haste.

So far, when Claude pops out a schema it's pretty spot on, iff you've described the problem correctly. What the article's author seems to be hinting at is that the problem was described incorrectly from day one, and the LLM picked the wrong schema from day one. Because the person making it is not technically literate enough to describe the problem in a way an LLM interpreted correctly. The hidden BA work a developer usually does was missing from the process.

I think for a lot of companies, AI is a destabilizing force that their managerial structure is unable to compensate for. When you change the economics to such a degree, you're basically removing a dam - resulting in far more stress on the rest of the system. If the leaders of the org don't see the potential downsides and risks of that, they're in for a world of hurt. I think we're going to see a real surge of companies just like this - crash and burn even though this tech was sold as being a universal improvement. The ones that survive will spread their knowledge about how to tame this wild horse, and ideally we'll learn a thing or two in the future. But the wave of naivety has surprised me, and I think there's an endless onrush of people that are overly excited about their new ability to vibe-code things into existence. I think we've got our own endless September event going on for the foreseeable future.

Without getting into AI-for-work good or bad, > update 42 if statements in 32 different files is a silly behavior for a programmer or an AI to have to do more than twice. We have tools that very effectively remove the need for things like that: programming languages that allow modular and reusable code, good design, etc.

Ideally. But that requires the correct abstraction, requires keeping it up to date.... that's basically an unachievable ideal. You either have overabstraction/overengineering (most codebases) or you have repetition. Repetition is actually more preferable in the LLM-world because you have to keep less stuff in your head. And the LLM's head too. Even if something does look copypasted, it might actually be semantically distinct enough that if you couple them, you'll create a brittle mess. Additionally, there's always going to be global changes (update the code style, document things, refactor into a new pattern, add new functionality to callers, etc.). The question isn't whether you use your lanuage's tools or you do it by hand, the question is whether you use an LLM or do it by hand :P

Totally fair, but 42 if-statements across 32 files isn't something you need to fix with like ... a grand refactor or hexagonal architecture or event sourcing or whatever the overengineering pattern du jour is. You can fix that with a utility function or three, and a file/class/module/whatever that owns the code relating to some of those conditions. I'm not some DRY zealot, but I've been in the "this system needs really similar changes to a ton of geographically distant code for simple changes" salt mines a lot. The people who say that kind of spaghetti is unavoidable are just as wrong as the ones who say it can only be fixed with a grand rearchitecture by a rockstar.

Sure but even wiring that utility function in is work :D If you have even just a 2-3-million LoC codebase, not even something truly enormous - making global changes does require typing, and a whole lot of it...

> the usual refactoring tools of modern IDEs are insufficient Cursor doesn't have refactorings, so

A lot of people have already noticed that it's becoming cheaper to create bespoke software, as an alternative to paying a SaaS or purchasing off-the-shelf. An example is that instead of buying a cookie-cutter "MacMansion" like in the last century even individuals can afford a unique house designed by a professional architect. It may not be an award winning artistic design, but it won't be the same copy-paste design as every neighbour up and down the street. I'm seeing more comments online that developers are now expected to do more in the sense that what used to be a CLI script may now be a semi-vibe-coded application with a Web UI, a dashboard, and Open Telemetry integration because... why not? As an example, I got a bunch of boxes of random Lego for my kid and I wanted to figure out what sets the pieces came from. I got Codex to vibe-code a full SPA web UI and a matching API app that pulls Rebrickable database CSVs, parses them, puts them into SQLite, and then runs a fairly complex integer optimisation solution on top of that collected data to figure out the best match. I did that in an hour while sitting in on an online meeting! There is no way I'd have the mental energy to do a project like that otherwise. I'm too busy with housework, actual work, etc... Maybe when I was younger I could blow a few weeks of effort on something like this, but now? No way. That cost-benefit arithmetic has dramatically shifted thanks to AI developer agents. Suddenly, many fiddly tasks are no longer fiddly, or even trivial, so there's no excuse not to do them any more. Going back to the architect or mechanical engineering example: Significant corrections to designs used to be expensive because all the blueprints (on paper!) had to be redrawn and distributed. Now, a change to CAD design in 3D can be converted to arbitrary 2D views, cross-sections, or whatever in seconds. The software just projects whatever view you want out of the master design file. Creating the paper blueprints similarly takes a minute or two at most on an industrial large-format printer. It just spits it out.

I’m an LLM enjoyer who also thinks that ‘er ‘jerbs are safe and, taken to their logical conclusion, most LLM-stroking online around coding reduces to an argument that we should be speaking Haskell to LLMs and also in specs and documentation (just kidding, OCaml is prettier). But also, I do a little business. You’ve hit the real issue, IT management is D-tier and lacks self awareness. “Agile” is effed up as a rule, while also being the simplest business process ever. That juniors and fakers are whole hog on LLMs is understandable to me. Hype, fashion, and BS are always potent. The part I still cannot understand, as an Executive in spirit: when there is a production issue, and one of these vibes monkeys you are paying has to fix it, how could you watch them copy and paste logs into a service you’re top dollar paying for, over and over, with no idea of what they’re doing, and also not be on your way to jail for highly defensible manslaughter? We don’t pay mechanics to Google “how to fix car”.

you're basically removing a dam - resulting in far more stress on the rest of the system. Adding to the grab-bag of useful flow-dysfunction concepts and metaphors: Braess's paradox. [0] Sometimes adding a new route makes congestion strictly worse ! Not (just) because of practical issues like intersections, but because it changes the core game-theory between competing drivers choosing routes. [0] https://en.wikipedia.org/wiki/Braess%27s_paradox

I saw something really similar happen at my last few jobs. 2 jobs ago vibe coding wasn't even viable but some of the people went so hard on making everything so much more bloated with LLMs it was so hard to get yes or no answers for anything. 1 line slack, 20second question would get a response that was 2 pages of wishy washy blog posts with no answer. Follow ups generated more hours wasted. My last job we watched a PM slowly become a vibe manager of vibe coders. He started inserting himself into technical discussions and using ai to dictate our direction at every step. We would reply but it got so laborious fighting against a human translating ai about topics they didn't understand people left. We weren't allowed to push back anymore either or our jobs would get threatened due to AI. Then they started mandating everyone vibe coded and the amount of vibe coding as being monitored. The pm got so disorganized being a pm and an engineer and an architect(their choice no one wanted this)that they would make multiple tickets for the same task with wildly different requirements. One team member would then vibe code it one way and another would another way. It was so hard to watch a profitable team of 20 people bringing in almost 100million of profit a year go into nonutility and the most pointless work. I then left. I am trying my best to not be jaded by all of these changes to the software industry but it's a real struggle.

The forcing of competent engineers to vibe code is something I’ll never understand. Also, I’ve heard rewriting people’s vibe coded efforts being a substantial issue, everything that engineers do nowadays seems to be code review.

It would be horrible to rewrite. Not the first commit or whatever. But after a few weeks of people not reading the code it looks more like a write only code base. I refused to go full vibe/agentic coding. So I got to see what was happening. This was only over a short period of time mind you. There was a lot of duplicate and triplicate methods. A lot of the classes were is-a related without inheritance, not the biggest deal but it was becoming a mess. Code I used to know well was more or less gone. It was rewritten in a way that wasn't the same approach and had lost lessons learned. Some of it had real battle wounds baked into it. Things qa passed the week before were broken in places no one thought they touched. A good deal of tests were useless or didn't mean anything for production. Code review is more or less impossible for me. I can read maybe a 1k line change. 20-30k changes all the time? You end up saying "sure buddy lgtm". We had someone put a 200kloc change for a new feature using a 3rd party tool no one had used before. No clue, but it was not my business apparently because we needed to be more individuals now that we were using AI

How do I do that? It takes a while. Don't ask me. It wasnt 200k it was like 170 something. I can't say too much but it was some big weird ETL pipeline using some weird database. Tons of weird algorithms for displaying data, by storing it all in memory? I don't know man I wasn't allowed to talk to whoever had swarms of agents create it. From what I understand of it it was a complete hazard Linux kernel has I think tens of millions of lines of code for reference.

I couldn't do it. It made me feel crazy. Looking back though, now I don't have a job and that stinks. Oh well at least I don't get nightmares about debugging the next production issue on call.

Can't you just tell Claude to fix it and if Claude can't fix it, it must be impossible to fix so oh well?

> The promise of this agentic workflow is always only a few weeks away. It's not been used to build anything that has made it to production yet. "We just need a swarm of many agents, all independently operating open-loop, creating and resolving tickets continuously. We will surely ship to production soon after implementing that!"

My company hired a lead architect and he stayed with us for less than a year. He introduced some overengineered shit we are still recovering from. How those people get to where they are and get hired for that kind of position is beyond me.

FWIW I was watching an interview with the founder of Claude Code and he claims that at Anthropic, no code is written by hand anymore. https://www.youtube.com/watch?v=SlGRN8jh2RI&pp=0gcJCQMLAYcqI...

That explains the spaghetti ball that is CC

This is one of the most insightful comment I've read on the subject in a a while minus the code review. All the described use cases are good enough for AI except code review which is hit or miss. But agentic coding is a snake oil.

the most productive teams will be the ones that treat code as compiler output (which we never read) legacy manual codebases which require human review will be the new "maintaining a FORTRAN mainframe". they'll stick around for longer than you'd expect (because they still work) , at legacy stagnant engineering companies

> related, i feel it's likely teams that go "all in" on agentic coding are going to inadvertently sabotage their product and their teams in the long run. They are trying to get warm by pissing their pants.

>People who cannot write code are building software. People who have never designed a data system are designing data systems. Most of it is not shipped; it is built, often for many hours, possibly shown internally with great vigor, used quietly, and occasionally surfaced to a client without much fanfare. This made me think of How I ship projects at big tech companies [1], specifically "Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped." [1] https://news.ycombinator.com/item?id=42111031

what would you say the disconnect was? Was it a simple case of that your teams' not comfortable with merging AI code?

I spent most of yesterday, deleting and replacing a bunch of code that was generated by an LLM. For the most part, the LLM's assistance has been great. For the most part. In this case, it decided to give me a whole bunch of crazy threaded code, and, for the first time, in many years, my app started crashing. My apps don't crash. They may have lots of other problems, but crashing isn't one of them. I'm anal. Sue me. For my own rule of thumb, I almost never dispatch to new threads. I will often let the OS SDK do it, and honor its choice, but there's very few places that I find spawning a worker, myself, actually buys me anything more than debugging misery. I know that doesn't apply to many types of applications, but it does apply to the ones I write. The LLM loves threads. I realized that this is probably because it got most of its training code from overenthusiastic folks, enamored with shiny tech. Anyway, after I gutted the screen, and added my own code, the performance increased markedly, and the crashes stopped. Lesson learned: Caveat Emptor .

Yes or boiler plate! I usually go in and tweak it anyways because it's not good. But it does help. This agentic coding thing is madness to me. I switched over to small local models. I do not need the vibe coder expensive models at all

I was tasked with coming up with a solution in 5 weeks which took another firm six months to produce. Never used agentic coding so much before or knew my code less well. Requirements are garbage though ,vague and just "copy what these other guys did, but better". I tried for. Couple of the weeks to get better specs but eventually gave up and just started building stuff to present.

Great article. If the author is browsing HN please hear me out. They say the pen is mightier than the sword. However the reason on why is not clear but I believe that because it can change minds. This article after re-reading possible changed my mind to abandon agentic coding!

yes, imho part of the problem of vibe coders is that training data is full of low quality advice/code, and it seems to me you won’t ever get rid of it. A perfect feedback loop to clean training data from bad advice/code without massive human intervention seems impossible as well.

"AI speedtracks bullshit shops into bullshit factories" is the other side of "AI enables efficiency gains beyond immagination". As a freelancer I get to see both in action. No surprise! Do you rememeber agile? Sometimes it was pragmatically applied towards efficiency, sometimes it became a bullshit religion full of priest and ceremonies. And on i could go, with more examples, the gist stays the same : new tools, speed increase, faster crash or faster travel depends on the trajectory the company/team/project/thing was already on. A special note on "People who cannot write code are building software." "Fuck yeah" to that! Devs has shipped bad software to people in other departements/domains, for ages. They would never build something better if what they had was good in the first place. When we (coders/startups) were doing it it was "innovation", now is "elephants in the china shop"? And this is not a rethorical snappy question: that IS innovation, instead of critizing the "wrong schema" ... understand the idea, help build it and do the job: ship code that works and is safe. Also, grey-beard here, pls, don't think you can ever have a stable job especially when code is around. It keeps changing, it always has, it always will. AI bringing unprecedented changes is hype. The world always changed fast. If "you" picked software development because of salary, you are in danger. If you did it because you love it, then tell me with a straight face this is not one of the best moments to be alive.

AI is another development that drives me absolutely mad. It's like jet fuel for people who leave a trail of technical debt for people who care more about that sort of thing to try to clean up. AI promises "you don't even need to understand the problem to get work done!" But the problem is doing the work is the how I understand problems, and understanding the problem is the bottleneck.

Imagine you hire an Engineer in your team. You find out he can't code. Yout have 4 major projects due this quarter. Are you going to become his 1-1 tutor from zero to 10 yoe hero coder in 3 months. Because he doesn't need help, he needs a time machine. (slop intended)

Problem is that it does not produce better or more work, it actually shifts the work to a different/future engineer. Today’s slop which gets engineer 1 a promotion, is engineer’s 2 problem next month when they are oncall and the codebase makes no sense. Your horse riding analogy, is like riding a horse into battle without your weapon because it’s slowing you down. Sure you got through the enemy first by outmanoeuvring, but you missed the point all together. Maybe you got a shiny medal but all your mates are dead.

And the added horror of prs that keep on coming. Correct looking code with no thoughts behind it.

The cope-ism in this blog post is palpable. The author is genuinely offended that someone who doesn't know how to code is daring to invade his turf. It's pretty sad that this is how he is reacting. I, for one, welcome the new paradigm shift of vibe coders entering the field. I still think I have a competitive advantage with my 30+ years of coding experience, but I don't think it's wrong for vibe coders to enter my turf. I think value of code is rapidly asymptotically to ZERO. Code has no value anymore. It doesn't matter if it's slop as long as it works. If you are one of the ones that believes that all code written by humans is sacred and infallible, you probably don't have a lot of experience working in many companies. Most human code is garbage anyway. If it's AI-generated, at least it's based on better best principles and if it's really bad you just need to reprompt it or wait for a newer version of the AI and it will automatically get better. THIS IS THE NEW PARADIGM. THINKING YOU HAVE ANY POWER TO SWAY THE FUTURE AWAY FROM THIS PATH IS FOOLISH. I'm currently running a migration program at work and it turns out there's a 10 MB limit to the number of entries I can batch over at one time. At first I asked AI to copy 10 rows per batch but that was too slow. Then I asked it to change the code to do 400 rows per batch but sometimes it failed because it exceeded the 10 MB limit. Then I said just collect the number of rows until you get 10 MB and then send it off. This is working perfectly and now I'm running it without any hitches so far. Then I asked it to add an estimate to how long it would take to finish after every batch, including end time. I really love this new world we're living in with AI coding. Sure this could have been done by someone without experience, but at least for right now the ideas I can come up with are much better than those without any experience, and that's hopefully the edge that keeps me employed. But whatever the new normal is, I'm ready to adapt.

> It doesn't matter if it's slop as long as it works I agree with most of what you said, but that statement doesn't take the time dimension into account. Slop accumulates, and eventually becomes unmanagable. We need to teach AI to become lean engineers too.

I disagree on both fronts. Unguided AI can be a very efficient tech debt generator.

just last week AI led a developer on our team to brick our git history when he was attempting to fix a deploy. he's not a git expert but an llm should of not led him that far astray, no? i see on a weekly basis where if an llm was left to do what its initial direction was without human oversight it would have broken otherwise working programs

Well this unlocked a new fear, I can imagine all the similar “nests” of AI generated content out there being created right now, I am likely to have to untangle one some day, or at least break it to someone that it’s garbage, almost as if the AI itself has built a nest and is hoarding artifacts but it’s actually the human deciding to bundle up the slop and put a bow on it.

Excellent article! Aptly describes what I have been feeling and thinking about the claims many AI optimists make. --- > He produced a great deal of code, [...] He could not, when asked, explain how any of it actually worked. [...] When opinions were voiced even as high as a V.P., he fought back. AI has democratized coding, but people have yet to understand that it takes expertise to actually design a system that can handle scale. Of course, you can build a PoC in a few hours with Claude code, but that wouldn't generate value. The reason why we see such examples in the workplace is because of the false marketing done by CEOs and wrapper companies. It just gives people a false hope that "they can just build things" when they can only build demos. Another reason is that the incentives in almost every company have shifted to favour a person using AI. It's like the companies are purposefully forcing us to use AI, to show demand for AI, so that they can get a green signal to build more data centers. --- > So you have overconfident, novices able to improve their individual productivity in an area of expertise they are unable to review for correctness. What could go wrong? This is one much-needed point to raise. I have many people around me saying that people my age are using AI to get 10x or 100x better at doing stuff. How are you evaluating them to check if the person actually improved that much? I have experienced this excessively on twitter since last few months. It is like a cult. Someone with a good following builds something with AI, and people go mad and perceive that person as some kind of god. I clearly don't understand that. Just as an example, after Karpathy open-sourced autoresearch, you might have seen a variety of different flavors that employ the same idea across various domains, but I think a Meta researcher pointed out that it is a type of search method, just like Optuna does with hyperparameter searching. Basically, people should think from first principles. But the current state of tech Twitter is pathetic; any lame idea + genAI gets viral, without even the slightest thought of whether genAI actually helps solve the problem or improve the existing solution. (Side note: I saw a blog from someone from a top USA uni writing about OpenClaw x AutoResearch, I was like WTF?! - because as we all know, OpenClaw was just a hype that aged like milk) --- > The slowness was not a tax on the real work; the slowness was the real work. Well Said! People should understand that learning things takes time, building things takes time, and understanding things deeply takes time. Someone building a web app using AI in 10 mins is not ahead but behind the person who is actually going one or two levels of abstractions deeper to understand how HTML/JS/Next.js works. I strongly believe that the tech industry will realise this sooner or later that AI doesn't make people learn faster, it just speeds up the repetitive manual tasks. And people should use the AI in that regard only. The (real) cognitive task to actually learn is still in the hands of humans, and it is slow, which is not a bottleneck, but that's just how we humans are, and it should be respected.