Live data from Hacker News

The Coming Loop

lucumr.pocoo.org

271–280 of 322 posts

Re: The Coming Loop

#271
post #243

My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now. If I can get a clear understanding of what I want to build, communicate that to Claude Code in planning mode with the goal to write an actionable spec (not code, plan to write the spec) then I tend to get very good results once the agent goes to implement. But this strategy, while effective, puts a big load on me to write…

Why can't Claude write the spec?

the bottleneck is still you knowing what the right thing is, and where the odd edges are.

either you tell claude or it tells you/is probably wrong

but, you can still be more agile i think, and just make the thing and see of it solves the problem or not, and if not, build something else

Re: The Coming Loop

#272
post #248

> We may create codebases that are not merely hard to maintain by humans, but that assume machine participation as part of their maintenance model... People more and more merge code they cannot fully explain. People lose their ability to create issue reports or discuss things in chat, without augmenting or rephrasing their messages with the context provided by a clanker. Too many people increasingly rely on a machine…

And this code is often full of security vulnerabilities. It's just hacks on top of hacks on top of hacks. You end up with 100K lines of code full of weird fallbacks, doing something which could have been done more reliably with just 1K lines of code. I think author's comment about preferring systems which make invalid edge cases impossible rather than implementing fallbacks is hugely important. With the fallback appr…

Ensure you check every PR with opens4.8 or fable - they catch every security issue upfront.

Re: The Coming Loop

#273
post #238

This ties into something I have been saying for months: LLMs are great at finishing tasks, but bad at aesthetics and taste. There are two kinds of work: One is goal-driven work, where we have a goal to achieve, and we care very little about how we get there. Security is a perfect example; if you want to exploit a system, you rarely care about how beautiful the exploit is, all you want is access to those super secret…

> Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability. Many orgs are quickly moving to a world where code quality and maintainability are not a priority, at all. If claude is just going to write the code, does it matter "maintainable" or "quality" it is? No. It just matters if it works, and if its fast, is how the perspective goes.

The irony is that coding agents are, if anything, more affected by technical debt than human maintainers (who at least occasionally have the taste to rise above the level of the current codebase they're working in). The impact on productivity may be initially delayed, but it's going to compound faster.

Re: The Coming Loop

#275

Earlier quoted context omitted.

This is exactly the way it should be! This is great! This is the most important part of engineering of systems that has been minimized over the past two decades in the rush to build. Now that the building is more automated, the specifications and system design can take the important lead again. Engineering and quality might be back!

Joke’s on you, Claude is writing that too

Why's it a joke, looks like quality and good engineering will be faster for what we build and maintain.

Re: The Coming Loop

#276
post #167

For some reason pro-ai blog posts feel like paid ads, I might be wrong.

Armin is very nuanced and balanced. He spells out clearly in the blog post that bad parts of AI

I'm saying if you are a writer and this is what you write about, you better get paid.

Re: The Coming Loop

#277

Earlier quoted context omitted.

I think we have to wait and see if long term maintainability will be any different from human coded software. Every single long surviving human written codebase I have worked with, has significant amounts of tech debt and large pieces had to be rewritten from time to time. This is of course anecdotal and I'm sure clean and elegant old codebases exist somewhere.

The worse designed the code, the more frequently it has to be re-factored. I've worked on long running projects which required essentially no refactoring when implementing new features and I've also worked on projects which had to be re-written multiple times to accommodate requirement changes.

In most half-decent codebases, including LLM generated ones, adding new features almost never requires a refactoring in my experience. It is almost always when you are fixing bugs, improving performance or changing core behavior.

Re: The Coming Loop

#278
Reading the comments here, I'm struck by how many people seem to view code quality as an optional thing. It's almost as if software can function correctly without it. But it can't. Code quality is not a nice-to-have, it's a must-have. For any moderately-complex offering. There's a certain level of complexity that you can never reach without a well designed codebase. Cannot reach no matter how many humans or AI agents you throw at the problem.

The idea that it's a 'nice-to-have' is an illusion. It's like if you borrowed a lot of money to fund your startup and you still have some cash in the bank; at that point, a viable business model might seem like a 'nice to have'.

It's only when the lender comes knocking and you don't have enough money to pay them that a viable business model suddenly becomes a 'must-have'.

Re: The Coming Loop

#279
post #248

> We may create codebases that are not merely hard to maintain by humans, but that assume machine participation as part of their maintenance model... People more and more merge code they cannot fully explain. People lose their ability to create issue reports or discuss things in chat, without augmenting or rephrasing their messages with the context provided by a clanker. Too many people increasingly rely on a machine…

What's your product? I'm dying to see how the product developed to 100x human standards by agent swarms is. Must be amazing.

Re: The Coming Loop

#280

Earlier quoted context omitted.

And this code is often full of security vulnerabilities. It's just hacks on top of hacks on top of hacks. You end up with 100K lines of code full of weird fallbacks, doing something which could have been done more reliably with just 1K lines of code. I think author's comment about preferring systems which make invalid edge cases impossible rather than implementing fallbacks is hugely important. With the fallback appr…

Ensure you check every PR with opens4.8 or fable - they catch every security issue upfront.

This isn't going to work because the LLM doesn't have enough context. Many security issues involve a failure mode which cuts across multiple parts of the code. A PR which seems perfectly valid on its own may be the missing piece which opens up a vulnerability. Each component may be fine on its own, but brought together, the system is vulnerable.

Think of a machine with interlocking gears; each gear may itself be perfect and may fit perfectly with each other, but then if a tiny pebble comes between them, the entire machine breaks. Maybe the problem here is that the final gear was too close to the ground and would catch stray pebbles kicked up by the wheel in front of it... The LLM couldn't know this unless it understood the full context in which the change occurred; not only the code, but the environment itself.

In a poorly designed codebase with hundreds of thousands of lines of code, it's impossible to have the full context of the code even. The architecture would lack proper separation of concerns to allow one to effectively establish an appropriate defense perimeter. In a poorly designed codebase, every part of the code can harbor a vulnerability.

It's like; if you don't have a proper access control layer which is automatically and declaratively enforced for all your endpoints, every endpoint will have to enforce security restrictions on their own; duplicating similar-looking code over and over. If one endpoint out of 1000 incorrectly enforces a security restriction, that could be a critical vulnerability.

Post reply on HN