11 ms·

Refreshing to see an honest and balanced take on AI coding. This is what real AI-assisted coding looks like once you get past the initial wow factor of having t

Refreshing to see an honest and balanced take on AI coding. This is what real AI-assisted coding looks like once you get past the initial wow factor of having the AI write code that executes and does what you asked. This experience is familiar to every serious software engineer who has used AI code gen and then reviewed the output: > But when I reviewed the codebase in detail in late January, the downside was obvious: the codebase was complete spaghetti14. I didn’t understand large parts of the Python source extraction pipeline, functions were scattered in random files without a clear shape, and a few files had grown to several thousand lines. It was extremely fragile; it solved the immediate problem but it was never going to cope with my larger vision, Some people never get to the part where they review the code. They go straight to their LinkedIn or blog and start writing (or having ChatGPT write) posts about how manual coding is dead and they’re done writing code by hand forever. Some people review the code and declare it unusable garbage, then also go to their social media and post how AI coding is completely useless and they’re not going to use it for anything. This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now: A realization that AI coding tools can be a large accelerator but you need to learn how to use them correctly in your workflow and you need to remain involved in the code. It’s not as clickbaity as the extreme takes that get posted all the time. It’s a little disappointing to read the part where they said hard work was still required. It is a realistic and balanced take on the state of AI coding, though.

vasco 7mo ago
Those extreme takes are taken mostly for clicks or are exaggerated second hand so the "other side's" opinion is dumber than it is to "slam the naysayers". Most people are meh about everything, not on the extremes, so to pander to them you mock the extremes and make them seem more likely. It's just online populism.
libraryofbabel 7mo ago
Agree. This is such a good balanced article. The only things that still make the insights difficult to apply to professional software development are: this was greenfield work and it was a solo project. But that’s hardly the author’s fault. It would however be fantastic to see more articles like this about how to go all in on AI tools for brownfield projects involving more than one person. One thing I will add: I actually don’t think it’s wrong to start out building a vibe coded spaghetti mess for a project like this… provided you see it as a prototype you’re going to learn from and then throw away. A throwaway prototype is immensely useful because it helps you figure out what you want to build in the first place, before you step down a level and focus on closely guiding the agent to actually build it. The author’s mistake was that he thought the horrible prototype would evolve into the real thing. Of course it could not. But I suspect that the author’s final results when he did start afresh and build with closer attention to architecture were much better because he has learned more about the requirements for what he wanted to build from that first attempt.
- szundi 7mo ago
  [dead]
- argee 7mo ago
  This wasn't even just greenfield work, it included the exact type of work where AI arguably excels: extracting working code from an extant codebase (SQLite) as a reusable library. (It also included the type of work AI is really bad at: designing APIs sensibly.)
airstrike 7mo ago
It's a very accurate and relatable post. I think one corollary that's important to note to the anti-AI crowd is that this project, even if somewhat spaghettified, will likely take orders of magnitude less time to perfect than it would for someone to create the whole thing from scratch without AI. I often see criticism towards projects that are AI-driven that assumes that codebase is crystalized in time, when in fact humans can keep iterating with AI on it until it is better. We don't expect an AI-less project to be perfect in 0.1.0, so why expect that from AI? I know the answer is that the marketing and Twitter/LinkedIn slop makes those claims, but it's more useful to see past the hype and investigate how to use these tools which are invariably here to stay
- kaoD 7mo ago
  > this project, even if somewhat spaghettified, will likely take orders of magnitude less time to perfect than it would for someone to create the whole thing from scratch without AI That's a big leap of faith and... kinda contradicts the article as I understood it. My experience is entirely opposite (and matches my understanding of the article): vibing from the start makes you take orders of magnitude more time to perfect. AI is a multiplier as an assistant, but a divisor as an engineer.
  - airstrike 7mo ago
    vibing is different from... steering AI as it goes so it doesn't make fundamentally bad decisions
    - 0xbadcafebee 7mo ago
      Both of these are not really the right way to use AI to code with. There are two basic ways to code with AI that work: 1. Autocomplete. Pretty simple; you only accept auto-completes you actually want, as you manually write code. 2. Software engineering design and implementation workflow. The AI makes a plan, with tasks. It commits those plans to files. It starts sub-agents to tackle the tasks. The subagents create tests to validate the code, then writes code to pass the tests. The subagents finish their tasks, and the AI agent does a review of the work to see if it's accurate. Multiple passes find more bugs and fix them in a loop, until there is nothing left to fix. I'm amazed that nobody thinks the latter is a real thing that works, when Claude fucking Code has been produced this way for like 6 months. There's tens of thousands of people using this completely vibe-coded software. It's not a hoax.
