What Is Going on Right Now?
Key topics
The author expresses frustration with the misuse of AI tools in software development, leading to low-quality code, and the discussion revolves around the implications and potential consequences of relying on AI-generated code.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6h
Peak period
140
Day 1
Avg / period
20
Based on 160 loaded comments
Key moments
- 01Story posted
Aug 22, 2025 at 3:08 AM EDT
4 months ago
Step 01 - 02First comment
Aug 22, 2025 at 8:58 AM EDT
6h after posting
Step 02 - 03Peak activity
140 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 30, 2025 at 8:05 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I don't want to move again and it's a terrible time to try, partly because of this nonsense. So where we are.
There's a glut of junior dev talent and not enough real problems out there which a junior can apply themselves to.
This means that most of them simply arent able to get the kind of experience which will push them into the next skill bracket.
It used to be that you could use them to build cheap proofs of concept or self contained scripting but those are things AI doesnt actually suck too badly at. Even back then there were too many juniors and not enough roles though.
Though cleaning up garbage fires isn't exactly fun. Gonna need to raise my rates.
This is what I did way back when I was a professional web designer. Cleaning up nasty "tag-soup" DreamWeaver and MS Word websites for folks cost extra compared to my normal rates for just building them a fresh "from-scratch" website.
I've been fighting this battle for years in my org and every time we start to make progress we go through yet another crisis and have to let some of our junior staff go. Then when we need to hire again it's an emergency and we can only hire more senior staff because we need to get things done and nobody is there to fill the gaps.
It's been a vicious cycle to break.
Using it well requires a competent team, working together with trust and transparency, to build processes that are designed to effectively balance human guidance/expertise with what LLM's are good at. Small teams are doing very big things with it.
Most organizations, especially large organizations, are so far away from a healthy culture that AI is amplifying the impact of that toxicity.
Executives who interpret "Story Points" as "how much time is that going to take" are asking why everything isn't half a point now. They're so far removed from the process of building maintainable and effective software that they're simply looking for AI to serve as a simple pass through to the bottom line.
The recent study showing that 95% of AI pilots failed to deliver ROI is a case study in the ineffectiveness of modern management to actually do their jobs.
besides just weird or broken code, anything exposed to user input is usually severly lacking sanity checks etc.
llms are not useless for coding. but imho letting llms do the coding will not yield production grade code.
Move hand this way and a human will give a banana.
LLMs have no understanding at all of the underlying language, they've just seen that a billion times a task looks like such and such, so have these tokens after them.
It's a model. It either predicts usefully or not. How it works is mostly irrelevant.
("But it works - when it works" is a tautology, not a useful model)
all i know about these LLMs is that even if they understand language or can create it, they know nothing of the subjects they speak of.
copilot told me to cast an int to str to get rid of an error.
thanks copilot, it was on kernel code.
glad i didnt do it :/. just closed browser and opened man pages. i get nowhere with these things. it feels u need to understand so much its likely less typing to write the code. code is concise and clear after all, mostly unambiguous. language on the other hand...
i do like it as a bit of a glorified google, but looking at what code it outputs my confidence it its findings lessens every prompt
As a recent example of this, I was recently curious about how the heart gets the oxygen depleted blood back to the heart. Pumping blood out made sense to me, but the return path was less obvious.
So I asked chatgpt whether the heart sucks in the blood from veins.
It told me that the heart does not suck in the blood, it creates a negative pressure zone that causes the blood to flow into it ... :facepalm:
Sure, my language was non-technical/imprecise, but I bet if I asked a cardiologist about this they would have said something like "That's not the language I would have used, but basically."
I don't know why, but lately I've been getting a lot of cases where these models contradicts themself even within the same response. I'm working out a lot (debating a triathlon) and it told me to swim and do upper body weight lifting on the same day to "avoid working out the same muscle group in the same day". Similarly it told me to run and do leg workouts on the same day.
> i do like it as a bit of a glorified google, but looking at what code it outputs my confidence it its findings lessens every prompt
I'm having the exact same reaction. I'm finding they are still more useful than google, even with an error rate close to 70%, but I am quickly learning that you can't trust anything they output and should double check everything.
maybe this is the effect of the LLMs interacting with eachother, the dumbing down. gpt-6 will be a markov chain again and gpt-7 will know that f!sh go m00!
edit: Not a programmer. Just a guy who needs some stuff done for some of the things I need to work on.
https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vib...
Is there any example of successful companies created mostly/entirely by "vibe coding" that isn't itself a company in the AI hype? I haven't seen any, all examples so far are similar to yours.
We'll see how well they scale.
I'm in a tiny team of 3 writing b2b software in the energy space and claude code is a godsend for the fiddly-but-brain-dead parts of the job (config stuff, managing cloud infra, one-and-done scripts, little single page dashboards, etc).
We've had much less success with the more complex things like maintaining various linear programming/neural net models we've written. It's really good at breaking stuff in subtle ways (like removing L2 regularisation from a VAE while visually it still looks like it's implemented). But personally I still think the juice is worth the squeeze, mainly I find it saves me mental energy I can use elsewhere.
A demise that in the case of a modern dysfunctional organisation would otherwise often be arriving a few years later as a results of complete and utter bureaucratic failure.
My experience is that all attempts to elevate technology to a "pivotal force" for the worse is always missing the underlying social and moral failure of the majority (or a small, but important, managerial minority) to act for the common good rather than egotistic self-interest.
Vikings with drones would endanger commercial airspace.
Vikings with nuclear weapons would be funny, from a distance.
Instruments are not inculpable as you think they are.
aside, but I have yet to meet a single person (dev, qa, pm, exec) who doesn't do this.
This reads a bit like "you're holding it wrong". If you need your team and organization to already be in a perfect state before AI usage will stop doing damage, what is the point of it in the first place.
Especially if AI is promoted as a "magic bullet" that will likely especially be uses by teams that are already dysfunctional.
Another claim for AI success, followed by, nothing specific
These juniors you're complaining about are going to get better in making these requests of AI and blow right past all the seniors who yell at clouds running AI.
I don’t use Claude code for everything. I’ve fallen off the bike enough times to know when I’ll be better off writing the changes myself. Even in these cases, though, I still plan with Claude, rubber duck, have it review, have it brainstorm ideas (“I need to do x, I’m thinking about doing it such and such way, can you brainstorm a few more options?”)
I agree with your comment up to a point, but this is pretty similar to pilots and autopilots. At the end of the day you still need a pilot to figure out non standard issues and make judgement calls.
The junior blowing past is as good as how long he will take to fix this issue that all the credits/prompts in the world are not solving. If the impact is long and costs enough your vibe coders will have good instantaneous speed but never reach the end.
I am optimist about AI usage as a tool to enhance productivity, but the workflows are still being worked out. It currently is neither fire all devs, nor No LLM allowed. It is definitely an exciting time to be a senior though :)
I've been coding for 25 years and what I feel reading posts & comments like in this thread is what I felt in the first few days of that black-blue/white-gold dress thing. I legitimately felt like half the people were trolling.
It's the same with LLM assisted coding. I can't possibly be getting such good results when all the rest are getting garbage, right? Impostor syndrome? Are they trolling?
But yeah, I agree fully with you. You need to actively try everything yourself, and this is what I recommend to my colleagues and friends. Try it out. See what works and what doesn't. Focus on what works, and put it in markdown files. Avoid what doesn't work today, but be ready because tomorrow it might work. Use flows. Use plan / act accordingly. Use the correct tools (context7 is a big one). Use search before planning. Search, write it to md files, add it in the repo. READ the plans carefully. Edit before you start a task. Edit, edit edit. Use git trees, use tools that you'd be using anyway in your pipelines. Pay attention to the output. Don't argue, go back to step1, plan better. See what works for context, what doesn't work. Add things, remove things. Have examples ready. Use examples properly. There's sooo much to learn here.
If someone told me that their Tesla's autopilot swerved them into a brick wall and they nearly died, I'm not going to say, "your newfound luddite bias is preventing you from seeking sensible middle ground. Surely there is no serious issue here." I'm going to say, "wow, that's fucked up. Maybe there's something deeply wrong with Tesla autopilot."
What a horrible metaphor for a tool that can translate pdfs to text. lol. The anti-AI arguments are just as, if not more, absurd than the "AI can do everything" arguments.
I'm gonna need you to know that just because some random dev who wrote a blog said something doesn't make it true. You know that, right?
> Don't pretend that there are no negative consequences to the proliferation of AI tools.
Wait, what? Who said otherwise?
I love how you compare this tool to a Tesla's Autopilot mode, then get called out on it, and are like "Are you saying these tools are perfect" lol.
> What a horrible metaphor for a tool that can translate pdfs to text. lol.
You didn't say otherwise explicitly, but you're definitely downplaying the issues discussed in the blog post.
> I'm gonna need you to know that just because some random dev who wrote a blog said something doesn't make it true.
That's not really a satisfying response. If you disagree with the post, you'll have to mount a more substantial rebuttal than, "well what if he's wrong, huh? Have you considered that?"
Sure, and that's very different from "the idea of self-driving cars is a giant scam that will never work".
Can any program be broken down into functions and functions of functions that have inputs and outputs so that they can be verified if they are working?
When adding machines and calculators appeared in offices, detractors claimed they would weaken the mind. In the mid-20th century, some educators derided calculator users as “button pushers” rather than “real mathematicians.”
In the 1980s, early adopters of personal computers and word processors were sometimes called “typists with toys.” Secretaries who mastered word processors were sometimes derided as “not real secretaries” because they lacked shorthand or dictation skills.
Architects and engineers who switched from drafting tables to CAD in the 1970s–80s faced accusations that CAD work was “cookie-cutter” and lacked craftsmanship. Traditional draftsmen argued that “real” design required hand drawing, while CAD users were seen as letting the machine think for them.
Across history, the insults usually follow the same structure:
- Suggesting the new tool makes the work too easy, therefore less valuable.
- Positioning users as “operators” rather than “thinkers.”
- Romanticizing the older skill as more “authentic” or “serious.”
That's a claim you're making for the first time, here. Not one I've made. Go ahead and re-read my comments to verify.
That variable is undefined in multiple constructors. Also your code cannot compile in various scenarios. Have a nice day.
So this doesn't seem relevant to the conversation about LLMs, Rust, and software quality improvement methods from strict typing to formal verification. It's like a "gotcha!" that didn't land. Sorry.
Please, find some bugs in a project I've touched in the last few years! Looking for things to fix. Please open a github issue from an account linked to your projects next time so I can return the favor :D The bugs are in there, I know they are, but with an LLM and a bit of time to review it's work, it now costs me a few minutes tops to write a test to exclude future cases of the same problem or class of problems. Which is a level of verification beyond what's been allocated time in previous projects, where the tests never got written or very infrequently.
Repsnapper's a great example of that. We didn't have a standardized testing framework we were using across the dozen or so libraries we'd integrated into the app. The original author Kulitorum sort of copied and pasted bits and pieces of code together to write the app originally, without much concern for licenses or origin tracking, so I initiated a line-by-line audit and license verification for the codebase in order to qualify it for inclusion in Fedora and Debian to make 3D printing easier and more available as there were no printing tools shipping in a distro at the time. Integrating new libraries into that codebase was unpleasant, working with the build system in general was not my favorite. Lots of room to screw it up, but it has to be just right to work. I think having llms and a testing framework would have allowed us to evolve the Repsnapper code a lot more safely, and a lot further than we ever managed.
Well, and I can say that pretty safely now that I'm in the process of doing just that with https://github.com/timschmidt/alumina-firmware and https://github.com/timschmidt/alumina-ui and https://github.com/timschmidt/csgrs
They're all still very young, still some things stubbed out, code is gross pending revision and cleanup, but it's basically Repsnapper 3.0 in Rust but this version includes CAD and a motion control firmware and fits in < 4mb. Among them I already have hundreds of tests entirely absent from Repsnapper. Couldn't have written csgrs without them. Probably a lot of redundant tests at this point, as things have changed rapidly. I'm only about 6mo of effort in.
...then a bit flips because of a stray high energy particle or someone trips over the metaphorical power cord and it all crashes anyway.
So it’s really not that far fetched.
Long story: yes, but it'd take centuries to verify all possible inputs, at least for any non-trivial programs.
The hard bit is knowing which functions to write, and what "valid" means for inputs and outputs. Sometimes you'll get a specification that tells you this, but the moment you try to implement it you'll find out that whoever was writing that spec didn't really think it through to its conclusion. There will be a host of edge cases that probably don't matter, and will probably never be hit in the real world anyway, but someone needs to make that call and decide what to do when (not if) they get hit anyway.
[0] https://en.wikipedia.org/wiki/Halting_problem
https://pron.github.io/posts/correctness-and-complexity
If a program is built with strong software architecture, then a lot of it will fit that definition. As an analogy, electricity in your home is delivered by electrical outlets that are standardized -- you can have high confidence that when you buy a new electrical appliance, it can plug into those outlets and work. But someone had to design that standard and apply it universally to the outlets and the appliances. Software architecture within a program is about creating those standards on how things work and applying them universally. If you do this well, then yes, you can have a lot of code that is testable and verifiable.
But you'll always have side-effects. Programs do things -- they create files, they open network connections, they communicate with other programs, they display things on the screen. Some of those side-effects create "state" -- once a file is created, it's still present. These things are much harder to test because they're not just a function with an input and an output -- their behavior changes between the first run and the second run.
Outside of functional code, there's a lot out there which requires mutable state. This is much harder to test which is why user interface testing on native apps is always more painful and most people still run manual QA or use an entirely different testing approach.
Can a function be "verified", this can mean "tested", "reviewed", "proved to be correct". What does correct even mean?
Functions in code are often more complex than just having input and output, unlike mathematical functions. Very often, they have side effects, like sending packets on network or modifying things in their environment. This makes it difficult to understand what they do in isolation.
Any non-trivial piece of software is almost impossible to fully understand or test. These things work empirically and require constant maintenance and tweaking.
Even if you can formally verify individual methods, what you're actually looking for is if we can verify systems. Because systems, even ones made of of pieces that are individually understood, have interactions and emergent behaviors which are not expected.
So what good are these tools? Do they have any value whatsoever?
Objectively, it would seem the answer is no.
Just another old-man-shouting-at-cloud blog post. you company culture sucks and the juniors need to be managed better. Don't blame the tools.
It seems to me that the limitations of this particular tool make it suitable only in cases where it doesn't matter if the result is wrong and dangerous as long as it's convincing. This seems to be exclusively various forms of forgery and fraud, e.g. spam, phishing, cheating on homework, falsifying research data, lying about current events, etc.
How do you fix that, when the process is literally "we throw an illegible blob at it and data comes out"? This is not even GIGO, this is "anything in, synthetic garbage out"
I mean, this is much less common than people make it out to be. Assuming that the context is there it's doable to run a bunch of calls and take the majority vote. It's not trivial but this is definitely doable.
If he problem is the system has no concept of correctness or world model.
You gotta watch for that for sure but no that's not a issue we worry about anymore, at least not for how we're using it for here. The text that's being extracted from is not a "BLOB". It's plain text at that point and of a certain, expected kind so that makes it easier. In general, the more isolated and specific the use case, the bigger the chances of the whole thing working end to end. Open ended chat is just a disaster. Operating on a narrow set of expectations. Much more successful.
I’m a mostly self taught hobbyist programmer, so take this with a grain of salt, but It’s also been great for giving me a small snippet of code to use as a starting point for my projects. I wouldn’t just check whatever it generates directly into version control without testing it and figuring out how it works first. It’s not a replacement for my coding skills, but an augmentation of them.
I think that as software/data people, we tend to underestimate the number of business processes that are repetitive but require natural language parsing to be done. Examples would include supply chain (basically run on excels and email). Traditionally, these were basically impossible to automate because reading free text emails and updating some system based on that was incredibly hard. LLMs make this much, much easier. This is a big opportunity for lots of companies in normal industries (there's lots of it in tech too).
More generally, LLMs are pretty good at document summarisation and question answering, so with some guardrails (proper context, maybe multiple LLM calls involved) this can save people a bunch of time.
Finally, they can be helpful for broad search queries, but this is much much trickier as you'd need to build decent context offline and use that, which (to put it mildly) is a non-trivial problem.
In the tech world, they are really helpful in writing one to throw away. If you have a few ideas, you can now spec them out and get sortof working code from an LLM which lowers the bar to getting feedback and seeing if the idea works. You really do have to throw it away though, which is now much, much cheaper with LLM technology.
I do think that if we could figure out context management better (which is basically decent internal search for a company) then there's a bunch of useful stuff that could be built, but context management is a really, really hard problem so that's not gonna happen any time soon.
What about 20 minuets ago when I threw a 20-line Typescript error in and it explained it in English to me? What definition of "objective" would that fall under?
Or get this, I'm building off of an existing state machine library and asked it to find any potential performance issues and guess what? It actually did. What universe do you live in where that doesn't have objective value?
Am I going to need to just start sharing my Claude chat history to prove to people who live under a rock that a super-advanced pattern matcher that can compose results can be useful???
Go ahead, ask it to write some regex and then tell me how "objectively" useless it is?
I think we'll all need at least 3 of your anecdotes before we change our minds and can blissfully ignore the slow-motion train wreck that we all see heading our way. Sometime later in your life when you're in the hospital hooked up to a machine the firmware of which was vibe-coded and the FDA oversight was ChatGPT-checked, you may have misgivings but try not to be alarmed, that's just the naysayers getting to you.
This sentence is proof you guys are some of the most absurd people on this planet.
I could have written it myself in a few hours, with the Python standard docs open on one monitor and coding and debugging on the other etc, but my project was "organize my photos" not "write a photo organizing app". However, often I do side projects to improve my skills, and using an AI is antithetical to that goal.
I reached for claude code to just vibe a basic android ux to drive some rest apis for an art project as the existing web UI would be a PITA to use under the conditions I had. Worked well enough and I could spend my time finishing other parts of the project. It would not have been worth the time to write the app myself and I would have just suffered with the mobile web UI instead. Would I have distributed that Android app? God no, but it did certainly solve the problem I had in that moment.
Outside of work though it's been great to have LLMs to dive into stuff I don't work with, which would take me months of learning to start from scratch. Mostly programming microcontrollers for toy projects, or helping some artists I know to bring their vision to life.
It's absurdly fun to get kickstarted into a new domain without having to learn the nitty-gritty first but I eventually need to learn it, it just lowers the timeframe to when the project becomes fun to work with (aka: it barely works but does something that can be expanded upon).
But we're in the mega hype phase still (1998/1999) and haven't quite crested over to the reality phase.
If you want to be well-paid, you need to be able to distinguish yourself in some economically-useful manner from other people. That was true before AI and AI isn't going to make it go away. It may even in some sense sharpen it.
In another few years there's going to be large numbers of people who can be plopped down in front of a code base and just start firing prompts at an AI. If you're just another one of the crowd, you're going to get mediocre career results, potentially including not having a career at all.
However, here in 2025 I'm not sure what that "standing out in the crowd" will be. It could well be "exceptional skill in prompting". It could be that deeper understanding of what the code is really doing. It could be the ability to debug deeply yourself with an old-school debugger when something goes wrong and the AI just can't work. It could be non-coding skills entirely. In reality it'll be more than just one thing anyhow and the results will vary. I don't know what to tell you juniors except to keep your eyes peeled for whatever this will be, and when you think you have an idea, don't let the cognitively-lazy appeal of just letting the AI do everything stop you from pursuing it. I don't know specifically what this will be, but you don't have to be right the first time, you have time to get several licks at this.
But I do know that we aren't going to need very many people who are only capable of firing prompts at an AI and blindly saying "yes" to whatever it says, not because of the level of utility that may or may not have, but because that's not going to distinguish you at all.
If all you are is a proxy to AI, I don't need you. I've got an AI of my own, and I've got lower latency and higher bandwidth to it.
Correspondingly, if you detect that you are falling into the pattern of being on the junior programmer end of what this article is complaining about, where you interact with your coworkers as nothing but an AI proxy, you need to course correct and you need to course correct now. Unfortunately, again, I don't have a recipe for that correction. Ask me in 2030.
"Just a proxy to an AI" may lead to great things for the AI but it isn't going to lead you anywhere good!
Having AI write code for me (other than maybe simple boilerplate stuff) goes entirely against why I write code in the first place which is the joy of problem solving, building things, and learning.
Edit: Typo
But, much of what I spend my time on are already solved problems (building retro video game clones) so AI has a LOT of high-quality content to draw upon. I'm not trying to create new, original products.
But our discipline has been through similar disruptions in the past. I think give it a few years then maybe we’ll settle on something sane again.
I do think the shift is permanent though. Either you adapt to use these LLMs well or you will struggle to be competitive (in general)
That certainly isn't true if what this article suggests is true.
Get something stood up quickly to react to.
It's not complete, it's not correct, it's not maintainable. But it's literal minutes to go from a blank page to seeing something clickable-ish.
We do that for a few rounds, set a direction and then throw it in the trash and start building.
In that sense, AI can be incredibly powerful, useful and has saved tons of time developing the wrong thing.
I can't see the future, but it's definitely not generating useful applications out of whole cloth at this point in time.
From there it's the important part: discussing, documenting, and making sure you're on the same page about what to actually build. Ideally, get input from your actual customers on the mockup (or multiple mockups) so you know what resonates and what doesn't.
They’re insanely useful. I don’t get why people pretend otherwise, just because they aren't fulfilling the prophesies of blowhards and salesmen
Unfortunately PMs tend to forget the throw-it-in-the-trash part, so the prototype still ends up in prod.
But good for you, if you found a way to make it work.
> Objectively, it would seem the answer is no. But at least they make a lot of money, right?
Wait, what? Does the author know what the word "objectively" means?
I'd kill for someone to tell me how feeding a pdf into Claude and asking it to provide a print-friendly version for a templating language has "objectively" no value?
What about yesterday when I asked Claude to look write some reflection-heavy code for me to traverse a bunch of classes and register them in DI?
Or the hundreds (maybe thousands) of times I've thrown a TS error and it explained it in English to me?
I'm so over devs thinking they can categorically tell everyone else what is and isn't helpful in a field as big as this.
Also, and this really, really needs repeated: When you say "AI" and don't specify exactly what you mean you sound like a moron. "AI", that insanely general phrase, happens to cover a wide, wide array of different things you personally use day to day. Anytime you do speech-to-text you're relying on "AI".
This is not what companies want. Companies want "value" that customers will pay for as quickly and cheaply as possible. As entities they don't care about craftsmanship or anything like that. Just deliver the value quickly and cheaply. Its this fundamental mismatch between what engineers want to do (build elegant, well functioning tools) and what businesses want to do (the bare minimum to get someone to give them as much money as possible) that is driving this sort of pulling-our-hair-out sentiment on the engineering side.
AI isn't good enough yet to generate the same quality of software as human engineers. But since AI is cheaper we'll gladly lower the quality bar so long as the user is still willing to put up with it. Soon all our digital products will be cheap AI slop that's barely fit for purpose, it's a future I dread.
The software I have vibecoded for myself totally obliterates anything available on the market. Imagine a program that operates without any lag or hicupps. Opens and runs instantly. A program that can run without an internet connection, without making an account, without somehow being 12GB in size, without totally unintuitive UI, without having to pay $20/mo for static capabilities, without persistent bugs that are ignored for years, without any ability to customize anything.
I know you are incredulous reading this is, but hear me out
Bespoke narrow scope custom software is incredibly powerful, and well within the wheelhouse of LLMs. Modern software is written to be the 110-tool swiss army knife feature pack to capture as large of an audience as possible. But if I am just using 3 of those tools, an LLM can write a piece of software that is better for me in every single way. And that's exactly what my experience has been so far, and exactly the direction I see software moving in the future.
The problem space of average people problems that can be addressed with <5K LOC is massive. The only real barrier is having to go through an IDE, but that will almost certainly be solved in the near future, it already sort of is with Canvas features.
[1]https://aistudio.google.com/prompts/new_chat
Any startup that can come to the table saying “All human engineers; SOC 2 Type 2 certified; dedicated Q/A department” will inherit the earth.
Maybe spaghetti code delivers value as quickly as possible in the short term, but there is a risk that it will catch up in the long term - hard to add features, slow iterations - ultimately losing customers, revenue and growth.
It’s not what I want… but at the same time, how many of our jobs do what we want? I could easily end up being the garbage man. I’m doing what I’m paid to do and I’m paid well to do it.
157 more comments available on Hacker News