After two years of vibecoding, I'm back to writing by hand [video]

> they are incredible help

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.

I've started disregarding any AI take that is all-or-nothing. These tools are useful for certain work once you've learned their limitations. Anyone making sweeping claims about vibecoding-style use being viable at scale or making claims that they're completely useless is just picking a side and running with it.

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.

> I think the problem is that people:

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

With respect for your priorities that may be different from mine, it would sadden me a little to always have to work like this, because it would rob me of the chance to think deeply about the problem, perhaps notice analogies with other processes, or more general or more efficient ways to solve the problem, perhaps even why it was necessary at all. Those are the tasty bits of the work, a little something just for me, not for my employer.

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.

Wait, your job was len(x) == 15?

quick validation for which you wrote a 3 paragraphs long prompt? sounds like you've wasted time

Curious what was the validation/diff size?

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 have a pragmatic approach, but you don't have a PR unless you have inspected and tested the code. Just submitting code generated by a tool without personally vouching for it's correctness and sanity is not engineering.

This isn't the usecase that's being criticized. Here you are responsible for the fix. You will validate and ship it and if something goes wrong, you will answer for it. The AI won't answer for it.

My stance is that it's similar to hand tools vs power tools.

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.

Have you watched the video? One of the points made in the video is to come back in two years and read the code base resulted from vibecoding.

Same, it's so good for these little things. And once you start adding rules and context for the "how to add the change/feature flags", etc you get that 3 paragraphs down. Now our head of product is able to fire off small changes instead of asking a dev, making them context switch, etc. Devs still review but the loop is so much shorter.

> didn't have to sit and wait for CI or any of the other bullshit to get it done

You run CI on human-generated PRs, but not AI-generated PRs? Why would there be a difference in policy there?

This is just sad to read. AI makes all of us stupider by the day, no matter what the tech bros and wanna-be billionaires of HN tells us...

Definitely, it's great at making a template but, it's hard to see or continue from what it has generated.

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.

If your Management thinks it's acceptable to increase velocity by shipping crappy code, I'm surprised they never thought to do this before AI.

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.

> there is pressure to ship crappy code

this is true with or without AI

The rush it out the door mentality of this industry is stupid.

To me the biggest benefit has been getting AI to write scripts that automate some things for me that are tedious but not needed to be deployed. Those scripts don’t have to be production-grade and just have to work.

Similar experience. I just tried Claude for the first time last week, and I gave it very small tasks. "Create a data class myClass with these fields<•••> and set it up to generate a database table using micronaut data" was one example. I still have to know exactly what to do, but I find it very nice that I didn't have to remember how to configure micronaut data, (which tbf is really easy) I just had to know that that's what I wanted to use. It's not as revolutionary as the hype, but it does increase productivity quite a bit, and also makes programming more fun I think. I get to focus on what I want to build, instead of trying to remember jdbc minutiae. Then I just sanity check the generated code, and trust that I will spot mistakes in that jdbc connection. It felt like the world's most intuitive abstraction layer between me and the keyboard, a pretty cool feeling.

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!

Software developers should be worried about their jobs, not because these tools are capable of replacing them or reducing a company’s need for human developers, but rather because the _perception_ that they can/will replace developers is causing a major disruption in hiring practices.

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?

I expect it'll be a sigmoid curve — we're in the exponential growth phase, but it'll flatten out. Then we'll need to wait for the next Big Idea to give us another the next sigmoid.

That’s what I said about self driving cars nearly a decade ago!

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.

Counterpoint…

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.

Elegance or "taste" for the codebase is wrong. It's not just a stylistic preference. It's objectively bad code that's going to be slow to iterate on and very easy to introduce bugs to

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"

This is a major annoyance for me. In one PR I reviewed recently, it introduced concurrency where it was not needed and then cascaded to a bunch of synchronization logic everywhere as a result. What could have been 30 lines or so turned into a couple hundred line diff and the submitter did not think to question it. It was harder to review and introduced a potential for data races with zero benefit. These are all competent people I work with, who do good work normally too.

On the other hand, how do you know what they're prompting? For all you know, the AI proposed the hacky 10 line fix and tour coworker was all hey let's fix this problem better.

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?

I'm sorry but Claude Code is AGI.

You're gonna be out of work in the next month or two if you don't jump on this train immediately.

With the power of Claude one engineer can do the work it used to take 30-40 employees to do.

Artisanal engineering is dead.

Human Language is the new code.

"You like code that's easy to work with, easy to understand, change and evolve? HAH! Bet you hate colored brackets and prettifying too!"

I wonder if I will feel compelled to go back. Right now it just feels too productive for me to not let AI write some of the code.

Why is not using LLMs self harming? We've been writing code without help of LLMs for many decades just fine.

I consider vibe coding and LLM-assistance to be distinctively separate things.

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.

I received multiple codes. Entered the latest one and a pop up message says, "Our dog’s gone off-leash… We’ve run into a problem and are working to fix it as fast as we can. Please try again soon."

I am not liking this era of infinite abundance.

Tell it to stop?

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.

No.

2. tends to happen less with more experienced engineers

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.

You're producing technical debt. At some point you will invest more time fixing the vibe slop than it would have cost you to do the work yourself in the first place. A lot of vibe-coding just feels like shifting responsibility and resources from "development" to "incident response".

How do you know the output is correct?

More like X-times daily. Where X is a function of how much money Company Y need to get from investors this week to continue training and running LLM models.

Nothing that is possible is "too hard" if you're willing to put in some effort. The only question is whether you will learn to do it, or press a button, hope the LLM did it well, and let it forever remain "too hard."

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.

> Try implementing something that is too hard for you.

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.