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

The human-in-the-loop is tired

pydantic.dev

Post reply on HN
Print view View original

71–80 of 221 posts

Re: The human-in-the-loop is tired

#71

Post by BugsJustFindMe »

bluefirebrand wrote: post #70
BugsJustFindMe wrote: post #62

Earlier quoted context omitted.

Name one time in all of history when increased productivity translated to workers working less. I'll wait.

Every single worker that has been laid off due to "increased AI productivity" is working less As a broad historical trend? Maybe not But fewer people working, right now? Absolutely

> Every single worker that has been laid off due to "increased AI productivity" is working less

This isn't a useful definition of working less in the thread context and is not the kind of working less that I meant.

If it helps, imagine that I had asked for "when increased productivity translated to workers personally reaping the benefits of the increased productivity by being able to thrive while doing less instead of either being laid off or just being expected to do more".

Re: The human-in-the-loop is tired

#72

Post by georgemcbay »

verdverm wrote: post #39
appplication wrote: post #32

> Here's a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated…

Maybe it's different between professional and personal projects, but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent. I'm able to focus on a single project for a month and have something pretty good by the end. Doing rewrites to clean up and reorganize has never been easier, so I get to see and feel more of the design space in action. The can be…

> but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent.

Features might be easier to create, but I rarely ever get the feeling of I did that anymore from writing software.

"I told the LLM to do that" is different and far less satisfying for me.

Re: The human-in-the-loop is tired

#75

Post by nibbleyou »

georgemcbay wrote: post #72
verdverm wrote: post #39

Earlier quoted context omitted.

Maybe it's different between professional and personal projects, but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent. I'm able to focus on a single project for a month and have something pretty good by the end. Doing rewrites to clean up and reorganize has never been easier, so I get to see and feel more of the design space in action. The can be…

> but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent. Features might be easier to create, but I rarely ever get the feeling of I did that anymore from writing software. "I told the LLM to do that" is different and far less satisfying for me.

I used to get overjoyed and would tell my partner how amazing programmer I am every time I built something that felt difficult at the beginning.

Now for every problem I know Claude/Codex will do it, and they do. I just don't get that feeling on finishing 10 features now.

Re: The human-in-the-loop is tired

#76

Post by skydhash »

spiderxxxx wrote: post #57
ptrl600 wrote: post #47

I don't understand how people are using AI. A lot of the time, what I want to build, doesn't have a succinct English sentence to describe it. If I describe the user requirement I just get a Fisher-Price toy thing that kind of ignores most of the adjectives and adverbs in my requirement. So I'd have to prompt with a big list of specs and algorithms for the specific thing I want. Then what's the point?

I've not had that problem, but I have 35 years of programming experience, so I can describe exactly what I want. Maybe that's the difference. It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to star…

> It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want.

That sounds like programming with extra steps.

Here's my No-AI workflow: I read the requirements and devise pretty much instantly have a solution. I Check the web/manuals/docs/source code for missing information so I can refine the solution from a hunch to an implementation plan. This can be pretty fast or can be the slowest part. I start coding, building a small subset that work and iteratively adding on top, feeling the design as I go, refactoring if necessary. Then after testing, I send it to review.

The "finding information" part is the most important one as accuracy is paramount. And for most AI workflows, it seems that's very much an afterthought.

The "coding" part is the relaxing one, except for a few moments where some nuggets of information are lies or misleading. Again, there's no practice to catch those in AI workflows.

If you have a good testing methodology in place, the last part can be fast tracked, where you mostly scanning for bad practices and modifications to important areas. Again in AI workflows, you see that either they rely on preexisting test suites (the big rewrites), or mostly trust the generated suite with no evidence that it's actually suitable.

The questions I have are: How do you ensure the accuracy of the software's model of the domain? And What do you do to retain the knowledge of that model (as in you have a good intuition of the current behavior of the software or at least can easily locate the code responsible)?

Re: The human-in-the-loop is tired

#77

Post by Terr_ »

zem wrote: post #48
Terr_ wrote: post #40

Earlier quoted context omitted.

Unfortunately the incremental approach doesn't help when it comes to the review step by another user, they've still gotta take it as a lump and apply fresh eyes on it.

