Remix.run Logo
▲ Resisting Cognitive Surrender(knlb.dev)
73 points by knlb 2 days ago | 29 comments
▲hypfer 5 minutes ago | parent | next [-]

The most difficult part of LLMs and agents seems to be - surprisingly - humans.

Specifically, humans and their dysfunctions. Their fragility. Their ego tied to stuff.

This is an excellent post/reflection on the topic of solo LLM use. The only gap I see is that it assumes that one works on something alone and not in a team. Though, that might be a different essay in itself.

Edit: Turns out that footnote 3 actually mentions that already. Nice. Good post

▲tra3 2 hours ago | parent | prev | next [-]

Great post. I particularly like the 4 column pr view idea. I’ve built something similar to review speckit specs. The scaffolding to ensure that code actually works makes sense too.

There’s one thing that’s bothering me though — all of these have us consuming what LLMs produce. I learned and internalized how things worked by building systems. At least within the constraints of the abstractions I was using. This makes me think of TikTok and shorts. Everybody is just watching. Maybe that’s not charitable though. Maybe the abstraction has now changed from an “os/gui/event loop” to “llm” and the rest is just accidental complexity.

▲skybrian 14 minutes ago | parent | prev | next [-]

Making a quick prototype is probably the best way to find out if an idea is worth keeping. Vibe-coding it and then throwing it away seems like a good way to go?

▲knlb 9 minutes ago | parent [-]

Yeah, definitely. Also at times I've vibecoded successive iterations with better designs after seeing where the first ones collapsed -- the agents do a good job with a template and need much less prompting for the successive versions.

▲gus_massa 18 hours ago | parent | prev | next [-]

>> A more serious irony is that the automatic control system has been put in place because it can do the job better than the operator, yet the operator is being asked to monitor that it is working effectively.

Automatic control is good for standard case, and the expected errors. For weird cases, for now humans are better to detect them and press the big red button.

▲esikich an hour ago | parent | next [-]

It's funny that I'm reading this while rewatching Chernobyl. Never underestimate the ability of bureaucracy to completely fuck things up.

▲mitthrowaway2 an hour ago | parent | next [-]

The computer doesn't know we're running a test!

▲oliculipolicula an hour ago | parent | prev [-]

Jumping into article, I assumed that the author was going to describe how he enjoys, by drawing it out as far as he can,

  the process of surrendering to the machine god..
(Not the machina diabol, as it sadly turned out to be, though some BDSM zealots might disagree.. the things that bureaucracy does to us are mild in comparison? )

But.. we do monitor whether our prayers are effective .. right? Is that a smitable offense?

After that disappointment, I too was "curious": was the author going to talk about "curiosity", that magic virtue that we hackers believe, lifts design into the divine (but more often than not kills the pussy)

▲cowlevel 4 hours ago | parent | prev [-]

Except experience shows they aren't. Experience shows that when humans are just pressing "ok" 99% of the time they'll press it 100% of the time and completely miss the other cases.

▲ashishmax31 an hour ago | parent | prev | next [-]

i sometimes wonder how all carpenters or music producers in the world would react if tomorrow a magic box arrives where they type-in/dictate what they want and voila... out comes a table/composition.. Will the worlds music producers and carpenters just "accept" this new magic genie? I would hope they wont. Yet here we are as software engineers...ready to surrender our craft to mere "prompts" with reckless abandon.

▲usrme an hour ago | parent | next [-]

For musicians there already exists something called Suno: https://suno.com/

▲tuvix 17 minutes ago | parent [-]

That’s not music

▲hansonkd 29 minutes ago | parent | prev [-]

I mean more or less to an extent if you expand by what you mean by "out comes". With Amazon, a carpenter can type in any furniture he wants and have it arrive in a matter of hours. Almost equally as magically as well as disruptive. People still use carpenters to make tables, but for the majority, the ease of same-day delivery and cheaper prices are worth it for a sacrifice in personalization and character.

▲ashishmax31 14 minutes ago | parent [-]

>With Amazon, a carpenter can type in any furniture he wants and have it arrive in a matter of hours. Sure but that doesnt require him to be a carpenter though right? Anybody could do that.

▲lioeters 3 hours ago | parent | prev | next [-]

"Yup, looks good to me!" said the human reviewing thousands of lines of generated code everyday.

This has become common now, and I've seen it ruin large projects until nobody understands the codebase full of verbose nonsensical code and comments. It becomes impossible to further develop the project without AI. Contributors not using AI for any reason are all leaving because no one enjoys working with mindless robots (and humans) as colleagues. It's demeaning and devaluing their labor and humanity. They're not getting "left behind", they are leaving the madness of crowds behind.

