Live data from Hacker News

I'm going back to writing code by hand

blog.k10s.dev

641–650 of 656 posts

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

#641
post #640
post #274

Earlier quoted context omitted.

the venn diagram of people who say "AI produces useless results I have to 100% throw away" and people who say "I've never successfully delegated parts of large software development to junior programmers" is a circle

Junior programmers learn and provide a wide value, AI does not

I get a lot more done with lot less frustration giving my work to Claude than to a junior dev quite frankly and I've managed many groups over my career.

the value of the junior dev is the hopes that they'd be a senior dev someday, I dont have a solution to that problem. But in my current capacity where the only devs I'm "managing" these days are via open source contributions, they're already gone - 100% of what I get is through their own work with LLMs (which I have to spend more time correcting than if I used the LLM myself).

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

#642
post #434

Earlier quoted context omitted.

From the description of the recommended tool it sounded to me like something that you use to deterministically generate code from a spec, which you could then modify if you like. That would be the same kind of dependency as the LLM workflow you describe, except that the abstraction is well-defined in a way that the LLM is not. Whether it's good or not is a different question.

That would be nice if it were the case but from what I can gather from this interesting dependency graph, there's a hard dependency on its renderer and schema. https://jsonforms.io/img/architecture.svg You can add your custom renderer but you still need their library for bindings and such.

If that is really a concern you could always have a pre-render step or server side render, whatever the name dujour is.

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

#643
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…

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…

I completely agree. I have tried N different ways to use AI and the one that really works for me is to step by step getting the AI to build one modular feature at a time (a method, a basic class etc.) I then review and fix if necessary. It works really well.

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

#644
post #308
post #291

Earlier quoted context omitted.

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.

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.

That is correct. Using an AI to generate code and then not verify it yourself is IMHO unprofessional and should get you at a minimum a verbal warning. YOU are responsible for the code NOT the AI.

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

#645
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.

30 years of experience writing bad code, with no effort to improve, doesn't make you any good. You need to right attitude and humility to become good.

Some of the worst programmers I have ever worked with had 30+ years of experience. They basically spend all of their time fixing bug after bug in a never ending cycle because the software they produced was so fragile that it would crash if you just looked at it wrong or the temperature in the room wasn't perfect.

While others with the same number of years of experience had massive systems in production for years with not a single bug reported by the happy users.

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

#648
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…

[deleted]

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

#649

Earlier quoted context omitted.

The 10x gains don't exist. Anyone with a modicum of programming skill and hype resistance has been saying this for a while.

Sure they do: it’s easy to get 10x gains if you were only producing 0.1x before.

This is what I'm seeing - for people who were slow and didn't posses a lot of depth or breadth, their blast radius and impact has skyrocketed. They can now work in unfamiliar domains quickly, without any knowledge of the nitty gritty details of those domains!

For me personally, it's a tradeoff of generating the first pass code 10x more quickly, but then deeply knowing and validating the code is then 10-20x more work than it would have been if I'd written it myself (and if time is of the essence, then there's the option of shallow validation/understanding in exchange for speed - which is a compromise in rigor and path towards tech debt). In the end, none of this seems like a net win (unless you don't care about quality), and it is much less enjoyable.

TL;DR; While LLMs are faster to spit out first pass code, by the time I've validated and fixed the LLM's first-pass work, I could've had my "by-hand" implementation done correctly, and had much deeper understanding out of the box. Net loss.

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

#650
post #635
post #632

Earlier quoted context omitted.

> There are other ways to achieve this goal though, that don’t require exhaustive human review, better models are able to do that part as well if properly guided. Not at this time. Even if you could somehow get their success rate to 90%, it's still far too low because the mistakes can be (and are occassionally) catastrophic. It's only when you review everything that you find mistakes that will bite you down the line.…

I haven’t had this problem. Maybe it’s because of the language I’m using (C++) or maybe it’s because of the strict enforcement of modularity and public vs private interfaces, etc that I use? Also, the code is tested against the hardware with every change. Idk if that’s why my experience has been different from yours or not. My workflow also requires a discussion of the architecture and methodology of each addition or…

I don't think our experience is different. Letting the agent work on pieces no bigger than a couple hundred lines at a time and checking if there's something fishy or not and that the code is legible and logical is close human supervision. This is very much not what the people who wish AI could build products for them do or can do at the rate they're moving.
Post reply on HN