Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm going back to writing code by hand

blog.k10s.dev

Post reply on HN
Print view View original

441–450 of 656 posts

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

#441

Post by hatefulmoron »

linuxftw wrote: post #418
hatefulmoron wrote: post #401

Earlier quoted context omitted.

You're right. I think having it spawn lots of subagents, read everything, formulate a big and detailed plan, only for it to be subtly wrong while requiring me to carefully review the result and the intermediate plans that produced it is quite tiring. I suppose things slip through.

If you understand these subtle pieces you perceive the AI to get wrong, you should include that in your prompt. Also, unit test and functional test coverage go a long way to ensure correct behavior.

I could also include the correct implementation for it to copy in the prompt, if you get what I'm trying to say. Some amount of laziness or vagueness in the prompt is an intended use case, it's surely the point of having the subagents do so much churning of tokens to research before writing the plan that I'm about to disregard. But sure, those are helpful tips.

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

#442

Post by hunterpayne »

readitalready wrote: post #435
pron wrote: 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 let agents break things 30 changes down the line. If something breaks, I add a check to my project validator and start over, with the validator providing instructions on what was wrong and how to fix it. It's all automatic, and now I have a guard against the exact same error in the future. Some of these checks have caught thousands of the same error, even with the latest Opus 4.7 writing the original code.

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

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

#443

Post by Kiro »

pron wrote: post #398
noelsusman wrote: post #390

Earlier quoted context omitted.

I guess I don't understand how this logic doesn't apply to human developers.

Human developers don't produce code at such a rate, and their judgment is, on average, better. So one, the review doesn't make you feel like you're slowing things down much, and two, the problems are less hidden.

> their judgment is, on average, better

I can only presume you work with talented people somewhere that is not representative of most companies. You're definitely overestimating the average programmer's abilities.

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

#444

Post by sim04ful »

My opinion is that we're using the wrong paradigms for LLMs. We should be leaning more on declaratively specifying behaviour.

If there's any hope for reliability, auditability, predictability to be had it lies in contraining and LlMs grammar whilst delegating freeform behavior to a more passive substrate.

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

#445

Post by tcgv »

pron wrote: 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…

> "Yep. The only people I've heard saying that generated code is fine are those who don't read it."

I review every line of code I generate with AI. I mainly use an MR-based approach:

1) Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. Usually at least one of them is on the right track, and it is better to ditch a solution that went in the wrong direction than to try to fix it.

2) Review the explanation and diff of the proposed changes line by line, file by file. If I find minor deviations from what I asked, or violations of the codebase architecture/conventions, I write comments in the diff and/or global comments, and ask again for 3x adjusted solutions.

3) Usually, by this point, the solution is ready for me to merge locally and either run local tests or do some manual fine-tuning.

4) Finally, I generate unit tests. I leave them to this stage because I can repeat the same process with the sole intent of generating case-specific unit tests. This way, I can generate/review tests against the final version of the implementation.

This has been working very well for me since our repos are reasonably organized and have a well-defined architecture. In the technical spec, I include the major architectural requirements and code conventions, and I also add a catch-all like "follow the codebase's existing conventions and style", which works reasonably well.

This simple process has enabled me to deliver most minor/medium tasks and bug fixes really quickly while maintaining control over the changes and without lowering the quality bar. For larger and more challenging tasks, I find myself "driving the wheel" (i.e. coding by hand) more often, and using AI code generation in a much more scoped and specific way. So that becomes a different process altogether.

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

#446

Post by andriy_koval »

IdiotSavage wrote: post #260
perarneng wrote: post #256

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?

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

it depends on language and infra, but some/many require lots of boilerplate and memorizing thousands of APIs, automating this is easy LLM 10x gain.

I for example write SQL myself, because boilerplate is super-minimal, and core SQL is very minimal itself, there are like 20 constructs to memorize.

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

#447

Post by cassianoleal »

baddash wrote: post #426
cassianoleal wrote: post #133

Earlier quoted context omitted.

I think it’s both in fact. Comprehension debt just sounds like there are things you don’t (yet) understand. Cognition debt means your lack of understanding compounds and the cognition “space” required to clear it increases accordingly. An increasing comprehension debt that can be paid off one bit at a time within reasonable cognition space takes linear time to clear. Cognition debt takes exponential time to clear the…

Woah, didn't expect a cognition debt researcher to be in the comment section jk :D your points make a lot of sense though!

lol no. Just an opinionated grey bearded software engineer with sleep deprivation. :D

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

#448

Post by mikepurvis »

RossBencina wrote: post #55
mikepurvis wrote: post #52

Earlier quoted context omitted.

I agree with what you're saying, but I think we do have a problem right now with definitions where there's a lot of people basically getting supercharged tab completions or running a chatbot or two in a parallel pane, but still clearly reviewing everything; and on the other side of things is freaking Steve Yegge pitching a whole new editor that lets you orchestrate a dozen or more agents all vibing away on code you'r…

> The first group are still thinking fairly deeply about design and interfaces and data structures, and are doing fairly heavy review in those areas. I can't speak for others, but I'd go further and say that LLMs allow me to go deeper on the design side. I can survey alternative data structures, brainstorm conversationally, play design golf, work out a consistent domain taxonomy and from there function, data structur…

GP and this is where I stand with it too. Additionally, the cost of "exploring" down a riskier design path and discovering the unknown unknowns is substantially reduced too, which I think ultimately leads to better decision-making on the design side. It's less "let's just stick to the pattern/tools that we know for sure works because we've done it before" and more "here's a vibed up mockup of it working, we can all see how this actually works and the better pattern that it enables".

Obviously technical and design choices have risks beyond just initial implementation, and those have to be considered too (do we trust the dependency, will it still be there in a year, can we get fixes merged upstream), but I think there's significant value in driving down the cost of code sketches involving unfamiliar libraries and tools.

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

#449

Post by gabrielhidasy »

dominotw wrote: post #436
ChicagoDave wrote: post #361

Earlier quoted context omitted.

I’m doing it because as a DDD adherent, I’ve been building software that way for 15 years without GenAI and now with GenAI I can do it faster. You can’t play whack-a-mole with GenAI. You have to start from well-known principles and watch everything it produces. Every module or bounded context has to have its own invariants. You can’t fully automate software engineering with GenAI. It seems the vast majority of GenAI…

[flagged]

That's not the point, the point is they can generate pretty good code, and do that most of the time, so ask them to generate the code, review it as you would review a more junior teammate or an opensource collaboration from an unknown source, and take advantage of their speed to test everything.

You can't make a great vibe-coded thing that you couldn't make yourself, but you can get pretty much the same code you would have made in a fraction of the time.

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

#450

Post by abustamam »

topaz0 wrote: post #434
abustamam wrote: post #423

Earlier quoted context omitted.

I think you're missing the point of the commenter. A third party library is a new dependency. Since there's new vulnerabilities almost every week in the npm ecosystem, if you can do something without a third party, it's probably better. With LLM driven code you can generate code once, and then if anything is shitty about it you can always manually update it yourself without the need of an LLM. It's a dependency of co…

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.

Post reply on HN