A guide to Gen AI / LLM vibecoding for expert programmers (opens in new tab)

But, slamming down commands for it on only easy problems in order to get 90% of a PR done and just finishing it yourself? That can get you 6 PRs in instead of 3, where you did the hard 3 and just looked at the transcripts for another 15, and tossed all but the 3 that looked good. Using Claude like that takes about half an hour out of your day and you get a good benefit, and that is what I am pointing to as a very useful approach.

I personally don't think any amount of MCP servers will make "Claude, find me a novel algorithmic improvement in this space and code it up" work, but hey if that works for you that's great. But reviewing and checking the proofs would likely make it not worth it for what I'm doing.

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".

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.

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.

Yeah, maybe it needs another name because yes when you say you're vibe coding everyone imagines some 20 year old kid with sunglasses spitting out Javascript and calling it Python. While the tools are the same, the understanding and the discipline is very different.

I think "tech lead managing offshore development" is an excellent analogy.

Reviewing thousands of lines at a time is always a failure state.

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.

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?

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.

Even if you could the code can't be copyrighted.

I don't see why it's an either or. As explained in the article, I'm still coding all day. Just some trivial PRs are getting done and tidied up while I'm doing so. You still have to do all of the code review, and you still have to solve all of the hard problems, you just do less of the refactoring by hand.

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.

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.

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.

But, what I found over time is that as my role grew, the amount of work that could be done grew exponentially. In grad school I had one project to work on, by postdoc there was 10 papers that could be juggled, now there's so many different projects/collaborations/contracts/etc. that I could be a part of that it's all just a matter of "do I have time for that?". Then the team sizes start to grow: having one student turns into 5, into a lab, into a team at one company, then a growing team at another, and an open source organization. In one decade life changed from "wake up, figure out what to program, make it" to "wake up, see the deluge of issues and PRs, start code review, try to get that done so I can start 'my' day", and I think most people in programming tend to have a trajectory like that. The role changes from "build something" to "find out where others are getting stuck and unblock them", plus 200+ issues files about trivial shit. The goal here is to to have the LLMs handle the trivial shit, I unblock someone, and then finally the glory hour of me getting to build something is back!

But I think this is why there are lots of very smart people who have decided they wanted to be individual contributors in Silicon Valley instead. And they are really well-respected, and you want them in your squad! If that's the direction you want to go, then you probably also are of the kind that avoids LLMs a bit (and are thus a good person to have on a team, balancing velocity people with precision people). But if you want to start driving bigger projects, sooner or later teams grow as that's the only way to put out the bigger grander idea.

But I do think that if Anthropic made a Claude stuffed animal with a very punchable face it would be a very hot selling add-on as while this can accelerate the day, sometimes it makes the stupidest decisions and you really have to think "okay it doesn't hate me, it's not trying to spite me, it doesn't even know me, but damn it tried to hide that it commented out the one most crucial test!"

Perhaps not when the code is getting written (by yourself or by an AI).

When you're dealing with a memory leak in production (yes, they can and do happen), or worse -- if you're dealing with a drop in performance -- good luck with the vibe debugging.

Maybe there will be a time not too far off in the future when the stochastic cockatoos become sentient enough to do all of this by themselves, it's sure as hell not happening tomorrow.

Oh, and logarithmic tables were still a useful thing as late as forty odd years ago :)

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.

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.

You sound like you have not spent much time using AI tools.

In both cases the more experience and mindful experimentation you have the better your results will be.

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.

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.