Live data from Hacker News

The Coming Loop

lucumr.pocoo.org

231–240 of 322 posts

Re: The Coming Loop

#231
I think a lot of people here have either not read the article fully or are misapprehending it.

Neither this author nor most other sane people I know claim that the code or architecture these "loops" produce is great. In fact, the author explains how it is not great. His point is rather, that we'll increasingly see a world in which code quality and maintainability by humans will cease to matter for a lot of codebases.

There might be many software companies in the future which successfully sell software products which were created without a single software developer being involved in its development or maintenance. The code might be bloated and bad - but it doesn't matter because machines can still create and maintain it cheaper and faster than people can.

I already see this happening at a small scale at the place where I work. Product managers with zero coding ability are attempting to create entire new product features on their own using Claude or Codex. We do not let them merge this stuff unsupervised but in some corners and in new repositories they are publishing stuff that they have barely spoken about with a developer. They are just doing it. We'll see more of that.

Re: The Coming Loop

#233

Earlier quoted context omitted.

When someone is expected to be wizened and does not have the knowledge to keep up with the needs of those around them, they in turn become Shamanistic in their practice. The speed of improvement on these models has been incredible and has outpaced the learning speed of humans and put many experts into these Shamanistic roles. I think the operative means of addressing this is to recognize that we can only learn so qui…

Algorithms and data that emulate responses aren't smart. A 5 year old knows if you want to wash your car, you need to take it to the car wash.

referring to John Woolridge's recent talk? "the car wash is only 200 feet away, should I drive or walk?"

His slide showed Opus 4.6 saying "walk". I couldn't get 4.6 to do that.

Re: The Coming Loop

#234
The author is spot on about the paradigm change of software as a lifeform. Living things provide us with genuine interactions and experiences of learning and growing, without forcing us to understand the code - You can learn to work with animals and plants without understanding their genetics at all. I believe this is how our relationship with software must develop, and in order to get there, we'll need to learn to design and develop software in a completely new way. I've been testing this hypothesis in my spare time, hacking together a server-browser system I call Mycelium. It's a bit like OpenClaw, except you can use it to create private local Webs, and print custom 2D Electron browsers to view and work in these webs.

Re: The Coming Loop

#235
> the code it produces is slop, but that’s more the fault of the model than the harness not being a good judge on if a step in the workflow resulted in a net improvement or completion.

I don’t know. I’ve invested heavily in building internal tools that scaffold code and lint the filled in architecture/code design. That with a ratchet pattern, to allow for new rules that have errors across the existing code base, but to asymptotically fix them, is working pretty well.

Example - all modules have tightly scoped design primitives (I’m using hexagonal architecture for the backend, for example). And all code has BDD tests, which is what I spend much of my time reviewing, since cases written in human sentences is easier than looking at so many files of code.

There is a relentless upkeep to draft rules that respond to the workarounds the agents come up with to adhere to the design I want, but it’s slowly approaching perfect. What has helped here tremendously is I use hooks to llm as a judge the decisions the llms make, and then have them review/raise the questionable ones after a first pass is completed. In general, this is snuffing out the slop effectively.

All to say, someone asked me recently what model I prefer. In this approach, the model doesn’t really matter to me because the code is consistently what I want. I’ll choose a model because it has better mcp speed (codex), or a more thorough scope (Claude code).

Where this IS true is when we’re building a net new pattern. The agents are not great at it. BUT most code can fit into the few patterns I’ve created, and what can’t you lock down a new pattern to enforce over a couple iterations of it. Almost everything, at least in SaaS, follows a template.

Re: The Coming Loop

#236
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 nuclear plans. Research is also like this; "research-quality" code was famously terrible, even before the age of AI.

The other kind of work is taste-driven work. People think that, when they're adding a feature to a large codebase, their goal is to add that feature, but that is often not the case. Keeping the codebase amenable to future changes is often far, far more important than this specific feature, and that requires taste. Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.

Re: The Coming Loop

#237

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…

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!

One thesis I am developing is that LLMs have given us a new kind of tradeoff. We can use the intelligence and tremendous speed up that mechanically pumping out basic CRUD code has given and we can either deliver more features or deliver higher quality.

What that means to me is that there is a balance. My belief is that we have to take some of the new power and put it towards quality rather than spend it all on speed.

Re: The Coming Loop

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

Re: The Coming Loop

#239

The author is spot on about the paradigm change of software as a lifeform. Living things provide us with genuine interactions and experiences of learning and growing, without forcing us to understand the code - You can learn to work with animals and plants without understanding their genetics at all. I believe this is how our relationship with software must develop, and in order to get there, we'll need to learn to d…

Interesting, could you share a link? (Your submissions appear to have been nuked.)

Edit: woah!

https://www.youtube.com/watch?v=NGgve4L2zY4

Re: The Coming Loop

#240
post #239

The author is spot on about the paradigm change of software as a lifeform. Living things provide us with genuine interactions and experiences of learning and growing, without forcing us to understand the code - You can learn to work with animals and plants without understanding their genetics at all. I believe this is how our relationship with software must develop, and in order to get there, we'll need to learn to d…

Interesting, could you share a link? (Your submissions appear to have been nuked.) Edit: woah! https://www.youtube.com/watch?v=NGgve4L2zY4

Yes, you found it. Blancs is the browser prototype for non-technical users, but the full system, Mycelium, I'm currently working on towards demos and distribution. I'll be sure to update the YT channel, if you want to follow the progress. I'm also on Twitter @livingsoft_
Post reply on HN