not if you break your work into a stack of PRs, which is the standard practice for my team at work. you just keep adding PRs to the top of the stack while the reviewer proceeds from the bottom. if something changes you propagate the change up the stack, which LLMs are also pretty good at doing.

I'm all in favor of stacking PR's to break reviews into chunks, but if they're being used to explain the reasoning or correctness of the final code to a reviewer, then that's a process-smell. It's like "teaching to the test", a shortcut that will hurt in the long run.

We want to end up with code that makes sense generally, to whomever is editing or or debugging it in the future. That next-person usually won't (or shouldn't need to) mine the git history to understand the current project in front of them.

Re: The human-in-the-loop is tired

#78

Post by thinkindie »

appplication wrote: post #32

> Here's a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated…

I think it all depends on your personal driver: personally I rather see a product I built in whatever way used by ever growing number of people because they find it useful. It means that the time I spent working on that helped other people solving a problem (hopefully).

That’s why a was always keen on cutting some corners when and where necessary in order to think about the user first and the code beauty second.

Of course I appreciate well structured and maintainable code but you can always strike a balance, even with LLMs assisted coding sessions.

Re: The human-in-the-loop is tired

#79

Post by viccis »

>When you've earned your opinions about architecture and code quality the hard way, they feel less like textbook rules and more like scar tissue.

I don't think it's common for any compsci programs to (competently at least) teach architecture and code quality.

>The honest truth is that in the last few months, there have been days when I have spent close to two full days writing a plan for an LLM to execute: obsessively clarifying, specifying, re-specifying, only to have it still do something inexplicably stupid.

It's because LLMs are actually taking us back in time to the pre-agile days where there was a career path (architect) that involved almost nothing but painstaking spec authoring and endless meetings to review and course correct the work of the engineers whose job was to implement what you designed as closely as possible. I have to emphasize that this was a different career path than what we think of as a senior engineer today. Not everyone likes this.

Re: The human-in-the-loop is tired

#80

Post by zem »

Terr_ wrote: post #77
zem wrote: post #48

Earlier quoted context omitted.

not if you break your work into a stack of PRs, which is the standard practice for my team at work. you just keep adding PRs to the top of the stack while the reviewer proceeds from the bottom. if something changes you propagate the change up the stack, which LLMs are also pretty good at doing.

I'm all in favor of stacking PR's to break reviews into chunks, but if they're being used to explain the reasoning or correctness of the final code to a reviewer, then that's a process-smell. It's like "teaching to the test", a shortcut that will hurt in the long run. We want to end up with code that makes sense generally , to whomever is editing or or debugging it in the future. That next-person usually won't (or sh…

i'm not sure i understand your objection. here's a concrete example of what i'm talking about:say i want to add a new feature to my code analyser, exception-aware code analysis. it ends up being 2000 lines worth of diffs, touching a bunch of files, and definitely too much to review in one go. so what i do is, first i write a doc file describing the feature, to show what i'm working towards. then i write a small commit, "add a new `exception_handlers` member to the context struct, and a small class containing its datatype", and upload it for review. why is this new member needed? see the plan doc pointed to by the commit message! now i needn't wait for it to be reviewed, i can stack another commit on top of it, "populate the exception_handlers info by walking the AST". it depends on the exception_handlers member being in the struct, but, crucially, it doesn't depend on that code being merged in, because it's there in the stack below this commit. i can keep adding things like "inherit exception_handlers when analysing function calls", "validate that all explicitly raised exceptions are caught by an exception handler in the current scope", etc - there are a lot of moving parts to analyse exception handling, but each commit is fairly small, does one precise thing, and is therefore relatively easy to review.

when the stack is complete and all the commits are uploaded to wherever (we use phabricator but i'm sure github has an equivalent) for review i just need to sit back (or work on something else) while my reviewer(s) go through each commit and validate that it looks like it does what it says on the tin. as soon as the bottom of the stack gets approved i can merge it in, or i can wait for everything to be reviewed. if there are any changes i do them and rebase the rest of the stack on top of the changed commit, fixing merge conflicts if needed. (it really helps if your tooling supports this workflow, of course!). and when it's all reviewed and merged, the effect is exactly the same as if i'd just sent in a 2000 line combined commit and merged it in - there's no need to go look through the git history for anything, the code will hopefully make sense as part of the codebase.

Post reply on HN