Live data from Hacker News

It's not empowering to hand off the details

davidnicholaswilliams.com

91–100 of 154 posts

Re: It's not empowering to hand off the details

#91
post #46

This is what a lot of people miss. People think, "Oh we won't need software soon, AI can just build interfaces when we need them" but in reality, the software was built to solve a problem, usually by people invested in solving that problem. Saying "Build me a todo app" will give you the sum of averages, a completely average todo app that works fine, but it isn't great in any measure. The details are what separates th…

I agree with your first part, that software is built to solve a problem. But I think you sort of sidestep what makes AI exciting to non-software people with your second part. The people who are excited about this aren't excited because they can ask for a todo app but because they can solve the problem the todo app was supposed to be soling for them without needing to find and learn a todo app.

AI is the new "excel spreadsheet with ridiculous formulas on top of VB script on top of pivot tables" for the non-programmers. Yes, the AI might not do it efficiently or even always give the right answers, but the spreadsheets didn't either. For non-programmers, the computer has always been a black box, data goes in, data comes out. Usually it's right, sometimes it's wrong and the users mostly had no idea why or how. But now they don't need the middleware app. They don't need to take their data and split it up into very specially structured files, and put just the right pieces of information on just the right lines and in the right spaces. They don't need to remember to do "(foo and (bar or baz))" to get the right answer, as opposed to "(foo and bar or baz)" and get the wrong one. AI for non-programmers is the closest we've ever come to "natural language programming" for people to use. It doesn't matter that it gets things wrong sometimes, or does it inefficiently or makes something unmaintainable unless you use the AI again. What matters to them is they can say "take all this data here and swizzle the frobs" in their native language instead of learning a specific programming syntax and system. And they can point it at some arbitrary data in whatever format they happen to have the data in, and they have a halfway decent chance of getting something that does what they want.

It's not going to be pretty, it's not going to be perfect and it's probably going to break in subtle and unexpected ways. But as long as most of the time its mostly good enough, people will still use it enthusiastically. We're effectively looking at "worse is better" for the modern age and for people that aren't and never were going to be programmers.

Re: It's not empowering to hand off the details

#92
post #19

I've been vibecoding a ton for the past 9 months, built a bunch of cool little apps for myself with AI, ran experiments, built an entire SDLC on skills, did the agent orchestration harness thing, etc. In the past few weeks I've hit a wall where I'm just tired of it. Each model becomes more independent but also harder to direct in detail. They produce massive, tedious, sloppy text outputs with very little input. They'…

My experience over the past year has been the exact opposite. I work through a design with the agent, have it research any points I'm not confident on, drill down on details I feel fuzzy on, and then have it do an adversarial critique of it until it stops surfacing defects. By the time I'm setting it loose to do the actual implementation, there's very little left to decide and it's producing pretty tight code. Plus I now have some solid design documents, a decision history, an issues list, and a set of gotchas for the agent to keep in mind in future.

My LLM is an assistant that helps my designs and decision process, implements the final work expertly, and I'm always in the driver's seat. And the development speed is astronomical.

Re: It's not empowering to hand off the details

#93
post #19

I've been vibecoding a ton for the past 9 months, built a bunch of cool little apps for myself with AI, ran experiments, built an entire SDLC on skills, did the agent orchestration harness thing, etc. In the past few weeks I've hit a wall where I'm just tired of it. Each model becomes more independent but also harder to direct in detail. They produce massive, tedious, sloppy text outputs with very little input. They'…

My experience over the past year has been the exact opposite. I work through a design with the agent, have it research any points I'm not confident on, drill down on details I feel fuzzy on, and then have it do an adversarial critique of it until it stops surfacing defects. By the time I'm setting it loose to do the actual implementation, there's very little left to decide and it's producing pretty tight code. Plus I…

I used to do adversarial critique, but I found that "agents can't identify issues" was a surprisingly long way from a good implementation. I kept finding silly correctness issues and shortcuts taken whenever I expanded testing or dug deeply into the implementation.

Now, I'm back to rubber-ducking until I've built my own mental model over a few days of thinking.

Re: It's not empowering to hand off the details

#94

Earlier quoted context omitted.

My experience over the past year has been the exact opposite. I work through a design with the agent, have it research any points I'm not confident on, drill down on details I feel fuzzy on, and then have it do an adversarial critique of it until it stops surfacing defects. By the time I'm setting it loose to do the actual implementation, there's very little left to decide and it's producing pretty tight code. Plus I…

I used to do adversarial critique, but I found that "agents can't identify issues" was a surprisingly long way from a good implementation. I kept finding silly correctness issues and shortcuts taken whenever I expanded testing or dug deeply into the implementation. Now, I'm back to rubber-ducking until I've built my own mental model over a few days of thinking.

I'm not doing adversarial critiques of the code; I'm doing adversarial critiques of the designs and plans. If it's still outputting bad code when it comes to the implementation, I do an interrogation round to find out why it's choosing that way, then update the principles, standards, or linting tools to fix it.

Re: It's not empowering to hand off the details

#95

This post ignores that verifying something works doesn't require you to fully understand it. This is easily observable in products we use everyday. We don't need to understand them to be able to verify they work correctly. The cost of verification is often cheaper than the cost of production. It present delegation as absence of power/agency. While I think there is some kernel of truth in here, the claim "it's not emp…