> ..the possibility of runaway dynamics: once a critical threshold is crossed, small increases in adoption can trigger rapid population-level shifts toward *persistent dependence, with abrupt losses in cognitive competence*.

We can all see it happening. As this technology permeates society, the challenge to maintain control, coherence, and quality will become greater and ever more serious - for example, AI in healthcare, military, management and governance.

▲cowlevel 2 hours ago | parent | next [-]

Even if the human's judgement is correct in every LGTM, there's a bias towards merging. Each merge that adds a feature but degrades understandability 1% will be merged. It won't be held back until it improves it by 5% instead. After 100 merges you have degraded understandability 100% even though nobody made an error.

▲californical an hour ago | parent | next [-]

You’re completely right that nobody is stopping a PR that just ever so slightly decreases understandability of something. It may not even be obvious to the reviewer that it’s slightly less understandable overall… Doubly so if they’re just skimming due to the volume, and tripley so if they’re having agents do the most of the review, which lets the human reviewer’s guard down.

But before LLMs, it didn’t matter because on a good team you’d have a balance where maybe some PRs added complexity and some simplified it. Sometimes people would include a small related cleanup or refactor in a PR for code around what they were doing if they noticed complexity. That has become far less common, I think.

I know it’s not your point, but a 1% decrease 100 times is 0.99^100 = 0.366 which is a 63.4% decrease in understandability. Just throwing that out there

▲lioeters 41 minutes ago | parent [-]

Glad to see the math corrected, the sloppy calculation was bothering me also.

▲unpleasurable an hour ago | parent | prev [-]

I think it's about 63%

▲Buttons840 34 minutes ago | parent | prev | next [-]

I hope there's still value to be found in a bunch of developers standing around a whiteboard and talking, and I think this scenario is where their ability and understanding really shows these days.

If we don't value that though--if we don't value understanding the system and just thinking through problems as a group--then let's stop pretending and just not do code reviews. Probably nobody cares and just types "LGTM" after having their own LLM do a spot check to cover their ass.

It's really easy to push developers to stop caring. If management says "go fast fast fast, use those LLMs!", then developers can't keep up, get frustrated, stop understanding the system, and at that point they're just there to collect a paycheck before society collapses. Or, if management is making dumb decisions all the time, same thing.

Hopefully as implementing ideas takes less and less time and resources, smart people who actually care will start building things with other smart people who care.

▲nurettin an hour ago | parent | prev [-]

To be fair, models are more accurate than how they were earlier this year. In march I was still frustrated and was writing my own event loops because the model simply wasn't built for it. By January I was still hand checking statistical outputs to make sure it wasn't making any errors, and it was. After august it was pretty much over. There were no stats errors, code generated was shit but it could do what is asked. Instruction following is still a problem, and I sometimes catch silly things in the scrolling diffs, but it has been much easier since then.

▲totetsu 2 hours ago | parent | prev | next [-]

I am often thinking recently of the littel loop diagrams from the "The Capability Trap" paper. We need to keep a loop reinvesting into our own Human capability in anything we're doing.

▲sjdh76 2 hours ago | parent | prev | next [-]

[dead]

▲jdw64 3 hours ago | parent | prev | next [-]

[dead]

▲augment_me 2 hours ago | parent | prev [-]

This is copium that is gone with the wind when the models perform up to the level of standard that the user requires. I'll give the author 6 months before they feel like its okay to just send it.

Karpathy had the same trajectory. Primeagean had the same trajectory. I think in the end everyone except for Jonathan Blow will have the same trajectory

▲knlb 7 minutes ago | parent | next [-]

Writing is hard, but what I was trying to say is that it's okay to just send it as long as you're doing it consciously and intentionally (and I do that frequently enough); but if it's not an explicit choice that can be problematic.

▲willtemperley 2 hours ago | parent | prev | next [-]

If you don't understand the code, how can you know if it's good enough?

I guess you could ask the model. "Yes well done, you're a visionary software engineer".

▲augment_me 4 minutes ago | parent [-]

Who cares if it's good enough? Send the product, if people use it, it's good enough. If not, let users debut it and give "feedback", problem solved. You then advocate to these users, make them feel important, make them your cash cows, rinse and repeat.

Every team I have been on have been more successful when they gave up on the product ideals and just ensured that the customers were hooked and satisfied.

▲EA-3167 2 hours ago | parent | prev [-]

In the narrow case of your profession perhaps. Beyond the slipshod world of most software is a universe of standards, licenses and liability.

The lawyers and judges who trusted an ML system to be up to snuff are currently pounding sand.