Live data from Hacker News

I'm going back to writing code by hand

blog.k10s.dev

571–580 of 656 posts

Re: I'm going back to writing code by hand

#571
post #192

Yep. The only people I've heard saying that generated code is fine are those who don't read it. The problem is that the mitigations offered in the article also don't work for long. When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it’s small, like the selection of a data structure. You can tell the agent what the…

I read all the code I generate with Cursor and some of it smells a bit weird but is easily fixable and most of it is as good as what I would write or better.

I read a bunch of Claude-Code-generated code last week and I was pretty impressed. It followed the established service class paradigm almost as exactly as we'd originally intended. The code was mostly very clean and had copious comments. A big step up from 2025 code.

For the record, I definitely don't immediately read the majority of code Claude writes these days. I just check on it periodicially. In terms of code quality it's as good as any human I know of.

Can be a bumbler at times. So can people.

Re: I'm going back to writing code by hand

#572
post #456

Earlier quoted context omitted.

You proved that testing is a good idea, not that vibe coding is a good idea.

To be honest, I am past the point of wanting to convince people that AI is useful, if you want to refuse new tools other people find helpful, your loss. (Also I stick to the original definition of "vibe coding = not looking at generated code", "LLM assisted coding = verify generated code", I do both, depending on the task)

So basically your only test is "it compiles" since you have no idea what it's actually testing.

Re: I'm going back to writing code by hand

#573
post #291
post #264

Earlier quoted context omitted.

That doesn't quite work, and precisely for the reason I mentioned: You can definitely tell the AI to follow some strategy, but at some point the strategy will need to change, and the AI won't tell you that (even if you tell it to). Unless you read the code every time you won't know if the AI is following the strategy and producing good results or following it and producing bad results because the strategy has to chan…

How do you define "bad code"? If I instruct the AI to make small modules where I can verify they work, have tests and no side effects - then it is good enough code for me. It works, is readable and can be extended - and will turn into bad code if this is not done with care.

> How do you define "bad code"?

Code that will not be able to evolve for more than one-two years is terrible code. Agents write terrible code while doing a truly impressive job hiding it (including in the tests they write) unless, of course, you keep them under very close supervision.

Re: I'm going back to writing code by hand

#574
post #324

Earlier quoted context omitted.

The GC shouldn't care about all the code it is collecting. I collects garbage, it doesn't care if the garbage is a intermediate value from your tax calculations, or the the previous state image from your UI - either way it is garbage and it is gone. Now in a few cases details of garbage collection matter by enough that it is worth something more invasive for some reason, but the vast majority of code shouldn't care a…

I don't get your comment. The GC is part of the runtime, to it user code is data. But the JIT compiler and other internal details of the runtime are its code, and there are very real cross-cutting concerns, like the JIT compilers output should take into account what memory representation the GC expects, where are barriers, when one is run etc. So I'm talking about a project such as the JVM. > have millions of lines o…

I don't work in that area, but I strongly suspect that they do their best to confine the interactions to small places if that is possible. Maybe not though.

Re: I'm going back to writing code by hand

#575
post #531

Earlier quoted context omitted.

Question: What do you think the word "effectively" means in the comment above?

Not OP, but it means nothing, because it's not "effectively" becoming a compiler. Think about it from an information theory standpoint: A compiler takes at least the exact amount of information it needs to produce a result, and produces exactly that result every time (unless it's bad at its job or has a bug). An LLM always takes far less information than would actually be needed to fully describe the desired output,…

You're rebutting a comment that says something like: "LLMs are literally becoming compilers"

No one said that

Re: I'm going back to writing code by hand

#576

Earlier quoted context omitted.

Question: What do you think the word "effectively" means in the comment above?

I interpret it as "in practice", "now". Non-native English speaker here, so I may have missed your meaning. If you meant they’re now better at mimicking compilers, sure, but they’re only mimicks.

Yes, I am saying there's no functional difference (for practical purposes) between a deterministic transformation like a compiler and a perfect probabilistic transformation like an LLM.

We do not have "perfect" probabilistic transformation, and we probably never will (in part because it's hard to know what exactly that even means), but the gap between the two is shrinking every day.

Ergo:

> they're becoming (effectively) more and more similar every day.

Re: I'm going back to writing code by hand

#577

Earlier quoted context omitted.

The "people" in your hypothetical story have been wrong the whole time. The correct attitude is: When AI can complete lines, you still have to read and understand the code. When AI can complete whole functions, you still have to read and understand the code. When AI can complete features and tickets, you still have to read and understand the code.

I heard a talk from a VP at NVIDIA a couple of months ago and he echoed this. Essentially their policy is "you are still fully responsible for the code you ship, whether AI helps with it or not"

this is a good policy, as long as the productivity expectations match it. The problem happens when you combine "you're responsible for what you ship" with "you need to be 100x faster"

Re: I'm going back to writing code by hand

#578

Earlier quoted context omitted.

If you know how to write good code you can force AI to write good code with various techniques. It's 100% doable. You just need to figure out the problems AI has and find solutions to make it easier for it. Ex: extremely small contexts Modularize to modules with clear boundaries and only allow the AI to work within those boundaries. Make modules pure from IO so they are easily testable. Hide modules behind interfaces…

So, basically you need to micro-manage it. Where are your 10x gains now? And is it fun to work like that?

i love my 2x gains, still hands-on with problem, not losing context, not outsourcing thinking. just automating the boring parts.

Re: I'm going back to writing code by hand

#579
post #570

Earlier quoted context omitted.

I get what you mean, but that can also happen with code written by humans.

Sure, by inexperienced ones.

Hm. Some have rather a lot of experience of making such mess themself.

I mean for real, is the idea here, that all programmers are or were some kind of semi gods?

Because this is not what I remember from the pre LLM time, rather this:

https://xkcd.com/2030/

I know I got into such developement hell myself. Fix a bug here, results in braking something there. Experience surely helps in avoiding it .. but even senior devs can make a mess. Otherwise there wouldn't be so many projects canceled.

So sure, agents can multiply a mess in a amazingly short time, but .. that is up to the humans guiding them.

Re: I'm going back to writing code by hand

#580
post #308

Earlier quoted context omitted.

Sure, if you carefully review the agent's output, including tests, you can get good results. If you don't carefully review the output, you obviously have no idea if it's good enough for you. The only way to find out is that 30 changes down the line the agent won't be able to change one thing without breaking another, but by then the codebase will be too far gone to fix.

I get what you mean, but that can also happen with code written by humans.

Nobody is going to argue that humans are capable of writing bad code
Post reply on HN