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

Building better AI tools

hazelweakly.me

Post reply on HN
Print view View original

141–150 of 189 posts

Re: Building better AI tools

#141

Post by ofjcihen »

tptacek wrote: post #73
miltonlost wrote: post #63

Earlier quoted context omitted.

It's not a confusing piece if you don't skip/ignore the first part. You're using her one example and removing the portion about how human beings learn and how AI is actively removing that process. The incident resolution is an example of her general point.

I feel pretty comfortable with how my comment captures the context of the whole piece, which of course I did read. Again: what's weird about this is that the first part would be pretty coherent and defensible if applied to coding agents (some people will want to work the way she spells out, especially earlier in their career, some people won't), but doesn't make as much sense for the example she uses for the remainin…

[flagged]

Re: Building better AI tools

#142

Post by mattmanser »

tptacek wrote: post #73
miltonlost wrote: post #63

Earlier quoted context omitted.

It's not a confusing piece if you don't skip/ignore the first part. You're using her one example and removing the portion about how human beings learn and how AI is actively removing that process. The incident resolution is an example of her general point.

I feel pretty comfortable with how my comment captures the context of the whole piece, which of course I did read. Again: what's weird about this is that the first part would be pretty coherent and defensible if applied to coding agents (some people will want to work the way she spells out, especially earlier in their career, some people won't), but doesn't make as much sense for the example she uses for the remainin…

I know you carry on to have a good argument down thread, but why do you feel the first part defensible?

The author's saying great products don't come from solo devs. Linux? Dropbox? Gmail? Ruby on Rails? Python? The list is literally endless.

But the author then claims that all great products come from committee? I've seen plenty of products die by committee. I've never seen one made by it.

Their initial argument is seriously flawed, and not at all defensible. It doesn't match reality.

Re: Building better AI tools

#143

Post by tptacek »

mattmanser wrote: post #142
tptacek wrote: post #73

Earlier quoted context omitted.

I feel pretty comfortable with how my comment captures the context of the whole piece, which of course I did read. Again: what's weird about this is that the first part would be pretty coherent and defensible if applied to coding agents (some people will want to work the way she spells out, especially earlier in their career, some people won't), but doesn't make as much sense for the example she uses for the remainin…

I know you carry on to have a good argument down thread, but why do you feel the first part defensible? The author's saying great products don't come from solo devs. Linux? Dropbox? Gmail? Ruby on Rails? Python? The list is literally endless. But the author then claims that all great products come from committee? I've seen plenty of products die by committee. I've never seen one made by it. Their initial argument is…

I just don't want to engage with it; I'm willing to stipulate those points. I'm really fixated on the strange example Weakly used to demonstrate why these tools shouldn't actually do things, but instead just whisper in the ears of humans. Like, you can actually make that argument about coding! I don't agree, but I see how the argument goes. I don't see how it makes any sense at all for incident response.

Re: Building better AI tools

#144

Post by meander_water »

I completely agree with this. I recently helped my dad put together a presentation. He is an expert in his field, so he already had all the info ready in slides. But he's not a designer, he doesn't know how to make things look "good". I tried a handful of "AI slide deck" apps. They all had a slick interface where you could generate an entire slide deck with a few words. But absolutely useless for actually doing what users need, which is to help them beautify rather than creating content.

Re: Building better AI tools

#145

Post by Jonovono »

yoyohello13 wrote: post #122
Jonovono wrote: post #51

Earlier quoted context omitted.

I find it do this more now with AI than before.

What do you mean? Are you working on more projects, or more engaged in ideation? Not sure how AI would cause you to write code in your head more while away from the computer. Most people seem to have a harder time writing code without AI the more they use it. The whole “copilot pause” phenomenon, etc.

Since my job now is primarily a reviewer of (AI) code I find:

1) I'm able to work on more projects

2) The things I am able to work on are much larger in scope and ambition

3) I like to mentally build the idea in my head so I have something to review the generated code against. Either to guide the model in the direction I am thinking or get surprised and learn about alternate approaches.

It's also like you say, in the process, a lot more iterative and ideation is able to happen with Ai. So early on i'll ask it for examples in x language using y approach. I'll sit on that for a night and throw around tangentially related approaches in my head and then riff on what I came up with the next day

Re: Building better AI tools

#146

Post by jgb1984 »

taylorallred wrote: post #14

One thing that has always worried me about AI coding is the loss of practice. To me, writing the code by hand (including the boilerplate and things I've done hundreds of times) is the equivalent of Mr. Miyagi's paint-the-fence. Each iteration gets it deeper into your brain and having these patterns as a part of you makes you much more effective at making higher-level design decisions.

What worries me more is the steep decline in code quality. The python and javascript output I've seen the supposed best LLM's generate is inefficient, overly verbose and needlessly commented at best, and simply full of bugs at worst. In the best case they're glaringly obvious bugs, in the worst case they're subtle ones that will wreak havoc for a long time before they're eventually discovered, but by then the grasp of the developers on the codebase will have slipped away far enough to prevent them from being compete t enough to solve the bugs.

There is no doubt in my mind that software quality has taken a nosedive everywhere AI has been introduced. Our entire industry is hallucinating its way into a bottomless pit.

Re: Building better AI tools

#147

Post by Jonovono »

bluefirebrand wrote: post #85
Jonovono wrote: post #51

Earlier quoted context omitted.

I find it do this more now with AI than before.

Do you? Or do you spend more time thinking about how to write prompts?

My prompts are very lazy, off the cuff. Maybe I would see better gains if I spent some time on them, not sure.

Re: Building better AI tools

#148

Post by bravesoul2 »

marknutter wrote: post #25
ranman wrote: post #16

> we built the LLMs unethically, and that they waste far more energy than they return in value If these are the priors why would I keep reading?

That's exactly the point I stopped reading too.

Do you not read any AI articles unless they are about the moral issues rather than usage?

Seems like the waiter told you how your sausage is made so you left the restaurant, but you'd eat it if you weren't reminded.

Re: Building better AI tools

#149

Post by prats226 »

Interestingly, deepseek paper mentions RL with process reward model. However they mentioned it failed to align model correctly due to subjectivity involved in defining if the intermediate step in process is right or wrong

Re: Building better AI tools

#150

Post by imranq »

While I agree with the author's vision for a more human-centric AI, I think we're closer to that than the article suggests. The core issue is that the default behavior is what's being criticized. The instruction-following capabilities of modern models mean we can already build these Socratic, guiding systems by creating specific system prompts and tools (like MCP servers). The real challenge isn't technical feasibility, but rather shifting the product design philosophy away from 'magic button' solutions toward these more collaborative, and ultimately more effective, workflows
Post reply on HN