Different outlets tilt different directions. On HN and some other tech websites it's common to find declarations that LLMs are useless from people who tried the free models on ChatGPT (which isn't the coding model) and jumped to conclusions after the first few issues. On LinkedIn it's common to find influencers who used ChatGPT for a couple things at work and are ready to proclaim it's going to handle everything in the future (including writing the text of their LinkedIn post)
The most useful, accurate, and honest LLM information I've gathered comes from spaces where neither extreme prevails. You have to find people who have put in the time and are realistic about what can and cannot be accomplished. That's when you start learning the techniques for using these tools for maximum effect and where to apply them.
Do you have any pointers to good (public) spaces like this? Your take sounds reasonable, and so I'm curious to see that middle-ground expression and discussion.
> That's when you start *learning* the techniques for using these tools for maximum effect and where to apply them.
"They're perfectly justified: the majority of hot new whatevers do turn out to be a waste of time, and eventually go away. By delaying learning VRML, I avoided having to learn it at all."
The quality of code generated with LLM decreases over time.
Let us talk again after, say, five years.
This requires the level of professionalism that 97.56% of SWEs do not have
> * see the hype;
> * try to replicate the hype;
> * it fails miserably;
> * they throw everything away;
I'm sure doing two years of vibecoding is is a considerably more sincere attempt than "trying to replicate the hype and failing at it".
>There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
Just under one year ago.
> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
Yes.
I use LLMs for coding in the exact opposite way as described in the video. The video says that most people start big, then the LLM fails, then they reduce the scope more and more until they're actually doing most of the work while thinking it's all the machine's work.
I use AI in two ways. With Python I ask it to write micro functions and I do all of the general architecture. This saves a lot of time, but I could do without AI if needed be.
But recently I also started making small C utilities that each do exactly one thing and for those, the LLMs write most if not all of the code. I start very small with a tiny proof of concept and iterate over it, adding functionalities here and there until I'm satisfied. I still inspect the code and suggest refactorizations, or putting things into independent, reusable modules for static linking, etc.
But I'm not a C coder and I couldn't make any of these apps without AI.
Since the beginning of the year, I made four of them. The code is probably subpar but they all work great! and never crash, and I use them every day.
Instead my productivity would be optimised in service of my employer, while I still had to work on other things, the more important work you cite. It's not like I get to finish work early and have more leisure time.
And that's not to mention, as discussed in the video, what happens if the code turns out to be buggy later. The AI gets the credit, I get the blame.
You should be aiming to use AI in a way that the work it does gives you more time to work on these things.
I can see how people could end up in an environment where management expects AI use is expected to simply increase the speed of exactly what you do right now. That's when people expect the automobile to behave like a faster horse. I do not envy people placed in that position. I don't think that is how AI should be used though.
I have been working on test projects using AI. These are projects where there is essentially no penalty for failure, and I can explore the bounds of what they offer. They are no panacea, people will be writing code for a long while yet, but the bounds of their capability are certainly growing. Working on ideas with them I have been able to think more deeply about what the code was doing and what it was should do. Quite often a lot of the deep thinking in programming is gaining a greater understanding of what the problem really is. You can gain a benefit from using AI to ask for a quick solution simply to get a better understanding of why a naive implementation will not work. You don't need to use any of that code at all, but it can easily show you why something is not as simple as it seems at first glance.
I might post a show HN in a bit of a test project I started over the Christmas break. It's a good example of what I mean. I did it in Claude Artifacts instead of using Claude Code just to see how well I can develop something non-trivial in this manner. There have been certainly been periods of frustration trying to get Claude to understand particular points, but some of those areas of confusion came from my presumptions of what the problem was and how it differed to what the problem actually was. That is exactly the insight that you refer to as the tasty bits.
I think there is some adaptation needed to how you feel about the process of working on a solution. When you are stuck on a problem and are trying things that should make it work, the work can absorb you in the process. AI can diminish this, but I think some of that is precisely because it is giving you more time to think about the hard stuff, and that hard stuff is, well, hard.
Now that is some stark truth right there.
In a sense, AI coding is like using a 3D printer. The machine outputs the final object but you absolutely decides how it will look like, how it will work.
This comment took 15s, typing can be very fast.
They literally are.
Was it 3 paragraphs to change a line of code?
I agree the tools are amazing, if you sit back and think about it it’s insane that you can generate code from conversation.
But so far I haven’t found the tools to be amazingly productive for me for small things like that. It’s usually faster for me to just write the thing directly than to have a conversation, and maybe iterate once or twice. Something that takes 5 minutes just turns into 15 minutes and I still need to be in the loop. If I still need to read the code anyway it’s not effective use of my time.
Now what I have found incredibly productive is LLM assisted code completions in read-eval-print loop. That and helping to generate inline documentation.
You need to pick and choose when to use them, it largely depends on the task.
I use AI a lot now for programming and spend more time code reviewing, sometimes though, I use my hands.
My nimber one rule is, don't try to do too much in one prompt.
You run CI on human-generated PRs, but not AI-generated PRs? Why would there be a difference in policy there?
After that it’s the “ask” capability when I need to get oriented in unfamiliar and/or poorly documented code. I can often use the autocomplete pretty effectively once I understand the patterns and naming conventions.
Similarly, agents are good for a first pass triage and plan when troubleshooting tricky bugs.
Still haven’t had a good candidate for going full vibe code. Maybe that’s because I don’t do a lot of greenfield coding outside of work, which seems to be where it shines.
Just my experience. It’s new set of tools in the toolbox, but not always the right one for a given task.
I know what I want before I type it. Having to parse the auto-completion disrupts the thought process of what I _wanted_ to write.
I think it might be even worse for greenfield work, as that's when you're establishing a lot of patterns. You don't want AI to have any role in that
But that's why you tell the AI to refactor.
I've started a greenfield project and went 100% AI for learning purposes (of course it's more like 95%) and my takeaway is:
- it's fully possible
-- but the AI is of no great help with figuring out what the architecture or interfaces should be
- Keep a refactoring backlog
-- Spend 30%-40% of your time on refactoring, aligning patterns, improving architecture
-- depending on your codebase, this can happen in parallel
-- sometimes you need to get your hands dirty and do the cleanup yourself
-- ... but usually, you only need to establish the pattern once
- once the patterns are established, it becomes easy to talk to the AI in the context of your codebase
-- you can reference patterns by name or location
This has been very effective in my experience. “See class foo for example implementation “
I also like the comments on how developers should be frequently reading the entire code and not just the diffs. But again there is probably pressure to speed up and then that practice gets sacrificed.
From what I've seen, companies using AI well are shipping better code because of all the artifacts (supporting context like Architectural Design Records, project-specific skills and agents, etc.) and tests needed to support that. I understand that many are not using AI well.
this is true with or without AI
I agree with this take... for now. I wouldn't be surprised if the AI agents improved exponentially (in the next few years) to the point where his statement is no longer true.
I truly don’t know how this is going to play out. Will the software industry just be a total mess until agents can actually replace developers? Or will companies come to their senses and learn that they still need to hire humans - just humans that know how to use agents to augment their work?
If AI can't replace developers, companies can't replace developers with it. They can try — and then they'll be met with the reality. Good or bad
Bingo.
And it’s causing the careers of a majority of juniors to experience fatal delays. Juniors need to leap into their careers and build up a good head of steam by demonstrating acquired experience, or they will wander off into other industries and fail to acquire said experience.
And when others who haven’t even gone through training yet see how juniors have an abysmally hard time finding a job, this will discourage them from even considering the industry before they ever begin to learn how to code.
But when no-one is hiring such that even students reconsider their career choice, this “failure to launch” will cause a massive developer shortage in the next 5-15 years, to the point where I believe entire governments will have this as a policy pain point.
After all, when companies are loathe to actually conduct any kind of on-the-job training, and demand 2-5 years of experience in an whole IT department’s worth of skills for “entry level” jobs, an entire generation of potential applicants with a fraction of that (or none at all) will cause the industry to have figurative kittens.
I mean, it will be the industry’s own footgun that has hurt them so badly. I would posit it may even become a leggun. The schadenfreude will be copious and well-deserved. But it’s going to produce massive amounts of economic pain.
Junior devs at least have the option of building a portfolio of usefully software on their own machine at home, while eating ramens.
They can build websites for mom'n'pop stores. They can participate into open source projects. Etc, etc...
I dread the people who won't get jobs into other fields because managers have been told by corporate that "we don't need people, chatgpt can do everything".
For many, even cutting their budget isn’t enough to pursue what you’re describing. Modern careers in software are very hard to reach for people who can’t afford to wait for a real paycheck, and it drives away a massive group of potential talent.
Bold of you to assume today’s young adults can live without a steady paycheque that doesn’t suck up 40-80hrs of their time a week. I mean, how else will that roof end up over their heads?
And most parents have been brainwashed to believe that any child not living on their own once they become adults are failures, and still need to be kicked out of the house such that they are forced to learn self-sufficiency.
AFAICT, most parents of adult offspring have zero clue about how bad things actually are out there, with most still telling their children to go from business to business with printed-off Résumés. Outside of blue-collar jobs, I haven’t seen this work for a good twenty years, now.
My point is that a luxury of the software engineering craft is that you can practice "at pro level" very cheaply. Even as a teenager, learning and using vscode/python/react/etc... on your own is a possibility.
Learning Salesforce and SAP and the internal support tool of BigCo is not.
That being said, I completely agree that we're going to put a generation of "wannabee white collar" in a dire situation. Cynically, this might be an overdue correction from the years of "college degree for everyone", and maybe (just maybe) some people will actually thrive in the "hard-to-llm-ize" profession if they can retrain.
(If the market laws apply, someone will build "turn advertisement-copy writers into electricians", and it would not necessarily be for the worst ? I know, easy to tell for me, who got the opposite deal by being a software engineer on demand at the right time at the beginning of my career.)
The 80/20 rule is a painful lesson to internalize but it’s damn near a universal constant now. That last exponential improvement that takes LLMs over the finish line will take a lot longer than we think.
It's an aftermarket system, but can be installed in most newish cars with a built in lane guidance system. Even a Corolla. And it's really want we want. It's not self-driving, it'll just take you down the freeway and you don't have to do anything except wait for your GPS to tell you to exit (and then you have to exit). Freeway-grade gurves in the road? Fine. Stop and go traffic? Handled. It's better than Tesla's FSD in two specific ways. One is that because it's not self-driving, it's way easier to trust the system because it's not going to change lanes or anything surprising on you. It's not going to do something fancy, just brake or accelerate or follow the lane or car in front of you left or right. I highly recommend it to anyone who does any amount of freeway driving. If not for the coolness of it then simply the safety aspect. Now, I'm sure everyone here is a better driver than most (though that has a problem, mathematically), but this thing is better than a tired/angry/drunk version of someone else driving.
But as you point out, most people are still driving their own cars.
Which, I think is where we're going to see the software development industry going. There's gonna be the AI maximalists, who, like Waymo and FSD, will have AI basically do everything. And then there's the pragmatists, for whom AI doesn't do everything, just enough to be useful.
Then there's everyone else, still writing their own code. Thing is, an app on your computer isn't a car. It's $20/month if not free if you're a total cheapskate, to get codex or claude or another assistant, vs many thousands of dollars for a self-driving or partially self-driving car. The other difference is in time. The value of a partially self-driving car (FSD or Comma) is in the mental fatigue of driving, and in improved safety, but a 7 hour road trip is still going to take 7 hours even if you're not driving. The only time a self-driving car helps is if you're going cross-city in a Waymo, and you're in the back seat working on your laptop. AI assisted coding though is different. If I take on projects I wouldn't do before with AI, that's a win for me. If I'm able to write software faster and with fewer bugs with AI, that's also a win for me, but also a win for my employer. If, however, it goes the other way and I write more bugs, then that's a loss for me and my employer.
And what do they run on? Information. The production of which is throttled by the technology itself, in part because the salespeople claim it can (and should) "replace" workers and thinkers, in part because many people have really low standards for entertainment and accept so called slop instead of cheap tropes manually stitched together.
So it would seem unlikely that they'll get the required information fed into them that would be needed for them to outpace the public internet och and widely pirated books and so on.
I am not worried about losing my programming role to AI.
I am worried about hiring employees and contractors. I haven’t had to hire anyone i office since, but I have specially avoided Upwork and new contractors. It’s too hard to tell if anyone knows anything anymore.
Everyone has the right or right enough answers for an interview or test.
The bar to detect bullshit has been moved deeper into the non-detectable range. It’s like everyone has open-book testing for interviews.
Even if I can sus out who is full of shit in a video or phone interview… the number of people I need to sort through is too large to be effective.
For Upwork specifically, this was an issue for years already. With people buying US accounts and lying about their location or subcontracting to cheaper foreign labor.
So, is vibe coding something I want to hire? Absolutely not. But, I don’t see being able to avoid it or at least not suffering from someone cutting corners.
But that also doesn't mean they're useless. Giving comparatively tedious background tasks to the agents that I check in on once or twice an hour does feel genuinely useful to me today.
There's a balance to be found that's probably going to shift slowly over time.
Just for fun, once I had played a bit with it like that, I just told it to finish the application with some vague Jira-epic level instructions on what I wanted in it and then fed it the errors it got.
It eventually managed to get something working but... Let's just say it's a good thing this was a toy project I did specifically to try out Claude, and not something anyone is going to use, much less maintain!
Would you finish the application with "some vague Jira-epic level instructions"? Or, even if you don't formally make tickets in Jira for them, do you go from vague Jira-epic-sized notions to ticket-sized items? If I had a mind-control helmet that forced you to just write code and not let you break down that jira-epic in your thoughts, do you think the code would be any good? I don't think mine would be.
So then, why does it seem reasonable that Claude would be any good, given such a mental straight jacket? Use planning mode, the keyword "ultrathink" and the phrase "do not write code", and have it break down the vage Jira epic into ticket-sized items, and then have it break it into sub tickets that are byte-sized tasks, and then have it get to work.
It did manage to get the application working though, with only a couple of "this thing broke, plz fix" style prompts, and it did better than I had thought it would to fulfill my intention, give how vague I was.
My point was that if you're going to build an actual product, you should probably not use Claude in that way. Break down the epics to smaller more manageable chunks however, and Claude can do an amazing job! I'll definitely keep experimenting with it this way, it's way better than full-manual coding, or at least that's my initial impression of about a week of experimentation!
1. I find AI written code verbose and inelegant. It makes it difficult to troubleshoot. I take pride in my own code and share it confidently with my doctoral students and coauthors. I can't share AI written/assisted code with the same confidence let alone pride.
2. Often AI takes shortcuts and writes terrible code. This is especially true for Bayesian models. My first check with any Bayesian model is to recover parameters using a simulated dataset. If the code fails to do that, there is no point in going forward. I used Opus 4.5, Gemini 3.0, and GPT 5.2 recently to write rather simple code for random parameters dynamic panel model. There are already papers that have done it. All three failed numerous times. I got it to work after a lot of handholding.
3. AI helps tremendously while creating web apps that make my analysis more actionable. A lot of reviewers now want to see something in action, so using Streamlit or Shiny is the way to go.
Writing by hand (or whiteboarding) forces you to load the entire context into your working memory. AI allows you to be lazy with your working memory. The code gets written faster, but the mental model of the system in my head is significantly weaker.
I agree that writing by hand sets up that mental model, and because it's written by you, it's easier to branch out from there.
There's a time and place for refactoring, but just fixing an isolated bug isn't it. But I've seen that often AI can't help itself from making changes you didn't ask for.
Before AI, "now" was seen as the wrong place for a refactor because of the time and effort involved, but if the hacky patch of a fix is roughly the same amount of wall clock time as a 500 line proper fix that makes the problem go away forever, what's the argument that the 10 line hack is actually better?
That only makes sense if the coworker isn't validating the fix and no one is reviewing the code. 500 lines of slop is going to take much longer if you have a human in the loop.
1. One-shot app development using Lovable with English requirements
2. Spec driven development tools like SpecKit, Kiro that promise English as being sufficient for LLM generated code
3. Using agent swarms with Claude Code and thinking you are making progress and you never have to look at the generated code, when the overall coherence or elegance of the codebase is lost.
Loved the analogies in this video:
“It looks like an airplane. It flies like an airplane. But when you inspect the code in its full context, it’s a paper plane.”
and
“It looks like an airplane, walks like an airplane and talks like an airplane. It’s probably an airplane. But it’s not an airplane, it’s a psychedelic airplane …filled with hallucinations”
But, still the tools are incredibly helpful when you have the right guardrails and take the time to ensure (somehow) the output matches your taste and code quality expectations.
I'm not saying AI has no place, but letting it take the lead in any way is just building your app on sand. Fine if you're building a sandcastle, bad if you're building a bridge. It's not "ohh well I just don't like the way sandcastles look"
There are some managers and developers out there who would charge and ship whatever code AI provides no matter what multidimensional horror there is inside. As long as these people point to test and say "look, the checkbox is green" they will sign on it without taking a single look at the codebase.
So what if tests don't actually cover important parts of the functionality. Checkbox is green and AI review agent said it's fine - so it must be fine.
I posted this comment using only curl by the way. Don't bother replying because I only engage in bidirectional conversation via SSH tunnel and netcat. I doubt that you could figure it out.
The tooling is going to change how we do development no doubt, but people are going to find their comfortable spot, and be productive.
So far, LLM generated code hasn't lived up to my standards. I'll use it for things that aren't critical as-is, but mostly I use it as a reference, an example, a starting point. Essentially, where in the past I'd find a code base that does things and I'd try to do something similar, now I let the LLM generate the code base. There are to questions it helps me answer:
1) What are the possible ways of solving problems?
2) What are the pros and cons of each approach?
That said, there are people successfully deploying apps that are entirely vibe coded. How many fail or succeed, that I don't know. But there are enough, and you can't deny the evidence.
You can't keep doing things the same way, that's now how technology as an industry works, the whole point is to come up with newer and better things. If you're a user of technology, then you can think like that and keep using old tech until the natural balance of things forces you.
I fully expect LLMs to be obsolete in a few decades, and I'm now wondering if people then will say how LLMs have been serving them fine for a few decades.
"just fine" isn't good enough in tech, "better" is always the goal.
This is some big stretch in reasoning. Four years ago we were not harming ourselves by not having AI and writing code ourselves.
At most you're hurting your ability to compete with "vibe coders" whose metric so far has been lines of code and $ spend per day running agents, not successful products.
Have you considered how relying on AI affects your own programming skills?
> Have you considered how relying on AI affects your own programming skills?
Yes, about as much as it did before but now I have more time to think more deeply about solutions instead of cosmetic things, syntactic nonsense,tedious b.s.,etc... It's like asking how using an IDE with auto-complete affects your programming skills when you could be writing in vim or notepad. Doing tedious things, knowing how to beg right on the correct forum, or hunting down the best library, the best doc,etc.. these are not programming skills. Like I said in my original comment, I'm not using it to write the code for me, I'm using it to do things that have nothing to do with solving the problem at hand.
With AI's assistance, you can become a better problem solver. heck, you might even be good at spotting mistakes other people make, just by force of habit learned from correcting mistakes AI makes. It's just a utility, take all the benefits from it and discard things you don't like about it. Nothing forces to use the code it generates. think of it as a junior programmer that's doing PRs for menial tasks for you, and that's the best case scenario. It's just a really good google search that gives you the results you're looking for instead of jumping through hoops to get something of lesser quality. Many times I've mistrusted the AI and did things the old way, and its solution contained more nuance, details and considerations I failed to glean with my initial attempts.
Before AI, the story of people copy pasting things from stack overflow, including bugs, and including good code that gets buggy in certain situations was a major trend. AI does that, except better both in terms of result quality, and in helping you avoid pitfalls. But imho, you still shouldn't trust it, you still have to vet everything it does and stop using it if that effort takes more time and it would have doing things manually.
Who is going to be responsible for the code? AI is definitely not responsible.
I am vibe coding, if I needed x, I lay that out task with any degree of specificity, and ask for the whole result. Maybe it’s good, I gave the LLM a lot of rope to hang me.
I am using an LLM for assistance if I need something like this file renamed, and all its functions renamed to match, and all the project meta to change, and every comment that mentions the old name to be updated. There is an objectively correct result.
It’s a matter of scope.
By this I mean give it precise instructions and ensure the instructions are always included in the context window. You’re responsible for managing the agents effective working memory, if that analogy makes sense. If you don’t tell it the way you want it to act, it’s effectively a blank slate.
I am not liking this era of infinite abundance.
I mean I am left with two thoughts:
1. programming language skill issue. Some languages are simply much better at composition than others. I find that yes, this happens, but actually on the order of a day, and once the code is "good", it doesn't really change that much in the grand scheme of things?
2. Even for languages where composition is better, this is exactly what happens with human development too?
I think the mistake is assuming you get high quality work with an agent regardless of the driver’s skill level. That doesn’t appear to be the case, but it’s the value prop that is being sold.
The video is spot on for codebases of products that are critical systems: payment, erp etc -> single source of truth.
Simple Crud apps/ Frontends for ecom that abstracted away the critical functionality to backend APIs (ERP, shop system, payment etc) benefit from vibe slop vs no shipping cadence
It's the same junk produced by fast-growing startups. It was always here, now there's more of it.
I'm convinced that people will continue to use it. Therefore, I need to be able to deal with it, maybe even leverage it somehow (there should be coding skills that I possess that people in that realm of fast-growing startups do not bother to learn).
I've been trying Google antigravity. Despite VS code being total dogshit compared to Intellij I'm pretty sure I won't be renewing any more (after 15 years, sorry jetbrains).
Honestly, without judgment, I think this is just a fundamental difference in how people approach their craft. You either want to be capable yourself or you just want the results.
This is almost the only thing I'm against when it comes to LLMs. You have no ability to figure out if it is right, and you will be overly impressed by garbage because you aren't qualified to judge. Has anybody come up with a pithy way to describe Dunning-Kruger for evaluating the output of LLMs, or are people too busy still denying that Dunning and Kruger noticed anything?
When it comes to implementing math, the main problem is that the tiniest difference can make the entire thing wrong, often to the degree of inverting it. I wouldn't be in any way comfortable in shipping something I didn't even understand. The LLM certainly didn't understand it; somebody should.
And some us even remember riding the CPU with mov rcx, 5.
We were just shifting our focus byte by byte from the nits and bolts towards the actual problem we are solving. In other words going less "hard"-ware, more and more "soft"-ware.
AI is just continuing this evolution, adding another abstraction layer in soft dev process.
I think the problem is that people:
* see the hype;
* try to replicate the hype;
* it fails miserably;
* they throw everything away;
I'm on call this week on my job, one of the issues was adding a quick validation (verifying the length of a thing was exactly 15). I could have sat and done that but I just spun an agent, told it where it was, told it how to add the change (we always add feature flags to do that), read the code, prompted it to fix a thing and boom, PR is ready. I wrote 3 paragraphs, didn't have to sit and wait for CI or any of the other bullshit to get it done, focused on more important stuff but still got the fix out.
Don't believe the hype but also don't completely discount the tools, they are incredible help and while they will not boost your productivity by 500%, they're amazing.