>We don't need to understand them to be able to verify they work correctly

I don't think that's the case and it's becoming more obvious every day. From people who cannot distinguish truth or fiction on online platforms, good code from bad, to insecure software that causes supply chain attacks, to investment vehicles or fake medicine peddled that does not work, the idiotic MBA manager who does not understand the workers they manage and so on. That is why we're living on BS metrics and crappy reviews, because to the people who manage organizations their own workplace is a Blackbox. The critique that "AI" systems are semantically blind token processors is correct, it's just not bothering anyone because it already applied to most modern companies.

When people become passive consumers rather than broadly competent users how something works cannot be evaluated so by definition all they have to go off is appearance, which is why we live in the age of influencers and marketing, because that is now the only factor that actually matters.

Re: It's not empowering to hand off the details

#96
post #41

All details are not created equal. Some details are boring. My AI dream (that I’m living happily) is getting to focus on the details that I find interesting and ignoring all the boilerplate details that modern software requires.

Boilerplate details mean we've failed as an industry. Why haven't we already got the computer to automate all the boring bits without AI?

I really enjoy working with Gleam which is a rather boilerplate heavy language. However most of the work is managed by a really well built LSP. If you're writing a strongly type language it's easy to programmatically manage all of the boilerplate. You could you an LLM but why bother when it's a so formulaic.

Re: It's not empowering to hand off the details

#98

This post ignores that verifying something works doesn't require you to fully understand it. This is easily observable in products we use everyday. We don't need to understand them to be able to verify they work correctly. The cost of verification is often cheaper than the cost of production. It present delegation as absence of power/agency. While I think there is some kernel of truth in here, the claim "it's not emp…

>We don't need to understand them to be able to verify they work correctly I don't think that's the case and it's becoming more obvious every day. From people who cannot distinguish truth or fiction on online platforms, good code from bad, to insecure software that causes supply chain attacks, to investment vehicles or fake medicine peddled that does not work, the idiotic MBA manager who does not understand the worke…

If I commission a part specified as 10.00 ± 0.01 mm, I can verify it with a calibrated micrometer without understanding the CNC machine, its software, or how to manufacture the part. Likewise, a function with a finite input space can be exhaustively tested against its specification without understanding its implementation. In these cases, I need to understand the requirement and the test, not the production details, which can actually be a black box.

Your examples show that verification is sometimes inadequate, not that it requires full productive competence. The conclusion doesn't generalize.

Re: It's not empowering to hand off the details

#99
> I think behind a lot of the enthusiasm around AI is a dream of being able to manifest things into reality without having to get into the details.

Ironically, that I don't have to skip the details is the one thing I like. Mind you, what I use LLM for is toy stuff compared to what people who use them at their jobs for big projects.

But FWIW, I wrote this comment recently: https://news.ycombinator.com/item?id=49049006 And then I figured I should actually do that, I wanna see what it looks like. So I described it to the best of my abilities, and was polite about it: https://pastebin.com/sAbPzi05 Claude did not ask for clarification, it just knocked it out of the park, free tier, Sonnet, medium effort. https://i.imgur.com/YPwr6aT.png The only changes I made since then are not worth talking about.

Today I made another little tool, one I'll actually use but that is too specific and boring to explain, and because of that previous experience I spent nearly an hour writing that prompt, rereading it, making sure to use the same terms for the same concepts everywhere, moving things around so what logically belongs together actually is together, instead of a stream of consciousness, and the result is exactly what I had in mind. It was like imagining something and then seeing that exact thing, except the colour scheme had a nice topical little quirk even.

The plan now is to keep chatting about the result as I make experiences with it in practice, make notes for version 2.0, and then update and extend that first prompt and use it in a fresh context. And that is very fun, actually, and it's still a puzzle. What do I even want, exactly, and how do I describe it? That's not trivial, and there is hardly a "skill ceiling" here, though of course there are diminishing returns. I also assume that if I put some vague amount "less effort" into it, the result would be the same, but I don't care, because I enjoy using this brain muscle.

And directing the effort towards just a prompt, not a whole "system" around it pleases me too, since I generally don't like vendor lock-in, and prefer things to just be a "a bunch of files" that run almost anywhere. A clear English description is as close as it gets to that, and I don't mind that I roll the dice with every LLM I give a specific prompt to, since at least it doesn't mutate the prompt.

I hate the formatting of the the LLM code of course, I wouldn't have named many variables that way, so I still look forward to and love making things where I put every character myself. But since I code voluntarily I see it as two separate activities that don't really encroach upon each other unless I make them.

Re: It's not empowering to hand off the details

#100

Earlier quoted context omitted.

I used to do adversarial critique, but I found that "agents can't identify issues" was a surprisingly long way from a good implementation. I kept finding silly correctness issues and shortcuts taken whenever I expanded testing or dug deeply into the implementation. Now, I'm back to rubber-ducking until I've built my own mental model over a few days of thinking.

I'm not doing adversarial critiques of the code; I'm doing adversarial critiques of the designs and plans. If it's still outputting bad code when it comes to the implementation, I do an interrogation round to find out why it's choosing that way, then update the principles, standards, or linting tools to fix it.

The skill I wrote did both. Design would go through an adversarial round, then a signoff by me, then implementation, then critique rounds by agents prompted to specific types of issues. And even then, LLMs were still struggling to put together complicated bits of code.
Post reply on HN