Hacker News Reader

Comment by dawnerd | Hacker News Reader

By the time you do all of that you might as well just write code by hand.

that's really just a scale question.

Yes, I would write a 4 line bash script by myself.

But if you're trading a 200 line comprehensive claude.md document for a module that might be 20k LoC? it's a different value proposition.

And how do you actually know that those 20k line of codes have no glaring bugs, or bugs that you can find yourself, or be able to understand it completely at some point?

The way I do this is by still writing tests.

Do tests let you understand a codebase you have not written?

They can. Particularly if you use them to validate your assumptions about the code.

this desire to understand code will be soon be seen as rather anachronistic. What's important is that you understand your tests. Let the AI generate the code.

The spec and the test are your human contribution.

I understand your point of view but I think it's too "optimistic", i.e. it will not happen soon, at least not outside AI maximalists.

you're describing TDD and it never turned into the panacea that was promised. I'm excited to try claude code, i even have a decent little personal project lined up for it but someone somewhere will always need to understand the code because tests are never 100% exhaustive and major flaws come up.

Ah yes, can't wait to tell my auditor / regulator "I don't understand the code because Claude wrote it, but it's fine, because understand the code is for boomers." That will get a big laugh in a deposition.

That'll be anachronistic too obviously. Your tests will be audited.

If the tests are written with sufficient detail that you don't need to look at the code, the implementation of the code is such a small part of the overall work that you are gaining very little in terms of overall productivity.

I agree

I would say yes.

To have useful tests, you must write the APIs for the functions, and give examples of how to wire up the various constructs, and correct input/output pairs.

Implementations of those functions that pass the test now have significant constraints that mean you understand a lot about it.

That’s called Test Driven Development.

First you write the tests, then you write code until tests pass.

How do you know your own handwritten 20k lines of code have no bugs, or that 20k lines of code written by coworkers have no bugs?

I'm not the person you're replying to, but I have a lot more confidence in my own 20k lines of code than an AIs. I've built up skills to write performant, readable, functional, maintainable code. I build it up slowly and I can anticipate bugs as I write. I'm not perfect, but when bugs do arise, since I've built up the code, I have some idea of where to look and where not to look in order to fix them.

As for coworkers, I would really try to get them to work in chunks smaller than 20k loc. But at some point you have an expectation that coworkers will be accountable for their area of responsibility. If there's a bug in their code, they're expected to fix it. If there's a bug in the AIs code, I'm expected to fix it....

And are you willing to stand behind those 20k loc? Like, whoever you're submitting it to, you can say "this is my work, it is done to a level of quality I find acceptable"?

You don't do it manually. You have claude do it once you’ve guided it back on track to remind itself not to do it next time.

I think you are perhaps missing the point. Investing into these techniques [2] enables you to do unhinged things. Such as building a compiler whilst you are AFK [1].

[1] https://x.com/i/broadcasts/1OyJALVOnEzGb

[2] https://ghuntley.com/ralph

Sure if I want to just toy around for fun.

Those are cool, but a production system is infinitely more complex.

What do you define as a production system? Are you aware that one can generate TLA+ specifications, then code generate from these specifications and assert that the implementation matches the TLA+ spec?

Reply on news.ycombinator.com