Live data from Hacker News

Working With AI: A concrete example

htmx.org

61–70 of 78 posts

Re: Working With AI: A concrete example

#61
post #21

Earlier quoted context omitted.

One partial mitigation is to ask it to use plan mode -- and then very carefully review the plan before allowing it to execute.

My experience with AI plans is that they’re a wall of text that’s very hard to extract meaning from. Combined with it not doing a good job to begin with, I don’t think plan+revise is a great use of time.

I get a lot of this in design docs every time I give it a negative constraint:

[Suboptimal choice]

And here's why it's not suboptimal -- you said X sucks and notto do X, but this choice is not technically X, it's just really similar and shares that sucky property.

Re: Working With AI: A concrete example

#62
post #26

Earlier quoted context omitted.

> But it doesn't work for reasoning and abstraction, so it fails to synthesise and propose novel views I disagree. Have a conversation with it about your problem and work through design decisions with it. When I do that, I find it gives me a lot of good ideas. Disclaimer: I'm not working on anything groundbreaking (like most people)

Yes, but "good ideas" compared to what? If you were aware of the better alternatives, you probably wouldn't be discussing those details with an LLM. You'd find that it just randomly gave you one. It might work, but you don't know how well until you're already entrenched. Nobody knows everything, so of course LLMs can be useful sometimes. More useful than plain old search, books, or even discussion with real humans? M…

> Yes, but "good ideas" compared to what? If you were aware of the better alternatives, you probably wouldn't be discussing those details with an LLM

Even when I already have a good idea of how I plan to do something, I may still ask AI and then find it gave me better idea for some particular thing.

I liken it to using GPS even when you know the route like the back of your hand. It can still steer you around an accident.

To do this effectively I have to drop the idea that I always know better than it does.

Re: Working With AI: A concrete example

#63
post #21

Carson’s experience matches mine: AI is good at analysis and boilerplate, but not good at the kind of critical thinking necessary for good designs. If it were human, I would say that it jumps to solutions to quickly, rather than stepping back to consider the big picture and how everything should fit together to make a cohesive whole. It’s not human, of course, and I think this problem actually relates to the fact tha…

One partial mitigation is to ask it to use plan mode -- and then very carefully review the plan before allowing it to execute.

[dead]

Re: Working With AI: A concrete example

#64

It's a good write up, but it's lacking some details, the most important one is: which Claude model was used? The second issue is: what was tooling and the prompt approach? (To be clear, I have no problem with the premise of the write up. But without some details like this, it's sort of like saying "I had a bad board on my deck, and my tape measure wasn't able to help me remove the nails. What a bad tape measure."

Opus 4.whatever (it was last week) via a command line interface in the IntelliJ Claude plugin. The series of prompts weren't particularly interesting or innovative on my part: a paste in of the user report then a few back and forths on fixing it, me reviewing the changes and coming up with the final answer.

It might feel interesting, but it's sort of the crux of the issue. Average or below average prompts will produce average below-average results. The model can't make up for that.

Not saying every problem can or should be solved but AI, but mastery of the tools is kind of important when evaluating the tools. It's like complaining that vi or emacs is slow to use because of the bindings are complicated.

Re: Working With AI: A concrete example

#65

> Technical debt, I assert without evidence1, grows exponentially, and therefpre it is very important to minimize it in your projects. This actually seems like a really important idea absolutely deserving of its own blog post. I'd have to think about the exact argument for why this feels so right, but the kernel would go something like this: whatever you build on those parts of the codebase where you have technical d…

I agree, it is an interesting thing to ponder. I often phrased it to myself that the cost of technical debt compounds the lower in the code stack you go.

Said another way, tech debt has a multiplicative factor the farther away from the end user you get. Tech debt in the database is worse than in the data layer. It is worse in the data layer than in the business logic. It is worse in the business logic than in the UI code. etc.

This is related to the fact that it gets exponentially more difficult to refactor code the farther away you get from the end user. Changing the database is usually more difficult and impacts more things than the data layer code. And on and on we go back up.

Re: Working With AI: A concrete example

#66

Carson’s experience matches mine: AI is good at analysis and boilerplate, but not good at the kind of critical thinking necessary for good designs. If it were human, I would say that it jumps to solutions to quickly, rather than stepping back to consider the big picture and how everything should fit together to make a cohesive whole. It’s not human, of course, and I think this problem actually relates to the fact tha…

I don't think this problem is related to the fact that they don't have a world model, or because they don't form a mental model of how everything fits together, or a fundamental limitation of LLMs. These claims are often meaningless, and the boring answer is usually something like "software architecture is harder to verify than code/maths so RLing on it is harder, and it's harder writing good evals/benchmarks for it".

Re: Working With AI: A concrete example

#67

Earlier quoted context omitted.

Opus 4.whatever (it was last week) via a command line interface in the IntelliJ Claude plugin. The series of prompts weren't particularly interesting or innovative on my part: a paste in of the user report then a few back and forths on fixing it, me reviewing the changes and coming up with the final answer.

It might feel interesting, but it's sort of the crux of the issue. Average or below average prompts will produce average below-average results. The model can't make up for that. Not saying every problem can or should be solved but AI, but mastery of the tools is kind of important when evaluating the tools. It's like complaining that vi or emacs is slow to use because of the bindings are complicated.

idk i think i'm pretty good w/AI in general, e.g. designed these using it:

https://mtmc.cs.montana.edu

https://bcp.cs.montana.edu

but we can all be better i guess

Re: Working With AI: A concrete example

#68

Earlier quoted context omitted.

It might feel interesting, but it's sort of the crux of the issue. Average or below average prompts will produce average below-average results. The model can't make up for that. Not saying every problem can or should be solved but AI, but mastery of the tools is kind of important when evaluating the tools. It's like complaining that vi or emacs is slow to use because of the bindings are complicated.

idk i think i'm pretty good w/AI in general, e.g. designed these using it: https://mtmc.cs.montana.edu https://bcp.cs.montana.edu but we can all be better i guess

bcp link is dead

Re: Working With AI: A concrete example

#69

> Technical debt, I assert without evidence1, grows exponentially, and therefpre it is very important to minimize it in your projects. This actually seems like a really important idea absolutely deserving of its own blog post. I'd have to think about the exact argument for why this feels so right, but the kernel would go something like this: whatever you build on those parts of the codebase where you have technical d…

Ward Cunningham, who coined technical debt, describes it as having interest, which is exponential:

> Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Re: Working With AI: A concrete example

#70

Earlier quoted context omitted.

I feel the same way. Maybe it’s the ADHD, maybe I’m just dumb, but I cannot parse well the giant walls they tend to produce.

It’s melting my brain to read them all day. Our merge request descriptions are a mile long and so dense with jargon that it’s very difficult to figure out the important part of the changes. They turned the english language into enterprise java and my train of thought is now a series of NullPointerExceptions

> They turned the english language into enterprise java

.... tell them not to do that if you don't like it?

"PR Descriptions must explain the entirety of the PR's contents in 300 characters or less and be written at no greater than a 600 lexile score. After writing the description, carefully review it's claims against the changeset diff if any staged changes are unable to be tracked back to a claim in the PR description, reject the creation and alert the user of the discrepancy offering solutions on how to remediate"

Post reply on HN