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

The Coming Loop

lucumr.pocoo.org

Post reply on HN
Print view View original

241–250 of 322 posts

Re: The Coming Loop

#241

Post by cyanydeez »

athrowaway3z wrote: post #42
mccoyb wrote: post #14

Loops work when you spend the proper amount of time to understand what you want ahead of time. The prerequisite is clarity — enough clarity that you could write a careful specification that you could hand off to a junior colleague. Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your m…

I had codex write a tool to extract all my pi sessions. (Had to filter out my prompts from the agents talking to subagents). Then I had it analyze the patterns i was making and turned that into the flowchart for the outer guidance-creating-prompt. I didn't have to spend too much time thinking what i wanted. I wanted it to do that. The result is still mixed, and i'm not trusting it with delicate code bases, but for a…

I'm having it build the software to run a raspberry pi and using a local llm and opencode. the display code is fugly, and i regret nothing about how it'll look inside nor do I want to know all the stupid requirements. We improved it'd render speed by finding a github example using numpy. It uses jinja to render user generated templates for the ui.

The only problem it runs into is the bizarre BGRA or RGB or whatever color mapping between screen and frame buffer; it absolutely has no idea what it does when it's right. It also thinks there's some magic around the bits per pixel.

I do not really care, as this thing won't ever be extended beyond display some text and a few graphics. So why do I need it taking up space in my brain.

A lot of little projects are a lot easier now, but corpos who think this will be a magic want to their largesse of badly maintained code are gonna have trouble.

Re: The Coming Loop

#243

Post by andai »

stillpointlab wrote: post #215

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?

Re: The Coming Loop

#244

Post by NichoPaolucci »

Man - what a ride this last year and a half has been. I feel for the juniors or newer developers, who really haven't had time to get into the seat. I don't see a great place to really "settle" into right now, as the field is unfolding rapidly. I wonder what things will look like in 10 years.

If I give an agent a sufficient spec, and it can one shot it, I imagine we won't need to loop, especially if we assume the tech is going to meaningfully improve in the coming years. In 5 years, "make no mistakes" and "add tests + review this code" will be baked into the agent or completely unnecessary, right?

Maybe I'm out of the loop.

Re: The Coming Loop

#245

Post by stillpointlab »

andai wrote: post #243
stillpointlab wrote: post #215

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?

It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, ready for implementation.

All of that thinking, planning, rewriting, etc. takes almost as long as it takes Claude to actually deliver the feature. The big features Claude writes take ~30-45min of uninterrupted coding to deliver (I just checked the last feature was 39m 41s for +1,610/-26). To write that same code would have taken me probably 2 days.

Re: The Coming Loop

#246

Post by throw4847285 »

meowface wrote: post #68
galoisscobi wrote: post #41

As much as I like Claude Code, Boris has done a lot of harm by encouraging software engineering practices that lead to slopware. We have two camps of people at work, the first camp are the agent goes brrr. They don't understand the code they write. They have loops running, agent orchestrators or agent hype du jour. The second camp is people who are inundated with PRs, are holding the line on quality, and just exhaust…

This sums up the dynamic: https://x.com/danhockenmaier/status/2021617680525172840

Maybe I'm being defensive, but the problem with this chart is it assume a binary of good dev/bad dev; AI makes the bad dev worse and the good dev better.

However, I think I once was a pretty good dev, and AI use is slowly turning me into a slop cannon. The temptation to use AI in place of real understanding is too strong.

I'm sure you'll say I was always dead weight, but I just want you to consider the possibility that AI might erode the capacity for good devs to handle discomfort, turning them into bad devs.

Re: The Coming Loop

#247

Post by godelski »

stillpointlab wrote: post #245
andai wrote: post #243

Earlier quoted context omitted.

Why can't Claude write the spec?

It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, re…

How do you expect it to give you what you want if you don't think about it?

Solution spaces for even seemingly simple problems is incredibly large. There's a reason there's a thousand different types of nails and a million types of screw heads. Just making every screw head Phillips (or pick another) doesn't just make things work.

But you need expertise to know these things. They're the issues that are subtle and appear to work but you end up breaking things (often invisibly) and just end up chasing problem after problem. It looks like a new problem but it's rooted in something else.

Re: The Coming Loop

#248

Post by gavinh »

> 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 to summarize or contextualize it. More and more do I encounter people who converse with me through the indirection of an LLM.

I experience this daily now. It find it discouraging and concerning.

I believe we're merging more code we can't fully explain because we are now relying on code review to build the mental model that was previously built by writing code and collaborative technical planning. I don't think code review is fit for this purpose. I do think we can extend code review with structured exercises, informed by pedagogy, that strike a better balance between friction and understanding. (I'm looking for help testing these exercises).

Re: The Coming Loop

#249

Post by godelski »

chairmansteve wrote: post #219
stillpointlab wrote: post #215

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…

> I tend to get very good results How do you define the good result? Does the definition of success include clean, maintainable code? I am finding I need to be in the loop. My code ships to thousands of users, so any issues get amplified.

Last time I saw one of these conversations on HN that was the key question.

What people disagreed on was what's good, or what's even good enough. I don't think that's a new thing but it's becoming far more apparent in the age of AI.

I'll make the claim, a demo is easy to make. But it's far from a minimum viable product. A demo is *maybe* 10% of the work. But for some people I know (and work with) they act like it's 90%.

Re: The Coming Loop

#250

Post by jongjong »

I feel like what should have happened with AI is that teams should have started to put more effort into planning and pre-implementation discussions. Second thing, team leads should have felt more comfortable to reject large Pull Requests.

When I see a large 10k-lines PR, I feel a sense of panic. In a corporate setting, I also feel a kind of pressure to approve; the more work was done, the more pressure there is to approve the PR. This is why I think up-front pre-implementation discussion and alignment has become essential.

You really can't have people going rogue and weaponizing their AI-generated lines to gain control of a project through the duality of brittleness + complexity.

Brittleness + Complexity = Control

Post reply on HN