After two years of vibecoding, I'm back to writing by hand
atmoio.substack.com
After two years of vibecoding, I'm back to writing by hand
1–10 of 652 posts
Re: After two years of vibecoding, I'm back to writing by hand
#2I'm impressed that this person has been vibecoding longer than vibecoding has been a thing. A real trailblazer!
Re: After two years of vibecoding, I'm back to writing by hand
#3two years of vibecoding experience already?
his points about why he stopped using AI: these are the things us reluctant AI adopters have been saying since this all started.
Re: After two years of vibecoding, I'm back to writing by hand
#4I'm impressed that this person has been vibecoding longer than vibecoding has been a thing. A real trailblazer!
GitHub copilot was released in 2021, and Cursor was released around October 2023[0].
Re: After two years of vibecoding, I'm back to writing by hand
#5> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not.
Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM.
LLMs allow me to write code faster and it also gives a lot of discoverability of programming concepts I didn't know much about. For example, it plugged in a lot of Tailwind CSS, which I've never used before. With that said, it does not absolve me from not knowing my own codebase, unless I'm (temporarily) fine with my codebase being fractured conceptually in wonky ways.
I think vibecoding is amazing for creating quick high fidelity prototypes for a green field project. You create it, you vibe code it all the way until your app is just how you want it to feel. Then you refactor it and scale it.
I'm currently looking at 4009 lines of JS/JSX combined. I'm still vibecoding my prototype. I recently looked at the codebase and saw some ready made improvements so I did them. But I think I'll start to need to actually engineer anything once I reach the 10K line mark.
Re: After two years of vibecoding, I'm back to writing by hand
#6> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not. Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM. LL…
> My way is to understand my own codebase and look at the output of the LLM.
Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
Re: After two years of vibecoding, I'm back to writing by hand
#7two years of vibecoding experience already ? his points about why he stopped using AI: these are the things us reluctant AI adopters have been saying since this all started.
The practice is older than the name, which is usually the way: first you start doing something frequently enough you need to name it, then you come up with the name.
Re: After two years of vibecoding, I'm back to writing by hand
#8AI is incredibly dangerous because it can do the simple things very well, which prevents new programmers from learning the simple things ("Oh, I'll just have AI generate it") which then prevents them from learning the middlin' and harder and meta things at a visceral level.
I'm a CS teacher, so this is where I see a huge danger right now and I'm explicit with my students about it: you HAVE to write the code. You CAN'T let the machines write the code. Yes, they can write the code: you are a student, the code isn't hard yet. But you HAVE to write the code.
Re: After two years of vibecoding, I'm back to writing by hand
#9> Not only does an agent not have the ability to evolve a specification over a multi-week period as it builds out its lower components, it also makes decisions upfront that it later doesn’t deviate from.
That's your job.
The great thing about coding agents is that you can tell them "change of design: all API interactions need to go through a new single class that does authentication and retries and rate-limit throttling" and... they'll track down dozens or even hundreds of places that need updating and fix them all.
(And the automated test suite will help them confirm that the refactoring worked properly, because naturally you had them construct an automated test suite when they built those original features, right?)
Going back to typing all of the code yourself (my interpretation of "writing by hand") because you don't have the agent-managerial skills to tell the coding agents how to clean up the mess they made feels short-sighted to me.
Re: After two years of vibecoding, I'm back to writing by hand
#10> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not. Well yea, but you can guard against this in several ways. My way is to understand my own codebase and look at the output of the LLM. LL…
> My way is to understand my own codebase and look at the output of the LLM. Then you are not vibe coding. The core, almost exclusive requirement for "vibe coding" is that you DON'T look at the code. Only the product outcome.
I know what you mean but to look that black and white at it seems dismissive of the spectrum that's actually there (between vibecoding and software engineering). Looking at the whole spectrum is, I find, much more interesting.
Normally I'd know 100% of my codebase, now I understand 5% of it truly. The other 95% I'd need to read it more carefully before I daresay I understand it.