if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
They are young and inexperienced today, but won't stay that way for long. Learning new paradigms while your brain is still plastic is an advantage, and none of us can go back in time.
You can absolutely learn new paradigms at any age. This idea that you can only do so as an 18-25 year old is ridiculous.
> They are young and inexperienced today, but won't stay that way for long.
I doubt that. For me this is the real dilemma with a generation of LLM-native developers. Does a worker in a fully automated watch factory become better at the craft of watchmaking with time?
I think the fundamental shift is something like having ancillary awareness of code at all but high capability to architect and drill down into product details. In other words, fresh-faced LLM programmers will come out the gate looking like really good product managers.
Similar to how C++ programmers looked down on web developers for not knowing all about malloc and pointers. Why dirty your mind with details that are abstracted away? Someone needs to know the underlying code at some point, but that may be reserved for the wizards making "core libraries" or something.
But the real advancement will be not being restricted by what used to be impossible. Why not a UI that is generated on the fly on every page load? Or why even have a webform that people have to fill out, just have the website ask users for the info it needs?
> looking like really good product managers.
Exactly and that's a different field with a different skillset than developer/programmer.
And that's the purpose of technology in the first place tbh, to make the hard/tedious work easier.
This part tracks. It's honestly rather generic.
> if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
This, I'm not sure applies either. TBH the biggest risk I'm seeing already right now is how quickly we're starting to see juniors trying to enter the job market who don't have the faintest idea how actually code. Let alone build software (but let's be honest, that's usually been the case). What decisions to make when writing something are based on factors outside just implementing the functionality: how maintainable is this? how extensible?
Giving a junior a sycophant that's reasonably competent at spitting out something functional (not necessarily functional in the sense you need it to be but apparently working) is a recipe for disaster IMO.
There will absolutely be some who "get it". But, how does that scale?
More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".
Play with it — that’s the only way anyone masters anything.
Separate yourself from the results, be prepared to waste time, but try and have some fun and keep your eyes open.
Playing with it is a great way to do that.
If there is something you are certain it won't be able to do, it's worth giving it a go anyway. Most of the time you will be right - and will still learn something new in confirming that and watching the way in which it fails. Very occasionally you'll be wrong and you will discover a new capability that surprises you.
To me, someone who actually love programming, it makes vibe coding look like hell.
> The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis
Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not alone here. Helping a student through a research thesis doesn't sound so bad, because as a human, helping people feels good. But here, there is no student, no human feelings, and you are not even helping the AI become better in the long term.
Given how “vibe coding” is all about explaining clearly the requirements and defining context, it’s for programmers who should have chosen middle management as a career.
To actual programmers that enjoy the craft, using an LLM means ruining the beautiful art of abstraction and mental visualisation of a complex piece of logic, by putting it through the very lossy process of explaining it into words. It would be a bit like a composer or a painter having to use words instead of leveraging their well-honed instinct.
You can always leave the core logic for your to work on and have the AI handle all the bits that you don't like to do. This is what we do for modelling for example, AI helps with the interface and data backends, the core modelling logic is hand-crafted.
this is my favourite kind of work. i can switch my brain off and just do something repetitive for a bit.
boredom is necessary for good ideas.
I feel good because real humans are using what I've built and they like it.
if you see programming as a necessary but ultimately annoying means to an end, that's fine, you do you, but there are many other folks who don't look at it that way, and they're no more or less right or wrong than you are
For me, that's:
- working in legacy parts of the codebase
- anything that requires boilerplate that can't be code genned
- actually writing the code of unit tests (the fun part is making code testable, and coming up with what to test)
- fixing lint issues that can't be auto fixed yet
- removing old feature toggles
- building a temporary test harness
The list goes on. That's not hell. That's getting someone else on the team to do all the stuff you don't enjoy, without ruining someones day.
This is why most of us get paid what we do, I’m sure you realize that. There is immense value in having engineers on a team/at a company that can do this.
> anything that requires boilerplate that can't be code genned
It is important to understand the boilerplate. It is also important to understand what is boilerplate and what isn’t. After these things are grasped, usually it’s a copypasta.
> actually writing the code of unit tests (the fun part is making code testable, and coming up with what to test)
If you don’t know how to write unit tests you don’t know how to write testable code. If you do know how to write unit tests you understand the value in maintaining them when you make code changes. Passing that off to a statistical next token predictor renders the tests largely useless
> fixing lint issues that can't be auto fixed yet
You should be thankful you didn’t write code in the 80s if this is a real stance. More thankful still that you rarely need to interact with code sans a linter or autocomplete. There are lots of technologies out there where this isn’t possible. Off the top of my head would be yocto recipes.
> removing old feature toggles
I’m not clear what this even means? You mean, doing your job?
> building a temporary test harness
Generate one, I don’t care. You’ll never know if it’s any good unless you go over the whole thing line by line. At which point, you didn’t save time and didn’t “level up” any skills
One nice thing about programming is that the computer is a dumb funnel for your human brain to encoded actions. If the program doesn't work, you did something wrong, missed a semicolon etc. This still applies to LLMs. If the LLM gave you shit output, it is your fault. You gave it shit input. If the model you used was the wrong one, you can still get good results, you just have to put in more work or break the problem down more first. But it's still programming. If you treat using LLMs that way, and start to apply your normal programming approaches to your prompts, you can find a workflow that satisfies your demands.
But even if you only use LLMs to rubber duck a problem, by literally typing "The program is doing X,Y,Z but it's only supposed to do Z. I already looked at A,B,C and I have a theory that G is causing the issue but I'm not seeing anything wrong there." and just paste that in the chat you might be surprised what it can turn up. And that's a fine use case!
LLMs are broadly useful and there are certainly elements of programming that are the "shit-shoveling" parts for you, from debugging to writing tests to planning or even re-writing Jira tickets, LLMs can help at different levels and in different ways. I think prescriptive calls to "code this way with LLMs" are shortsighted. If you are determined to write each line yourself, go for it. But like refusing to learn IDE shortcuts or use a new tool or language, you are simply cutting yourself off from technological progress for short term comfort.
The best part of programming to me is that it is always changing and growing and you are always learning. Forget the "AI eating the world" nonsense and treat LLMs as just another tool in your toolkit.
You will always be able to write code by hand. But you will not be able to keep up with other engineers who master using AI tools. I am a software engineer, I like building things. And I don't use binary or assembly, or C or any other lower level languages for good reasons. AI is just another higher level abstraction. A tool that allows me to build things a little faster. I use it every day.
Agreed.
My LLM usage has quickly become a more efficient way to solve problems that basically require copy/pasting from some documentation I have to look up where me doing it myself is more error prone.
I was recently doing a fairly complex set of data transformations and understanding what the data means remained essential. AI tends to fail spectacularly at really understanding the nuances of data (that often requires understanding the underlying business logic generating the data).
However it's very useful when I have to do a bunch of window functions, where I can describe the operation but don't want to look up the syntax. Or just writing SQL when I can explain exactly what I need it to do.
Similarly working with Pytorch involves a fair bit of what I consider pseudo-boilerplate where the code itself is quite boring, but contains just enough complexity that it can't be simply automated away. Hand rolling this stuff often leads to small errors/bugs, but LLMs can do a spectacular job of quickly generating this, provided you do know exactly what you're looking to build.
What's interesting is that this has still been a major speed boost, because looking up how to do some tedious thing you just forgot how to do can really break flow.
But you can't change the fundamental operation of an LLM, by its very nature it is not suitable for producing consistently correct results. Getting better at "vibe coding" is an exercise in futility.
In both cases the more experience and mindful experimentation you have the better your results will be.
You sound like you have not spent much time using AI tools.
What's worse is they also tend to be the type of "evangelists" that become wildly defensive or accusatory when you question anything about their work.
But I don’t “vibe code” anything. I understand and review all the code that gets generated. Most of the stuff coming from my agents is either boilerplate or extensively uses libraries and static analysis tools that make it easy to verify.
I kill aggressively any code the agent outputs that doesn’t match my standards unless it’s obvious that I can get it up to par quickly. This is one of the big advantages of the llm. I can do that without navigating inter personal conflict.
But the output is mostly indistinguishable from what I create by hand.
I'm having fun with Claude Code and Vibe Kanban on personal projects, and before that I spent a lot of time with both the Windsurf and Cursor agents. It's making me literally 10x more productive on personal projects, maybe even 50x.
On personal projects:
- no-one but me needs to decide on requirements
- no-one but me needs to make decisions
- no-one but me needs to maintain the code going forward
- much of the time I'm intentionally using languages and frameworks that I am somewhat clueless about, and an LLM providing continuous ideas (even if sometimes entirely silly ones) stops me getting stuck
- I don't mind if there are large chunks of useless or half-working code
On commercial projects:
- every line of code is a massive liability. Every line needs to be reviewed by another engineer, and every developer who joins the project needs to be aware of it, take it into consideration when making changes elsewhere, and potentially debug it if something goes wrong
- senior engineers are almost always hired to work with languages and technologies they are already very familiar with, meaning for many tasks it's often quicker to write out the code by hand (or perhaps with Cursor's auto-complete) than guide an LLM to do it
- much of the time is spent in meetings trying to unearth the real product requirements or providing updates to stakeholders
- much of the time is spent reading old code and working out how to implement things in extremely large and complex systems in a minimally disruptive way
- a lot of time is spent reviewing other people's PRs, and getting infuriated when people (often either very junior or very senior) produce 1000 line PRs consisting of unnecessary changes, excessive boilerplate, half-finished experiments, and things that clearly haven't been tested properly. This was the case long before LLMs, AI just makes it ever more tempting for people to act this way.
- trying to avoid or gently negotiate political games over who is in control of the project, or who gets to makes technical decisions
Previously: make a little bit of progress, realize I'd need a year's worth of weekends to complete it, give up after one day.
With vibe-coding assistance: make 10x+ progress, realize that with a few more weekends I could finish it, keep going.
What's the cost of 32Cph?
(A minor disagreement: it's using a definition of "vibe coding" that applies to any form of ai-assisted programming. I prefer to define vibe coding with its original definition from all the way back in February where it only refers to code that is generated through prompting without any review.)
Coding is the easy part. Knowing what to code, how to work with people, how to interact with the real world and with chaos, with bad data, with poor integrations, and entropy.
I'm all for making AI and coding better and helping people do that and think.
I'm not impressed by anyone who doesn't show me they can think about the problems we face better and faster, and keep doing it without slowing down to a halt or making it someone's else's problem.
Everyone else is just talking themselves up or selling something, neither of which are useful to me.
Or, any of:
- the problem was too big in scope and needed a stepped plan to refer to and execute step by step
- your instructions weren't clear enough
- the context you provided was missing something crucial it couldn't find agentically, or build knowledge of (in which case, document that part of the codebase first)
- your rules/AGENTS.md/CLAUDE.md needs some additions or tweaking
- you may need a more powerful model to plan implementation first
Just throwing away and moving on is often the wrong choice and you'll get better at using these tools slower. If you're still within the "time it would have taken me to do it myself" window, think about what caused it to go off the rails or fail spectacularly and try giving it another go (not following up, throw away current results and chat and try again with the above in mind)
We use feature flags. However, cleaning them up is something rarely done. It typically takes me ~3minutes to clean one up.
To clean up the flag:
1) delete the test where the flag is off
2) delete all the code setting the flag to on
3) anything getting the value of the flag is set to true
4) resolve all "true" expressions, cleaning up if's and now constant parameters.
5) prep a pull request and send it for review
This is all fully supported by the indexing and refactoring tooling in my IDE.
However, when I prompted the LLM with those steps (and examples), it failed. Over and over again. It would delete tests where the value was true, forget to resolve the expressions, and try to run grep/find across a ginormous codebase.
If this was an intern, I would only have to correct them once. I would correct the LLM, and then it would make a different mistake. It wouldn't follow the instructions, and it would use tools I told it to not use.
It took 5-10 minutes to make the change, and then would require me to spend a couple of minutes fixing things. It was at the point of not saving me any time.
I've got a TONNE of low-hanging fruit that I can't give to an intern, but could easily sick a tool as capable as an intern on. This was not that.
I've been using Cursor for the last few months and notice that for tasks like this, it helps to give examples of the code you're looking for, tell it more or less how the feature flags are implemented and also have it spit out a list of files it would modify first.
After iterating on that for a while, I did a bunch manually (90) and then gave the LLM a list of pull requests as examples, and asked _it_ to write the prompt. It still failed.
Finally, I broke the problem up and started to ask it to generate tools to perform each step. It started to make progress - each execution gave me a new checkpoint so it wouldn't make new mistakes.
Then I can rinse and repeat using the tool, fixing the bugs in the tool myself instead of repeating the expensive (in time) cost of using the LLM.
That was my last attempt, but I ran out of time.
For repeating patterns I'll identify 1-3 commit hashes or PRs, reference them in a slash command, and keep the command up to date if/when edge cases occur.
It is always the founder type who is trying to peddle fantasies like this:
Vibe coding turns any individual into the CTO leading a team of 20, 30, 50, 60 interns.
How much does his new hobby cost?
On my $200/month Claude 20x Max subscription I used enough tokens for about $5,200 of compute in the first month. This is obviously not sustainable, but hey, it’s a startup world and VCs are paying for it right now.
Like I'm sure the grad students working for Euler learned a ton generating logarithmic tables by hand, but it proved to be useless in the end. Could having a solid grasp on memory management/access in C be the same?
I think this is why obsolescence can be hard to predict.
Like if in 30 years all code is run and managed by ai bots, then all this debate about "it's important to know how to code!" will seem really silly.
I generally don't get great results from LLM code because most of my work is in C++ (which I'm guessing is underrepresented in the training data?), but when I point it towards some well-worn javascript thing I've had real successes! Most recent example is this little chrome plugin I had it whip up in one shot (https://chromewebstore.google.com/detail/favicon-tab-grouper...) because I couldn't find the exact functionality I needed in other plugins.
Works perfectly for my needs, took less than five minutes to spin up, and I use it all the time. If you're looking to get started with vibecoding stuff, try making plugins that provide niche functionality for your hyper-specific workflows.
iLoveOncall•3h ago
Just yesterday I was reading the comment of a Principal Engineer saying "of course vibe coding carries a huge risk for more junior engineers that don't understand when the LLM does something that looks right but is actually wrong", as if just because they have more experience THEY CAN.
No, you can't either. Not a single soul on this planet can review the thousands of lines of vibe coded bullshit that LLMs spit out.
Here's my guide to Gen AI / LLM Vibecoding for Expert Programmers: don't.
jandrese•3h ago
This does have the caveat that reading code is usually harder than writing it, so the total time savings is far less than what AI companies claim. You only get in real danger when you don't review the code and just YOLO it into production.
shortrounddev2•3h ago
leptons•3h ago
polishdude20•1h ago
iLoveOncall•6m ago
simonw•3h ago
apwell23•3h ago
ivape•3h ago
I know exactly when it’s going sideways. You’d have to know to even know, it’s one of those things. If you don’t know then you don’t know.
Put it another way, you know how some people fail open book tests? How’s that possible? The book is not enough.
exitb•3h ago
jbeninger•3h ago
JavaScript isn't my primary language and date functions are always a pain. But I know enough to review and test the code quickly. It doesn't change a 1-week project into a 4-hour one, but it can change a 20-minute project into a 5-minute one.
ivape•2h ago
I suppose for your actual job (if you happen to be in the IDGAF mode), yeah, why work harder and not smarter? That’s a different story altogether, as many will be mailing it in.
abletonlive•3h ago
ajaioslaja•3h ago
For a dev worth paying for, the crucial details of some code is discussed prior to the PR in a way that the PR review becomes an afterthought. You can follow this process with an LLM but the PR review is still brutal. It doesn’t do what you say and it doesn’t learn (in a deterministic way a good human dev does).
High performing teams do not have many changes nor comments in a PR (on average, obviously).
iLoveOncall•3h ago
You also seem to be missing the point that if vibe coding lets your engineers write 10x the amount of code they previously could in the same working hours, you now have to review 10x that amount.
It's easy to see how there is an instant bottleneck here...
Or maybe you're saying that the same amount of code is written when vibe-coding than when writing by hand, and if that's the case then obviously there's absolutely no reason to vibe-code.
lagrange77•3h ago
EagnaIonat•3h ago
Even if you could the code can't be copyrighted.
simonw•3h ago
If that is true, how come huge companies like Microsoft and Salesforce and Google keep boasting about the increasing percentage of their code that is written by LLMs?
What do you know that they don't?
qzw•1h ago
ebiester•3h ago
Reviewing thousands of lines at a time is always a failure state.
iLoveOncall•3h ago
Vibe coding is letting AI write code so you spend less time writing the same amount of code (ideally not more, in practice definitely more).
If more code is written you have to review more code. Doesn't matter if you break it down in 10 lines PRs or if you review a million lines at once, you still end up having to review all the code generated.
leptons•3h ago
ebiester•2h ago
It also means that sometimes, you say "this is bad code," refine the prompt, and run it again.
Yes, it means that you as a code reviewer is a bottleneck. It means that you are limited to the productivity gain that can exist. We are talking 10-15% productivity gains per person in mature code bases, not some magic replacement.
But if you're worried about reviewing code, maybe we shouldn't allow junior programmers to contribute to codebases either. After all, you might make a mistake in reviewing that.
alfalfasprout•3h ago
ebiester•2h ago
In my world, though, we use the refactoring tools such as feature flags and incremental improvements. We can use stacked pull requests. It requires training and discipline but it's absolutely doable for 99% of tasks.
rychco•3h ago
I don't follow. Why wouldn't you believe that a senior engineer, that has been reviewing code for years, be any better at reviewing code?