zahlman 7mo ago
I feel like recently HN has been seeing more takes like this one and at least slightly less of the extremist clickbaity stuff. Maybe it's a sign of maturity. (Or maybe it's just fatigue with the cycle of hyping the absolute-latest model?)
- senko 7mo ago
  It takes time for people to go through these experiences (three months, in OP's case), and LLMs have only been reasonably good for a few months (since circa Nov'25). Previously, takes were necessarily shallower or not as insightful ("worked with caveats for me, ymmv") - there just wasn't enough data - although a few have posted fairly balanced takes (@mitsuhiko for example). I don't think we've seen the last of hypers and doomers though.
  - deaux 7mo ago
    > LLMs have only been reasonably good for a few months (since circa Nov'25). Ironically this itself is one of the hyper/doomer takes.
    - senko 7mo ago
      But is it a hyper or a doomer take? There seems to be a concencus among people I follow/read, that somewhere around that time was an inflexion point in coding LLMs, and this matches my personal experience. (My comment was in the context of LLMs being used to generate non-throwaway code, not general GenAI use - apologies if that was unclear.)
      - deaux 7mo ago
        > There seems to be a concencus among people I follow/read, that somewhere around that time was an inflexion point in coding LLMs, and this matches my personal experience. LLMs have been a very useful tool to generate non-throwaway code for at least 2 years. It's a question of Overton Window, of mainstream acceptance, that has made you and the people you're talking about come to a "consensus" that there was an agentic LLM coding step change around that time. There was indeed an inflection point, but it was a social one: a window shift, where it became socially acceptable among mainstream SWEs to hold this sentiment. It had already been the case for a long time, but for those who understood this, expressing that was still not deemed acceptable. Doing so would brand one as a hyper, at least in the particular circles you were in. You were in reality part of the doomers, just as much as the current doomers are still doomers.
yojo 7mo ago
+1 I’ve been driving Claude as my primary coding interface the last three months at my job. Other than a different domain, I feel like I could have written this exact article. The project I’m on started as a vibe-coded prototype that quickly got promoted to a production service we sell. I’ve had to build the mental model after the fact, while refactoring and ripping out large chunks of nonsense or dead code. But the product wouldn’t exist without that quick and dirty prototype, and I can use Claude as a goddamned chainsaw to clean up. On Friday, I finally added a type checker pre-commit hook and fixed the 90 existing errors (properly, no type ignores) in ~2 hours. I tried full-agentic first, and it failed miserably, then I went through error by error with Claude, we tightened up some exiting types, fixed some clunky abstractions, and got a nice, clean result. AI-assisted coding is amazing, but IMO for production code there’s no substitute for human review and guidance.
- ffsm8 7mo ago
  Fwiw, the article mirrors my experience when I started out too, even exactly with the same first month of vibecoding, then the next project which I did exactly like he outlined too. Personally, I think it's just the natural flow when you're starting out. If he keeps going, his opinion is going to change and as he gets to know it better, he'll likely go more and more towards vibecoding again. It's hard to say why, but you get better at it. Even if it's really hard to really put into words why
  - devmor 7mo ago
    [flagged]
    - ffsm8 7mo ago
      really? have you ever learned a skill? Like carving, singing, playing guitar, playing a video game, anything? It's easy to get better at it without understanding why you're better at it. As a matter of fact, very very few people master the discipline enough to be able to grasp the reason for why they're actually better Most people just come up with random shit which may or may not be related. Which I just abstained from.
hbarka 7mo ago
> Some people never get to the part where they review the code. They go straight to their LinkedIn or blog and start writing (or having ChatGPT write) posts about how manual coding is dead and they’re done writing code by hand forever. Some people review the code and declare it unusable garbage, then also go to their social media and post how AI coding is completely useless and they’re not going to use it for anything. This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now. What’s really happening is that you’re all of those people in the beginning. Those people are you as you go through the experience. You’re excited after seeing it do the impossible and in later instances you’re critical of the imperfections. It’s like the stages of grief, a sort of Kübler-Ross model for AI.
csallen 7mo ago
I'll take the other side of this. Professional software engineers like many of us have a big blind spot when it comes to AI coding, and that's a fixation on code quality. It makes sense to focus on code quality. We're not wrong. After all, we've spent our entire careers in the code. Bad code quality slows us down and makes things slow/insecure/unreliable/etc for end users. However, code quality is becoming less and less relevant in the age of AI coding, and to ignore that is to have our heads stuck in the sand. Just because we don't like it doesn't mean it's not true. There are two forces contributing to this: (1) more people coding smaller apps, and (2) improvements in coding models and agentic tools. We are increasingly moving toward a world where people who aren't sophisticated programmers are "building" their own apps with a user base of just one person. In many cases, these apps are simple and effective and come without the bloat that larger software suites have subjected users to for years. The code is simple, and even when it's not, nobody will ever have to maintain it, so it doesn't matter. Some apps will be unreliable, some will get hacked, some will be slow and inefficient, and it won't matter. This trend will continue to grow. At the same time, technology is improving, and the AI is increasingly good at designing and architecting software. We are in the very earliest months of AI actually being somewhat competent at this. It's unlikely that it will plateau and stop improving. And even when it finally does, if such a point comes, there will still be many years of improvements in tooling, as humanity's ability to make effective use of a technology always lags far behind the invention of the technology itself. So I'm right there with you in being annoyed by all the hype and exaggerated claims. But the "truth" about AI-assisted coding is changing every year, every quarter, every month. It's only trending in one direction. And it isn't going to stop.
- vlovich123 7mo ago
  > However, code quality is becoming less and less relevant in the age of AI coding, and to ignore that is to have our heads stuck in the sand. Just because we don't like it doesn't mean it's not true. Strong disagree. I just watched a team spend weeks trying to make a piece of code work with AI because the vibe coded was spaghetti garbage that even the AI couldn’t tell what needed to be done and was basically playing ineffective whackamole - it would fix the bug you ask it by reintroducing an old bug or introducing a new bug because no one understood what was happening. And humans couldn’t even step in like normal because no one understood what’s going on.
atomicnumber3 7mo ago
I'm deeply convinced that there's 2 reasons we don't see real takes like this: 1) is because these people are quietly appreciating the 2-50% uplift you get from sanely using LLMs instead of constantly posting sycophantic or doomer shit for clout and/or VC financing. 2) is because the real version of LLM coding is boring and unsexy. It either involves generating slop in one shot to POC, then restarting from scratch for the real thing or doing extensive remediation costing far more than the initial vibe effort cost; or it involves generally doing the same thing we've been doing since the assembler was created except now I don't need to remember off-hand how to rig up boilerplate for a table test harness in ${current_language}, or if I wrote a snippet with string ops and if statements and I wish it were using regexes and named capture groups, it's now easy to mostly-accurately convert it to the other form instead of just sighing and moving on. But that's boring nerd shit and LLMs didn't change who thinks boring nerd shit is boring or cool.
- devmor 7mo ago
  There’s also just the negative association factor. I use LLMs in my every day work. I’m also a strong critic of LLMs and absolutely loathe the hype cycle around them. I have done some really cool things with copilot and Claude and I keep sharing them to within my working circle because I simply don’t want to interact that much with people who aren’t grounded on the subject.
  - cossray 7mo ago
    I would be interested to hear your take on Copilot vs Claude. I have used Copilot (trial) in VS Code and I found it to mostly meet my needs. It could generate some plans and code, which I could review on the go. I found this very natural to me as I never felt 'left behind' in whatever code the AI was generating. However, most of the posts I see here are on Claude (I haven't tried it) and very few mentions of Copilot. What is your impression about them and the use cases each is strong in?
    - cassidy_co 7mo ago
      (Context: I'm a different person, but have thoughts on this) I started using Copilot at work because that's what the company policy was. It's a pretty strict environment, but it's perfectly serviceable and gets a lot of fresh, vetted updates. IDE integration with vs code was a huge plus for me. Claude code is definitely a messier, buggier frontend for the LLM. It's clunkier to navigate and it has much more primitive context management tools. IDE integration is clunky with vs code, too. However, if you want to take advantage of the Anthropic subscription services, I've found Claude Code is the way to go... Simply because Anthropic works hard to lock you into their ecosystem if you want the sweet discounts. I'm greedy, so I bit the bullet for all of the LLM coding stuff I do in my personal life.
sharperguy 7mo ago
It's actually common for human-written projects to go through an initial R&D phase where the first prototypes turn into spaghetti code and require a full rewrite. I haven't been through this myself with LLMs, but I wonder to what extent they could analyse the codebase, propose and then implement a better architecture based on the initial version.
- zozbot234 7mo ago
  If you write that first prototype in Rust, with the idiomatic style of "Rust exploratory code" (lots of defensive .clone()ing to avoid borrowck trouble; pervasive interior mutability; gratuitous use of Rc<> or Arc<> to simplify handling of the objects' lifecycle) that can often be incrementally refactored into a proper implementation. Very hard to do in other languages where you have no fixed boilerplate marking "this is the sloppy part".
  - klabb3 7mo ago
    Rust is a language for fast prototyping? That’s the one thing Rust is absolutely terrible at imo, and I really like the production/quality/safety aspects of Rust.
    - zozbot234 7mo ago
      It's not specialized to fast prototyping for sure, but you can use for that with the right boilerplate.
- Deukhoofd 7mo ago
  Let's be real, a lot of organizations never actually finish that R&D phase, and just continue iterating on their prototypes, and try to untangle the spaghetti for years. I recently had to rewrite a part of such a prototype that had 15 years of development on it, which was a massive headache. One of the most useful things I used LLMs for was asking it to compare the rewritten functionality with the old one, and find potential differences. While I was busy refactoring and redesigning the underlying architecture, I then sometimes was pinged by the LLM to investigate a potential difference. It sometimes included false positives, but it did help me spot small details that otherwise would have taken quite a while of debugging.
wolttam 7mo ago
> you need to learn how to use them correctly in your workflow and you need to remain involved in the code I completely agree that this is the case right now, but I do wonder how long it will remain the case.
throwatdem12311 7mo ago
For me it’s just a matter of “does this actually save me time at all?” If it generates the slop version in a week but it takes me 3 more weeks to clean it up, could I have I just done it right the first time myself in 4 weeks instead? How much money have I wasted in tokens?
- zephen 7mo ago
  > does this actually save me time at all? Soooooo.... As one who hasn't taken the plunge yet -- I'm basically retired, but have a couple of projects I might want to use AI for -- "time" is not always fungible with, or a good proxy for, either "effort" or "motivation" > How much money have I wasted in tokens? This, of course, may be a legitimate concern. > If it generates the slop version in a week but it takes me 3 more weeks to clean it up, could I have I just done it right the first time myself in 4 weeks instead? This likewise may be a legitimate concern, but sometimes the motivation for cleaning up a basically working piece of code is easier to find that the motivation for staring at a blank screen and trying to write that first function.
  - throwatdem12311 7mo ago
    Well for me, the amount of time/effort as a function my of my motivation has acted as a natural gatekeeper to bad ideas. Just because I can do something with AI now doesn’t necessarily mean that I should. I am also weary of trading time and effort for outright money right out of my own pocket to find out, especially when I find the people I’d be giving money to so reprehensible. I don’t live somewhere where developers make a lot of money. I’m not poor in any stretch but not rich enough that I can waste money on slop for funsies. But I can spend a month on validating a side project because I find coding as a hobby enjoyable in and of itself, and I don’t care if I throw out a few thousand lines of code after a little while and realize I’m wasting my time. Cleaning up agent slop code by hand is also a miserable experience and makes me hate my job. I do it already because at $DAYJOB because my boss thinks “investing” in third worlders for pennies on the dollar and just giving them a Claude subscription will be better than investing in technical excellence and leadership. The ROI on this strategy is questionable at best, at least at my current job. Code Review by humans is still the bottleneck and delivering proper working features has not accelerated because they require much more iteration because of slop. Would much rather spend the time making my own artisanal tradslop instead if it’s gonna take me the same amount of time anyway - at least it’s more enjoyable.
te_chris 7mo ago
Without wanting to sound rude: I think the mistake people make with AI prototypes is keeping the code at all. The AI’s are more than capable of producing a mountain of docs from which to rebuild, sanely. They’re really not that capable - without a lot of human pain - of making a shit codebase good.
deleted 7mo ago
[deleted]
moron4hire 7mo ago
Someone used Claude Code to generate a very simple staffing management app. The sort of thing that really wouldn't take that long to make, but why pay for any software when you can just ignore the problem, amiright? Anyway, the code that got generated was full of SQL injection issues for the most absurd sorts of things. It would have 80% of the database queries implemented through the ORM, but then the leftover stuff was raw string concat junk, for no good reason because it wasn't even doing any dynamic query or anything that the ORM couldn't do.
cush 7mo ago
Good code will stand the test of time. No matter how great a project is, there’s no world in which I adopt anything written over a few months and just released, for maintenance reasons alone.
beepbooptheory 7mo ago
I'm sorry, who is this for? Aren't you maybe a little tired of talking about this, if not totally <expletive> bored?? There is something at this point kind of surreal in the fact that you know everyday there will be this exact blog post and these exact comments. Like, its been literal years and years and yall are still talking about the thing thats supposed to do other things. What are we even doing anymore? Is this dead internet? It boggles the mind we are still at this level of discourse frankly. Love 'em hate 'em I don't care yall need to freaking get a grip! Like for the love god read a book, paint a picture! Do something else! This blog is just a journey to snooze town and we all must at some level know that. This feels like literal brain virus.
iamandoni 7mo ago
This is exactly why I built https://github.com/andonimichael/arxitect https://github.com/andonimichael/arxitect . I’ve found that agents by default produce tactical but brittle software. But if you teach agents to prioritize software architecture and design patterns, their code structure becomes much much better. Additionally, better structured code becomes more token efficient, requires less context to make changes, and coding agents become more accurate.
joe_the_user 7mo ago
This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now Is there evidence these groups are a minority? I mean, the OP sounds like they are taking the right approach but I suspect it requires both skill/experience and an open mind to take their approach. Just because an approach has good use-cases doesn't mean those are going predominate.
prpl 7mo ago
I find the people who end up with spaghetti code did so because they didn’t translate their normal processes over. Being completely methodical about development really helps. obra/superpowers, for example, gets close but I think it overindexes on testing and doesn’t go far enough with design document templates, planning, code style guides, code reviews, and more. Being methodical about it takes more time, but prevents a good bit of the tech debt. Planning modes help, but they are similarly not methodical enough.
- ianhorn 7mo ago
  That works until you make a plan/tests/etc, set the thing loose, and then when it has trouble it decides "actually the pragmatic thing would be [diverge from the plan/change the tests/etc]" and goes off the rails. I'm so frustrated by these things right now.
  - prpl 7mo ago
    I have honestly not had that problem much. Being specific, concise, and strong with your prompts helps out a lot.
nickstinemates 7mo ago
There is a lot you can do to shape the end result to not have these faults. In the end, the engineering mind and rigor still needs to apply, so the hard work doesn't go away. But, the errors that are described - no architecture adhesion, lack of comprehension, random files, etc. are a matter of not leveling up the sophistication of use further, not a gap in those tools. As an example. Very clearly laying out your architecture principles, guidance, how code should look on disk, theory on imports, etc. And then - objectively analyzing any proposed change against those principles, converges toward sane and understandable. We've been calling it adversarial testing across a number of dimensions - architecture, security, accessibility, among other things. Every pr gets automatically reviewed and scored based on these perspectives. If an adversary doesn't OK the PR, it doesn't get merged.
order-matters 7mo ago
i feel like it's worth noting that for a long time prior to AI, I heard a ton of anecdotes about codebases at big companies being very shitty spaghetti more often than not, and if one of the maintainers left it was often a nightmare of managing, refactoring, or in some cases re-writing whenever issues popped up with new integrations If AI needs to re-write everything from scratch everytime you make a design change, that may have some obvious inefficiencies and limitations to it but if it can also do that in a few hours or a week, is it really that bad comapred to months of stalling and excuses from devs trying to understand the work of someone before them who wasnt given enough time to make well documented clean code to begin with? Like it is undoubtedly worse for hobby projects to rely on the AI output 100%, but im actually not so sure for commercial products. It'll be the same type of spagetti garbage everywhere. There will be patterns in its nonsense that over years people will start to get accustomed to. Youll have people specialize in cleaning up AI generated code, and itll more or less be a relatively consistent process compared to picking up random developer spaghetti maybe this is a hot take though
socalgal2 7mo ago
Unfortunately there is a ton of pressure not to review code. AI enthusiasts see themselves in a race against others and code review = going slower. I recently attended a company wide "let's all use AI" conference and several talks were about how they were not reviewing much code anymore because the PRs were coming in 10x to 50x more and they just couldn't keep up. Scary AF
bmitc 7mo ago
> This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now: A realization that AI coding tools can be a large accelerator but you need to learn how to use them correctly in your workflow and you need to remain involved in the code. It’s not as clickbaity as the extreme takes that get posted all the time. It’s a little disappointing to read the part where they said hard work was still required. It is a realistic and balanced take on the state of AI coding, though. I appreciate the balanced takes and also the notion that one can use these AI tools to build software with principled use. However, what I am still failing to see is concrete evidence that this is all faster and cheaper than just a human learning and doing everything themself or with a small team. The cat is out of the bag, so to speak, but I think it's still correct to question these things. I am putting in a _lot_ of work to reach a principled status quo with these tools, and it is still quite unclear whether it's actually improvement versus just a side quest to wrangle tools that everyone else is abusing.

vasco 7mo ago

Those extreme takes are taken mostly for clicks or are exaggerated second hand so the "other side's" opinion is dumber than it is to "slam the naysayers". Most people are meh about everything, not on the extremes, so to pander to them you mock the extremes and make them seem more likely. It's just online populism.

libraryofbabel 7mo ago

Agree. This is such a good balanced article. The only things that still make the insights difficult to apply to professional software development are: this was greenfield work and it was a solo project. But that’s hardly the author’s fault. It would however be fantastic to see more articles like this about how to go all in on AI tools for brownfield projects involving more than one person. One thing I will add: I actually don’t think it’s wrong to start out building a vibe coded spaghetti mess for a project like this… provided you see it as a prototype you’re going to learn from and then throw away. A throwaway prototype is immensely useful because it helps you figure out what you want to build in the first place, before you step down a level and focus on closely guiding the agent to actually build it. The author’s mistake was that he thought the horrible prototype would evolve into the real thing. Of course it could not. But I suspect that the author’s final results when he did start afresh and build with closer attention to architecture were much better because he has learned more about the requirements for what he wanted to build from that first attempt.

szundi 7mo ago
[dead]
argee 7mo ago
This wasn't even just greenfield work, it included the exact type of work where AI arguably excels: extracting working code from an extant codebase (SQLite) as a reusable library. (It also included the type of work AI is really bad at: designing APIs sensibly.)

airstrike 7mo ago

It's a very accurate and relatable post. I think one corollary that's important to note to the anti-AI crowd is that this project, even if somewhat spaghettified, will likely take orders of magnitude less time to perfect than it would for someone to create the whole thing from scratch without AI. I often see criticism towards projects that are AI-driven that assumes that codebase is crystalized in time, when in fact humans can keep iterating with AI on it until it is better. We don't expect an AI-less project to be perfect in 0.1.0, so why expect that from AI? I know the answer is that the marketing and Twitter/LinkedIn slop makes those claims, but it's more useful to see past the hype and investigate how to use these tools which are invariably here to stay

kaoD 7mo ago
> this project, even if somewhat spaghettified, will likely take orders of magnitude less time to perfect than it would for someone to create the whole thing from scratch without AI That's a big leap of faith and... kinda contradicts the article as I understood it. My experience is entirely opposite (and matches my understanding of the article): vibing from the start makes you take orders of magnitude more time to perfect. AI is a multiplier as an assistant, but a divisor as an engineer.
- airstrike 7mo ago
  vibing is different from... steering AI as it goes so it doesn't make fundamentally bad decisions
  - 0xbadcafebee 7mo ago
    Both of these are not really the right way to use AI to code with. There are two basic ways to code with AI that work: 1. Autocomplete. Pretty simple; you only accept auto-completes you actually want, as you manually write code. 2. Software engineering design and implementation workflow. The AI makes a plan, with tasks. It commits those plans to files. It starts sub-agents to tackle the tasks. The subagents create tests to validate the code, then writes code to pass the tests. The subagents finish their tasks, and the AI agent does a review of the work to see if it's accurate. Multiple passes find more bugs and fix them in a loop, until there is nothing left to fix. I'm amazed that nobody thinks the latter is a real thing that works, when Claude fucking Code has been produced this way for like 6 months. There's tens of thousands of people using this completely vibe-coded software. It's not a hoax.

zahlman 7mo ago

I feel like recently HN has been seeing more takes like this one and at least slightly less of the extremist clickbaity stuff. Maybe it's a sign of maturity. (Or maybe it's just fatigue with the cycle of hyping the absolute-latest model?)

senko 7mo ago
It takes time for people to go through these experiences (three months, in OP's case), and LLMs have only been reasonably good for a few months (since circa Nov'25). Previously, takes were necessarily shallower or not as insightful ("worked with caveats for me, ymmv") - there just wasn't enough data - although a few have posted fairly balanced takes (@mitsuhiko for example). I don't think we've seen the last of hypers and doomers though.
- deaux 7mo ago
  > LLMs have only been reasonably good for a few months (since circa Nov'25). Ironically this itself is one of the hyper/doomer takes.
  - senko 7mo ago
    But is it a hyper or a doomer take? There seems to be a concencus among people I follow/read, that somewhere around that time was an inflexion point in coding LLMs, and this matches my personal experience. (My comment was in the context of LLMs being used to generate non-throwaway code, not general GenAI use - apologies if that was unclear.)
    - deaux 7mo ago
      > There seems to be a concencus among people I follow/read, that somewhere around that time was an inflexion point in coding LLMs, and this matches my personal experience. LLMs have been a very useful tool to generate non-throwaway code for at least 2 years. It's a question of Overton Window, of mainstream acceptance, that has made you and the people you're talking about come to a "consensus" that there was an agentic LLM coding step change around that time. There was indeed an inflection point, but it was a social one: a window shift, where it became socially acceptable among mainstream SWEs to hold this sentiment. It had already been the case for a long time, but for those who understood this, expressing that was still not deemed acceptable. Doing so would brand one as a hyper, at least in the particular circles you were in. You were in reality part of the doomers, just as much as the current doomers are still doomers.

yojo 7mo ago

+1 I’ve been driving Claude as my primary coding interface the last three months at my job. Other than a different domain, I feel like I could have written this exact article. The project I’m on started as a vibe-coded prototype that quickly got promoted to a production service we sell. I’ve had to build the mental model after the fact, while refactoring and ripping out large chunks of nonsense or dead code. But the product wouldn’t exist without that quick and dirty prototype, and I can use Claude as a goddamned chainsaw to clean up. On Friday, I finally added a type checker pre-commit hook and fixed the 90 existing errors (properly, no type ignores) in ~2 hours. I tried full-agentic first, and it failed miserably, then I went through error by error with Claude, we tightened up some exiting types, fixed some clunky abstractions, and got a nice, clean result. AI-assisted coding is amazing, but IMO for production code there’s no substitute for human review and guidance.

ffsm8 7mo ago
Fwiw, the article mirrors my experience when I started out too, even exactly with the same first month of vibecoding, then the next project which I did exactly like he outlined too. Personally, I think it's just the natural flow when you're starting out. If he keeps going, his opinion is going to change and as he gets to know it better, he'll likely go more and more towards vibecoding again. It's hard to say why, but you get better at it. Even if it's really hard to really put into words why
- devmor 7mo ago
  [flagged]
  - ffsm8 7mo ago
    really? have you ever learned a skill? Like carving, singing, playing guitar, playing a video game, anything? It's easy to get better at it without understanding why you're better at it. As a matter of fact, very very few people master the discipline enough to be able to grasp the reason for why they're actually better Most people just come up with random shit which may or may not be related. Which I just abstained from.

hbarka 7mo ago

> Some people never get to the part where they review the code. They go straight to their LinkedIn or blog and start writing (or having ChatGPT write) posts about how manual coding is dead and they’re done writing code by hand forever. Some people review the code and declare it unusable garbage, then also go to their social media and post how AI coding is completely useless and they’re not going to use it for anything. This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now. What’s really happening is that you’re all of those people in the beginning. Those people are you as you go through the experience. You’re excited after seeing it do the impossible and in later instances you’re critical of the imperfections. It’s like the stages of grief, a sort of Kübler-Ross model for AI.

csallen 7mo ago

I'll take the other side of this. Professional software engineers like many of us have a big blind spot when it comes to AI coding, and that's a fixation on code quality. It makes sense to focus on code quality. We're not wrong. After all, we've spent our entire careers in the code. Bad code quality slows us down and makes things slow/insecure/unreliable/etc for end users. However, code quality is becoming less and less relevant in the age of AI coding, and to ignore that is to have our heads stuck in the sand. Just because we don't like it doesn't mean it's not true. There are two forces contributing to this: (1) more people coding smaller apps, and (2) improvements in coding models and agentic tools. We are increasingly moving toward a world where people who aren't sophisticated programmers are "building" their own apps with a user base of just one person. In many cases, these apps are simple and effective and come without the bloat that larger software suites have subjected users to for years. The code is simple, and even when it's not, nobody will ever have to maintain it, so it doesn't matter. Some apps will be unreliable, some will get hacked, some will be slow and inefficient, and it won't matter. This trend will continue to grow. At the same time, technology is improving, and the AI is increasingly good at designing and architecting software. We are in the very earliest months of AI actually being somewhat competent at this. It's unlikely that it will plateau and stop improving. And even when it finally does, if such a point comes, there will still be many years of improvements in tooling, as humanity's ability to make effective use of a technology always lags far behind the invention of the technology itself. So I'm right there with you in being annoyed by all the hype and exaggerated claims. But the "truth" about AI-assisted coding is changing every year, every quarter, every month. It's only trending in one direction. And it isn't going to stop.

vlovich123 7mo ago
> However, code quality is becoming less and less relevant in the age of AI coding, and to ignore that is to have our heads stuck in the sand. Just because we don't like it doesn't mean it's not true. Strong disagree. I just watched a team spend weeks trying to make a piece of code work with AI because the vibe coded was spaghetti garbage that even the AI couldn’t tell what needed to be done and was basically playing ineffective whackamole - it would fix the bug you ask it by reintroducing an old bug or introducing a new bug because no one understood what was happening. And humans couldn’t even step in like normal because no one understood what’s going on.

atomicnumber3 7mo ago

I'm deeply convinced that there's 2 reasons we don't see real takes like this: 1) is because these people are quietly appreciating the 2-50% uplift you get from sanely using LLMs instead of constantly posting sycophantic or doomer shit for clout and/or VC financing. 2) is because the real version of LLM coding is boring and unsexy. It either involves generating slop in one shot to POC, then restarting from scratch for the real thing or doing extensive remediation costing far more than the initial vibe effort cost; or it involves generally doing the same thing we've been doing since the assembler was created except now I don't need to remember off-hand how to rig up boilerplate for a table test harness in ${current_language}, or if I wrote a snippet with string ops and if statements and I wish it were using regexes and named capture groups, it's now easy to mostly-accurately convert it to the other form instead of just sighing and moving on. But that's boring nerd shit and LLMs didn't change who thinks boring nerd shit is boring or cool.

devmor 7mo ago
There’s also just the negative association factor. I use LLMs in my every day work. I’m also a strong critic of LLMs and absolutely loathe the hype cycle around them. I have done some really cool things with copilot and Claude and I keep sharing them to within my working circle because I simply don’t want to interact that much with people who aren’t grounded on the subject.
- cossray 7mo ago
  I would be interested to hear your take on Copilot vs Claude. I have used Copilot (trial) in VS Code and I found it to mostly meet my needs. It could generate some plans and code, which I could review on the go. I found this very natural to me as I never felt 'left behind' in whatever code the AI was generating. However, most of the posts I see here are on Claude (I haven't tried it) and very few mentions of Copilot. What is your impression about them and the use cases each is strong in?
  - cassidy_co 7mo ago
    (Context: I'm a different person, but have thoughts on this) I started using Copilot at work because that's what the company policy was. It's a pretty strict environment, but it's perfectly serviceable and gets a lot of fresh, vetted updates. IDE integration with vs code was a huge plus for me. Claude code is definitely a messier, buggier frontend for the LLM. It's clunkier to navigate and it has much more primitive context management tools. IDE integration is clunky with vs code, too. However, if you want to take advantage of the Anthropic subscription services, I've found Claude Code is the way to go... Simply because Anthropic works hard to lock you into their ecosystem if you want the sweet discounts. I'm greedy, so I bit the bullet for all of the LLM coding stuff I do in my personal life.

sharperguy 7mo ago

It's actually common for human-written projects to go through an initial R&D phase where the first prototypes turn into spaghetti code and require a full rewrite. I haven't been through this myself with LLMs, but I wonder to what extent they could analyse the codebase, propose and then implement a better architecture based on the initial version.

zozbot234 7mo ago
If you write that first prototype in Rust, with the idiomatic style of "Rust exploratory code" (lots of defensive .clone()ing to avoid borrowck trouble; pervasive interior mutability; gratuitous use of Rc<> or Arc<> to simplify handling of the objects' lifecycle) that can often be incrementally refactored into a proper implementation. Very hard to do in other languages where you have no fixed boilerplate marking "this is the sloppy part".
- klabb3 7mo ago
  Rust is a language for fast prototyping? That’s the one thing Rust is absolutely terrible at imo, and I really like the production/quality/safety aspects of Rust.
  - zozbot234 7mo ago
    It's not specialized to fast prototyping for sure, but you can use for that with the right boilerplate.
Deukhoofd 7mo ago
Let's be real, a lot of organizations never actually finish that R&D phase, and just continue iterating on their prototypes, and try to untangle the spaghetti for years. I recently had to rewrite a part of such a prototype that had 15 years of development on it, which was a massive headache. One of the most useful things I used LLMs for was asking it to compare the rewritten functionality with the old one, and find potential differences. While I was busy refactoring and redesigning the underlying architecture, I then sometimes was pinged by the LLM to investigate a potential difference. It sometimes included false positives, but it did help me spot small details that otherwise would have taken quite a while of debugging.

wolttam 7mo ago

> you need to learn how to use them correctly in your workflow and you need to remain involved in the code I completely agree that this is the case right now, but I do wonder how long it will remain the case.

throwatdem12311 7mo ago

For me it’s just a matter of “does this actually save me time at all?” If it generates the slop version in a week but it takes me 3 more weeks to clean it up, could I have I just done it right the first time myself in 4 weeks instead? How much money have I wasted in tokens?

zephen 7mo ago
> does this actually save me time at all? Soooooo.... As one who hasn't taken the plunge yet -- I'm basically retired, but have a couple of projects I might want to use AI for -- "time" is not always fungible with, or a good proxy for, either "effort" or "motivation" > How much money have I wasted in tokens? This, of course, may be a legitimate concern. > If it generates the slop version in a week but it takes me 3 more weeks to clean it up, could I have I just done it right the first time myself in 4 weeks instead? This likewise may be a legitimate concern, but sometimes the motivation for cleaning up a basically working piece of code is easier to find that the motivation for staring at a blank screen and trying to write that first function.
- throwatdem12311 7mo ago
  Well for me, the amount of time/effort as a function my of my motivation has acted as a natural gatekeeper to bad ideas. Just because I can do something with AI now doesn’t necessarily mean that I should. I am also weary of trading time and effort for outright money right out of my own pocket to find out, especially when I find the people I’d be giving money to so reprehensible. I don’t live somewhere where developers make a lot of money. I’m not poor in any stretch but not rich enough that I can waste money on slop for funsies. But I can spend a month on validating a side project because I find coding as a hobby enjoyable in and of itself, and I don’t care if I throw out a few thousand lines of code after a little while and realize I’m wasting my time. Cleaning up agent slop code by hand is also a miserable experience and makes me hate my job. I do it already because at $DAYJOB because my boss thinks “investing” in third worlders for pennies on the dollar and just giving them a Claude subscription will be better than investing in technical excellence and leadership. The ROI on this strategy is questionable at best, at least at my current job. Code Review by humans is still the bottleneck and delivering proper working features has not accelerated because they require much more iteration because of slop. Would much rather spend the time making my own artisanal tradslop instead if it’s gonna take me the same amount of time anyway - at least it’s more enjoyable.

te_chris 7mo ago

Without wanting to sound rude: I think the mistake people make with AI prototypes is keeping the code at all. The AI’s are more than capable of producing a mountain of docs from which to rebuild, sanely. They’re really not that capable - without a lot of human pain - of making a shit codebase good.

deleted 7mo ago

[deleted]

moron4hire 7mo ago

Someone used Claude Code to generate a very simple staffing management app. The sort of thing that really wouldn't take that long to make, but why pay for any software when you can just ignore the problem, amiright? Anyway, the code that got generated was full of SQL injection issues for the most absurd sorts of things. It would have 80% of the database queries implemented through the ORM, but then the leftover stuff was raw string concat junk, for no good reason because it wasn't even doing any dynamic query or anything that the ORM couldn't do.

cush 7mo ago

Good code will stand the test of time. No matter how great a project is, there’s no world in which I adopt anything written over a few months and just released, for maintenance reasons alone.

beepbooptheory 7mo ago

I'm sorry, who is this for? Aren't you maybe a little tired of talking about this, if not totally <expletive> bored?? There is something at this point kind of surreal in the fact that you know everyday there will be this exact blog post and these exact comments. Like, its been literal years and years and yall are still talking about the thing thats supposed to do other things. What are we even doing anymore? Is this dead internet? It boggles the mind we are still at this level of discourse frankly. Love 'em hate 'em I don't care yall need to freaking get a grip! Like for the love god read a book, paint a picture! Do something else! This blog is just a journey to snooze town and we all must at some level know that. This feels like literal brain virus.

iamandoni 7mo ago

This is exactly why I built https://github.com/andonimichael/arxitect https://github.com/andonimichael/arxitect . I’ve found that agents by default produce tactical but brittle software. But if you teach agents to prioritize software architecture and design patterns, their code structure becomes much much better. Additionally, better structured code becomes more token efficient, requires less context to make changes, and coding agents become more accurate.

joe_the_user 7mo ago

This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now Is there evidence these groups are a minority? I mean, the OP sounds like they are taking the right approach but I suspect it requires both skill/experience and an open mind to take their approach. Just because an approach has good use-cases doesn't mean those are going predominate.

prpl 7mo ago

I find the people who end up with spaghetti code did so because they didn’t translate their normal processes over. Being completely methodical about development really helps. obra/superpowers, for example, gets close but I think it overindexes on testing and doesn’t go far enough with design document templates, planning, code style guides, code reviews, and more. Being methodical about it takes more time, but prevents a good bit of the tech debt. Planning modes help, but they are similarly not methodical enough.

ianhorn 7mo ago
That works until you make a plan/tests/etc, set the thing loose, and then when it has trouble it decides "actually the pragmatic thing would be [diverge from the plan/change the tests/etc]" and goes off the rails. I'm so frustrated by these things right now.
- prpl 7mo ago
  I have honestly not had that problem much. Being specific, concise, and strong with your prompts helps out a lot.

nickstinemates 7mo ago

There is a lot you can do to shape the end result to not have these faults. In the end, the engineering mind and rigor still needs to apply, so the hard work doesn't go away. But, the errors that are described - no architecture adhesion, lack of comprehension, random files, etc. are a matter of not leveling up the sophistication of use further, not a gap in those tools. As an example. Very clearly laying out your architecture principles, guidance, how code should look on disk, theory on imports, etc. And then - objectively analyzing any proposed change against those principles, converges toward sane and understandable. We've been calling it adversarial testing across a number of dimensions - architecture, security, accessibility, among other things. Every pr gets automatically reviewed and scored based on these perspectives. If an adversary doesn't OK the PR, it doesn't get merged.

order-matters 7mo ago

i feel like it's worth noting that for a long time prior to AI, I heard a ton of anecdotes about codebases at big companies being very shitty spaghetti more often than not, and if one of the maintainers left it was often a nightmare of managing, refactoring, or in some cases re-writing whenever issues popped up with new integrations If AI needs to re-write everything from scratch everytime you make a design change, that may have some obvious inefficiencies and limitations to it but if it can also do that in a few hours or a week, is it really that bad comapred to months of stalling and excuses from devs trying to understand the work of someone before them who wasnt given enough time to make well documented clean code to begin with? Like it is undoubtedly worse for hobby projects to rely on the AI output 100%, but im actually not so sure for commercial products. It'll be the same type of spagetti garbage everywhere. There will be patterns in its nonsense that over years people will start to get accustomed to. Youll have people specialize in cleaning up AI generated code, and itll more or less be a relatively consistent process compared to picking up random developer spaghetti maybe this is a hot take though

socalgal2 7mo ago

Unfortunately there is a ton of pressure not to review code. AI enthusiasts see themselves in a race against others and code review = going slower. I recently attended a company wide "let's all use AI" conference and several talks were about how they were not reviewing much code anymore because the PRs were coming in 10x to 50x more and they just couldn't keep up. Scary AF

bmitc 7mo ago

> This blog post shows the journey that anyone not in one of those two vocal minorities is going through right now: A realization that AI coding tools can be a large accelerator but you need to learn how to use them correctly in your workflow and you need to remain involved in the code. It’s not as clickbaity as the extreme takes that get posted all the time. It’s a little disappointing to read the part where they said hard work was still required. It is a realistic and balanced take on the state of AI coding, though. I appreciate the balanced takes and also the notion that one can use these AI tools to build software with principled use. However, what I am still failing to see is concrete evidence that this is all faster and cheaper than just a human learning and doing everything themself or with a small team. The cat is out of the bag, so to speak, but I think it's still correct to question these things. I am putting in a _lot_ of work to reach a principled status quo with these tools, and it is still quite unclear whether it's actually improvement versus just a side quest to wrangle tools that everyone else is abusing.