Live data from Hacker News

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

atmoio.substack.com

431–440 of 652 posts

Re: After two years of vibecoding, I'm back to writing by hand

#431

Earlier quoted context omitted.

Embrace TDD? Write those tests and tell the agent to write the subject under test?

Different strokes for different folks and all, but that sounds like automating all of the fun parts and doing all of the drudgery by hand. If the LLM is going to write anything, I'd much rather make it write the tests and do the implementation myself.

This is a serious problem with professional software development — programmers see testing as a chore, and self-indulge in the implementation.

Re: After two years of vibecoding, I'm back to writing by hand

#432

AI 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'…

Not only that, it's constitution. I'm finding this with myself. After vibe coding for a month or so I let my subscription expire. Now when I look at the code it's like "ugh you mean now I have to think about this with my own brain???"

Even while vibe-coding, I often found myself getting annoyed just having to explain things. The amount of patience I have for anything that doesn't "just work" the first time has drifted toward zero. If I can't get AI to do the right thing after three tries, "welp, I guess this project isn't getting finished!"

It's not just laziness, it's like AI eats away at your pride of ownership. You start a project all hyped about making it great, but after a few cycles of AI doing the work, it's easy to get sucked into, "whatever, just make it work". Or better yet, "pretend to make it work, so I can go do something else."

Re: After two years of vibecoding, I'm back to writing by hand

#434

I feel like I'm taking crazy pills. The article starts with: > you give it a simple task. You’re impressed. So you give it a large task. You’re even more impressed. That has _never_ been the story for me. I've tried, and I've got some good pointers and hints where to go and what to try, a result of LLM's extensive if shallow reading, but in the sense of concrete problem solving or code/script writing, I'm _always_ di…

You're not crazy, I'm also always disappointed. My theory is that the people who are impressed are trying to build CRUD apps or something like that.

so 99% of all software?

Re: After two years of vibecoding, I'm back to writing by hand

#435
post #253

I feel like I'm taking crazy pills. The article starts with: > you give it a simple task. You’re impressed. So you give it a large task. You’re even more impressed. That has _never_ been the story for me. I've tried, and I've got some good pointers and hints where to go and what to try, a result of LLM's extensive if shallow reading, but in the sense of concrete problem solving or code/script writing, I'm _always_ di…

I usually do most of the engineering and it works great for writing the code. I’ll say: > There should be a TaskManager that stores Task objects in a sorted set, with the deadline as the sort key. There should be methods to add a task and pop the current top task. The TaskManager owns the memory when the Task is in the sorted set, and the caller to pop should own it after it is popped. To enforce this, the caller to…

This is a good start. I write prompts as if I was instructing junior developer to do stuff I need. I make it as detailed and clear as I can.

I actually don't like _writing_ code, but enjoy reading it. So sessions with LLM are very entertaining, especially when I want to push boundaries (I am not liking this, the code seems a little bit bloated. I am sure you could simplify X and Y. Also think of any alternative way that you reckon will be more performant that maybe I don't know about). Etc.

This doesn't save me time, but makes work so much more enjoyable.

Re: After two years of vibecoding, I'm back to writing by hand

#436
post #272

Earlier quoted context omitted.

> I can attest that the first pass of testing can often be shit. That's why you iterate. So far, by the time I’m done iterating, I could have just written it myself. Typing takes like no time at all in aggregate. Especially with AI assisted autocomplete. I spend far more time reading and thinking (which I have to do to write a good spec for the AI anyways).

Nope, you couldn't have written it yourself in the same time. That's just a false assumption a lot of you like to make.

[dead]

Re: After two years of vibecoding, I'm back to writing by hand

#437
post #300
post #275

Earlier quoted context omitted.

What you’re describing makes sense, but that type of prompting is not what people are hyping

The more accurate prompt would be “You are a mind reader. Create me a plan to create a task manager, define the requirements, deploy it, and tell me when it’s done.” And then you just rm -rf and repeat until something half works.

"Here are login details to my hosting and billing provider. Create me a SaaS app where customers could rent virtual pets. Ensure it's AI and blockchain and looks inviting and employ addictive UX. I've attached company details for T&C and stuff. Ensure I start earning serious money by next week. I'll bump my subscription then if you deliver, and if not I will delete my account. Go!"

Re: After two years of vibecoding, I'm back to writing by hand

#438

The tale of the coder, who finds a legacy codebase (sometimes of their own making) and looks at it with bewilderment is not new. It's a curious one, to a degree, but I don't think it has much to do with vibe coding.

I have been working for 20 years and I haven’t really experienced this with any code I’ve written. Sure I don’t remember every line but I always recall the high level outlines.

I admit I could be an outlier though.

Re: After two years of vibecoding, I'm back to writing by hand

#439
I tried vibe-coding few years back and switched to "manual" mode when I realized I don't fully understand the code. No, I did read each line of code and understood it, I understood the concepts and abstractions, but I didn't understand all nuances, even those at the top of documentation of libraries LLM used.

I tried minimalist example where it totally failed few years back, and still, ChatGPT 5 produced 2 examples for "Async counter in Rust" - using Atomics and another one using tokio::sync::Mutex. I learned it was wrong then the hard way, by trying to profile high latency. To my surprise, here's quote from Tokio Mutex documentation:

Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code.

The feature that the async mutex offers over the blocking mutex is the ability to keep it locked across an .await point.

Re: After two years of vibecoding, I'm back to writing by hand

#440

Earlier quoted context omitted.

I think it’s usage patterns. It is you in a sense. You can’t deny the fact that someone like Ryan dhal creator of nodejs declared that he no longer writes code is objectively contrary to your own experience. Something is different. I think you and other deniers try one prompt and then they see the issues and stop. Programming with AI is like tutoring a child. You teach the child, tell it where it made mistakes and yo…

> Programming with AI is like tutoring a child. You teach the child, tell it where it made mistakes and you keep iterating and monitoring the child until it makes what you want. Who are you people who spend so much time writing code that this is a significant productivity boost? I'm imagining doing this with an actual child and how long it would take for me to get a real return on investment at my job. Nevermind that…

Here's an example:

I recently inherited an over decade old web project full of EOL'd libraries and OS packages that desperately needed to be modernized.

Within 3 hours I had a working test suite with 80% code coverage on core business functionality (~300 tests). Now - maybe the tests aren't the best designs given there is no way I could review that many tests in 3 hours, but I know empirically that they cover a majority of the code of the core logic. We can now incrementally upgrade the project and have at least some kind of basic check along the way.

There's no way I could have pieced together as large of a working test suite using tech of that era in even double that time.

Post reply on HN