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

251–260 of 322 posts

Re: The Coming Loop

#251

Post by fc417fc802 »

jazzypants wrote: post #10
JodieBenitez wrote: post #3

> For now I have not moved past the point of comprehension being important to me. Ah ! This is me too... at least for what I have to ship at work. Not so much for my toy/weekend projects. But it turns out agents are also good at explaining.

I think it's insane to suggest that software developers should ever get to the point where they don't even comprehend their code. Before someone else says it, no I don't read the assembly code that is produced by my compilers. However, I can generally predict what kind of assembly will be produced, and the result is deterministic unlike LLMs. It seems like most vibe coders scoff at the idea of even looking at the cod…

> the result is deterministic

Well the result generally matches the input specification, something that an LLM is much less consistent about. I don't think it's deterministic in the sense of being able to predict a priori what the compiler will generate for a novel and nontrivial code block.

Re: The Coming Loop

#252

Post by wahnfrieden »

AndrewKemendo wrote: post #214
wahnfrieden wrote: post #186

Earlier quoted context omitted.

Why is HN interested in management and team process discussion but allergic to similar topics on how to manage agents? It’s like saying why discuss these team workflows when it’s just devs writing code. Or why use any jargon to describe workflows when it's just devs writing code.

Because like every other large social group it’s actually a collection of dozens of subgroups that have an overlapping interest You’ll see those subgroups come out in threads like this and you’ll see other subgroups come out in different threads there is no singular version of hacker news that is always existing it is a collection of sentiments that from time to time align interests around specific topics

Sure. Let me rephrase - why do these particular posters and their upvoters …

Re: The Coming Loop

#253

Post by hatthew »

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…

This matches my experience coding, and the expectations I (and many other) have been voicing for years about why AI is still a ways away from solving coding. The hard part of programming isn't pressing the keys to put code into a file, it's understanding the problem and coming up with a good, clean, extensible solution. AI is great at making ok solutions that technically work, but pretty bad at having a good vision for a solution. AI is still very useful for bouncing ideas off of and exploring to create a better understanding, but writing a good spec for an LLM to implement isn't much easier than just writing the code yourself.

Re: The Coming Loop

#254

Post by jongjong »

One thing that I'm certain of, is that there are always costs to writing more lines than what is necessary to solve a specific problem.

I've experienced this before AI, and I've experienced this, magnified, with AI.

For a well-designed project written by hand, you will work faster writing the code for new features by hand than the same project written with AI from scratch, using AI to write the new features.

But... If you have a well designed, human-written codebase, you will be faster if you generate the code for new features using AI than if you do it by hand... And you can maintain that speed for long periods of time if you use fine-grained prompts. What matters most is the quality of the codebase.

You can achieve the same degree of maintainability using AI from the beginning but you would have to make fine-grained prompts.

The gap is about making good engineering decisions. It just so happens that the value of good decisions compounds over time.

Re: The Coming Loop

#255

Post by fwip »

mmillin wrote: post #136
handoflixue wrote: post #113

Earlier quoted context omitted.

How impossible are we talking? I tend to be a fairly defensive programmer - maybe nothing currently sends this function a negative value, but how hard is it for a future code change to alter that assumption? I always figured a clear error was best. It lets even someone unfamiliar with the code know what assumptions are being made about the valid range of inputs, so they don't have to consider impossible outliers.

Obviously it isn’t totally impossible, but it becomes challenging to know if it’s required or not. It’s hardest when it isn’t just throwing an error but instead defaulting to something only half-sensible. For example replacing a negative number with 0 or overflowing rather than panicking. When it comes to assumptions about the input, ideally model them in the type system. If you can’t, explicit checks and throws are…

I hate the "pick defaults out of a hat" approach that LLMs seem to take. I suspect this behavior may be a result of reenforcement learning on coding challenges - making the code worse by throwing in these assumptions (which in turn become part of your documented API) may get you an extra half percentage point on the code challenges.

Re: The Coming Loop

#256

Post by throwaway7783 »

jr3592 wrote: post #238
miki123211 wrote: post #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…

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

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.

Re: The Coming Loop

#257

Post by cheevly »

mlsu wrote: post #225
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…

"Writing specs" is the essential complexity of programming. What you're saying is that there's no silver bullet. Agents or no agents, punchcards or interpreters, programming is programming at the end of the day.

I'm pretty sure programmers weren't the ones writing the specs in the past...

Re: The Coming Loop

#258

Post by devin »

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

I'll help if I can.

Re: The Coming Loop

#259

Post by jongjong »

gavinh wrote: 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 approach; you end up implementing fallback on top of fallback on top of fallback... Each fallback seems to increase the amount of code exponentially and somehow it always creates new problems. This should almost be a 'General law of system design.'

Fallbacks reduce the risk of failure but make failures more complicated and harmful when they do happen.

As a software engineer, like the new coding environment which is being created by AI.

Big tech companies have created infinite work for me. The human developer has become a critical component of code execution. The human needs to always be present to handle the nearly infinite number of difficult unhandled exception cases which are guaranteed to occur from time to time.

The software engineer is no longer like a laborer, but more like a security guard who sits at his desk drinking coffee most of the time and only steps in on rare occasions when something goes wrong.

Re: The Coming Loop

#260

Post by [deleted] »

AndrewKemendo wrote: post #201
weego wrote: post #160

What does any of that mean in practice? it's just rambling about abstract concepts that seem to be designed to hint at a bigger picture, when it's just getting AI to write code for you. Is this where it's going? Having to mystify our roles so it seems like we're still the thought leaders when actually we're just becoming pseudo-teachers that try and herd our group of AI idiots to the right conclusion for us so we don…

I’m sorry but this response is just absolutely ridiculous and is not giving anything near the respect to the author that you should have. You’re just rambling and ranting about philosophical things and have basically nothing to say about the technical or engineering points that the author wrote. This is a entirely emotional appeal and doesn’t actually engage the author where the author is engaging in the audience. If…

[deleted]
Post reply on HN