Live data from Hacker News

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

atmoio.substack.com

251–260 of 652 posts

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

#251

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 have found AI great in alot of scenarios but If I have a specific workflow, then the answer is specific and the ai will get it wrong 100% of the time. You have a great point here.

A trivial example is your happy path git workflow. I want:

- pull main

- make new branch in user/feature format

- Commit, always sign with my ssh key

- push

- open pr

but it always will

- not sign commits

- not pull main

- not know to rebase if changes are in flight

- make a million unnecessary commits

- not squash when making a million unnecessary commits

- have no guardrails when pushing to main (oops!)

- add too many comments

- commit message too long

- spam the pr comment with hallucinated test plans

- incorrectly attribute itself as coauthor in some gorilla marketing effort (fixable with config, but whyyyyyy -- also this isn't just annoying, it breaks compliance in alot of places and fundamentally misunderstands the whole point of authorship, which is copyright --- and AIs can't own copyright )

- not make DCO compliant commits ...

Commit spam is particularly bad for bisect bug hunting and ref performance issues at scale. Sure I can enforce Squash and Merge on my repo but why am I relying on that if the AI is so smart?

All of these things are fixed with aliases / magit / cli usage, using the thing the way we have always done it.

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

#252

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…

[flagged]

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

#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 pop must pass in an allocator and will receive a copy of the Task. The Task will be freed from the sorted set after the pop.

> The payload of the Task should be an object carrying a pointer to a context and a pointer to a function that takes this context as an argument.

> Update the tests and make sure they pass before completing. The test scenarios should relate to the use-case domain of this project, which is home automation (see the readme and nearby tests).

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

#254

After reading the article (and watching the video), I think the author makes very clear points that comments here are skipping over. The opener is 100% true. Our current approach with AI code is "draft a design in 15mins" and have AI implement it. The contrasts with the thoughtful approach a human would take with other human engineers. Plan something, pitch the design, get some feedback, take some time thinking throu…

You can update the spec as you go... There's nothing that makes the spec concrete and unchangeable.

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

#255
post #134

Earlier quoted context omitted.

> That being said. I have no idea how you'd actually go about teaching students CS these days, considering a lot of them will probably use ChatGPT or Claude regardless of what you do. My son is in a CS school in France. They have finals with pen and paper, with no computer whatsoever during the exam; if they can't do that they fail. And these aren't multiple choice questions, but actual code that they have to write.

I wrote code in a spiral notebook because the mainframe was not available to me at home.

(U880 - GDR Z80 8 bit CPU clone)

I wrote assembler on pages of paper. Then I used tables, and a calculator for the two's-complement relative negative jumps, to manually translate it into hex code. Then I had software to type in such hex dumps and save them to audio cassette, from which I could then load them for execution.

I did not have an assembler for my computer. I had a disassembler though- manually typed it in from a computer magazine hex dump, and saved it on an audio cassette. With the disassembler I could check if I had translated everything correctly into hex, including the relative jumps.

The planning required to write programs on sheets of paper was very helpful. I felt I got a lot dumber once I had a PC and actual programmer software (e.g. Borland C++). I found I was sitting in front of an empty code file without a plan more often than not, and wrote code moment to moment, immediately compiling and test running.

The AI coding may actually not be so bad if it encourages people to start with high-level planning instead of jumping into the IDE right away.

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

#256
post #42

> The AI had simply told me a good story. Like vibewriting a novel, the agent showed me a good couple paragraphs that sure enough made sense and were structurally and syntactically correct. Hell, it even picked up on the idiosyncrasies of the various characters. But for whatever reason, when you read the whole chapter, it’s a mess. It makes no sense in the overall context of the book and the preceding and proceeding…

I don’t get the analogy because novel is supposed to be interesting. Code isn’t supposed to be interesting, it’s supposed to work.

If you’re writing novel algorithms all day, then I get your point. But are you? Or have you ever delegated work? If you find the AI losing its train of thought all it takes is to try again with better high level instructions.

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

#257

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

I had my first interview last week where I finally saw this in the wild. It was a student applying for an internship. It was the strangest interview. They had excellent textbook knowledge. They could tell you the space and time complexities of any data structure, but they couldn't explain anything about code they'd written or how it worked. After many painful and confusing minutes of trying to get them to explain, li…

Sounds a little bit like the stories from Feynman, e.g.: https://enlightenedidiot.net/random/feynman-on-brazilian-edu...

The students had memorized everything, but understood nothing. Add in access to generative AI, and you have the situation that you had with your interview.

It's a good reminder that what we really do, as programmers or software engineers or what you wanna call it, is understanding how computers and computations work.

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

#258

unless someone shows their threads of prompts or an unedited stream of them working, it's pointless to put any weight into their opinions. this is such an individualized technology that two people at the same starting point two years ago, could've developed wildly different workflows.

That's the sad part. Empiricism is scarce when people and companies are incentivized to treat their AI practices as trade secrets. It's fundamentally distinct from prior software movements which were largely underwritten by open, accessible, and permissively-licensed technologies.

I don't see people treating AI practices as trade secrets. It's just the nature of a non-deterministic system.

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

#259
post #230

Earlier quoted context omitted.

There's also plenty of mech tales where the mech pilots need to spend as much time out of the suits making sure their muscles (and/or mental health) are in good strength precisely because the mechs are a "force multiplier" and are only as strong as their pilot. That's a somewhat common thread in such worlds.

Yes. Also, it's a fairly common trope that if you want to pilot a mech suit, you need to be someone like Tony Stark. He's a tinkerer and an expert. What he does is not a commodity. And when he loses his suit and access to his money? His big plot arc is that he is Iron Man. He built it in a cave out of a box of scraps, etc. There are other fictional variants: the giant mech with the enormous support team, or Heinlein'…

For me the idea of "people piloting mech suits" brings up lost kids, like Shinji from nge.

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

#260

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…

Just a supplementary fact: I'm in the beneficial position, against the AI, that in a case where it's hard to provide that automatic feedback loop, I can run and test the code at my discretion, whereas the AI model can't. Yet. Most of my criticism is not after running the code, but after _reading_ the code. It wrote code. I read it. And I am not happy with it. No even need to run it, it's shit at glance.

Yesterday I generated a for-home-use-only PHP app over the weekend with a popular cli LLM product. The app met all my requirements, but the generated code was mixed. It correctly used a prepared query to avoid SQL injection. But then, instead of an obvious:

    "SELECT * FROM table WHERE id=1;" 
it gave me:

    $result = $db->query("SELECT * FROM table;");
    for ($row in $result)
        if ($["id"] == 1)
            return $row;

With additional prompting I arrived at code I was comfortable deploying, but this kind of flaw cuts into the total time-savings.
Post reply on HN