Hacker News Reader

First I wasn't sure if technical debt still matters but I think it absolutely does. As long as I'm involved in the planning phase at all, the complexity of the code base still bubbles up to me. Claude will say: ok we can build that but how should we handle legacy code paths A,B,C,D that no one needs and I wasn't even aware existed.

even better when "legacy" means something Claude added without explicit instruction, maybe in the same session, for edge cases that can't happen

I think the current LLMs benefit from the modular design, but also from things humans would hate: arbitrary uniqueness. If you have three services, your main() function better just be a single call to a unique function else they're going to slowly lose track of which one you're talking about.

I broke apart a 1k length script into functional components because the local AI just couldn't figure out where edits landed. But once that was complete, it had no problem tweaking features in those scopes.

I think the real TAM is local coding models starting around 32GB sometime in 2027. Obviously, Capitalism gets to decide what we're blessed with but knowing that you can get Qwen3.8-Flash-Next running at around 40GB VRAM with SSD offloading means data centers are either going to become way more efficient, or they're going to die on the vine.

> Then again, I'm stuck with decades of legacy code and systems that noone understands that were introduced by humans...

But that's despite many efforts made to keep that code understandable, maybe even documented. If now that's not even tried the results will be a thousand times worse - and the dependency on the LLM absolute.

The only time I ever few like I need agent swarms is when I am doing mechanical whole-codebase migrations/verification.

The LLMs are so much faster than I can check the output anyway. If I have a long-running task I just work on another one in parallel while I wait on the first one.

> Models will often just ignore your process instructions

Many are using a sub, which means (AFAIK) you can't override the system prompt:

https://platform.claude.com/docs/en/release-notes/system-pro...

I imagine it's harder to follow relevant instructions once they are buried in a mass of otherwise irrelevant, but undifferentiated instructions.

> many devs don't see any speed advantage for complex work

Swarms don't necessarily need to be about speed. You can get a lot of value from small swarms doing things like analysis or verification work.

It's also a way to make the system more reliable in terms of doing the work!

But I think many people are still missing the point about how AI systems should learn. Arguably, with people we tend to hire and "grow" in-house experts as opposed to outsourcing everything, so why shouldn't we build a system that learns from experience, from its failures?

At first I thought the key was in skills, but skills are static, while you need a continuously learning system

Agreed on all counts. Once you set up an alignment and verification system, you really see how many gaps are present in initial code generation, regardless of what might have been specified.

Even if you have a basic skill-based workflow, a rudimentary retrospective > process improvements artifact that can be ingested on the next run can have a positive impact.

The advantage is not so with speed, but with autonomity and doing MORE work. The benefits are clear when you stop micromanage your agents and start scaling their work

> The code is 'correct', but it's just not what any of us would have written".

I'd fine with not what we'd have written ... if it worked.

Trying ChatGPT for a simple one page of HTML JS having draggables, I said clamp touch point to visible viewpoint. Fine. Then I said add 3x drag gain. It put that after the clamp, whereas anyone/thing having an ounce of intelligence would have urecognised the only possible purpose of the clamp and so put the gain before.

This is fundamentally why we cannot trust stochastic parrots to code. They lack the human's understanding of purpose which cannot be abstracted from the code yet is essential for success.

And then what? You unambiguously told it what you wanted, it did that, and you continued on using it and saving time?

> You unambiguously told it what you wanted, it did that

Try rereading the report please.

Brother what “report” are you talking about? Do you mean your comment? The one with your story that ended before the resolution of your problem was reached?