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

51–60 of 189 posts

Re: Building better AI tools

#51

Post by Jonovono »

yoyohello13 wrote: post #26
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.

There are many time when I’ll mull over a problem in my head at night or in the shower. I kind of “write the code” in my head. I find it very useful sometimes. I don’t think it would be possible if I didn’t have the language constructs ingrained in my head.

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

Re: Building better AI tools

#52

Post by agentultra »

lupire wrote: post #41
agentultra wrote: post #13

Earlier quoted context omitted.

We don't need humans to be perfect to have reliable responses to critical situations. Systems are more important than individuals at that level. We understand people make mistakes and design systems and processes to compensate. The problem with unattended AI in these situations is precisely the lack of context, awareness, intuition, intention, and communication skills. If you want automation in your disaster recovery…

What happens when you walk into a fire and you don't know what to do? Or can't do it quickly enough?

Who is sending in untrained people to manage fires? Maybe that organization deserves what's coming to them.

An extreme example: nuclear reactors. You don't want untrained people walking into a fire with the expectation that they can manage the situation.

Less extreme example: financial systems. You don't want untrained people walking into a fire losing your customers' funds and expect them to manage the situation.

Re: Building better AI tools

#53

Post by ozten »

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.

"Every augmentation is an amputation" -- Marshall McLuhan

Re: Building better AI tools

#54

Post by tptacek »

This is a confusing piece. A lot of it would make sense if Weakly was talking about a coding agent (a particular flavor of agent that worked more like how antirez just said he prefers coding with AI in 2025 --- more manual, more advisory, less do-ing). But she's not: she's talking about agents that assist in investigating and resolving operations incidents.

The fulcrum of Weakly's argument is that agents should stay in their lane, offering helpful Clippy-like suggestions and letting humans drive. But what exactly is the value in having humans grovel through logs to isolate anomalies and create hypotheses for incidents? AI tools are fundamentally better at this task than humans are, for the same reason that computers are better at playing chess.

What Weakly seems to be doing is laying out a bright line between advising engineers and actually performing actions --- any kind of action, other than suggestions (and only those suggestions the human driver would want, and wouldn't prefer to learn and upskill on their own). That's not the right line. There are actions AI tools shouldn't perform autonomously (I certainly wouldn't let one run a Terraform apply), but there are plenty of actions where it doesn't make sense to stop them.

The purpose of incident resolution is to resolve incidents.

Re: Building better AI tools

#55

Post by jaggederest »

nico wrote: post #8
Edmond wrote: post #4

In terms of AI tools/products, it should be a move towards "Intelligent Workspaces" and less chatbots: https://news.ycombinator.com/item?id=44627910 Basically environments/platforms that gives all the knobs,levers,throttles to humans while being tightly integrated with AI capabilities. This is hard work that goes far beyond a VSCode fork.

Using Claude Code lately in a project, and I wish my instance could talk to the other developers’ instances to coordinate I know that we can modify CLAUDE.md and maintain that as well as docs. But it would be awesome if CC had something built in for teams to collaborate more effectively Suggestions are welcomed

I have an MCP that implements memory by writing to the .claude/memories/ folder and instructions in CLAUDE.md to read it. Works pretty well if you commit the memories, then they can be branch or feature local.

Re: Building better AI tools

#56

Post by visarga »

> We're really good at cumulative iteration. Humans are turbo optimized for communities, basically. This is why brainstorming is so effective… But usually only in a group. There is an entire theory in cognitive psychology about cumulative culture that goes directly into this and shows empirically how humans work in groups.

> Humans learn collectively and innovate collectively via copying, mimicry, and iteration on top of prior art. You know that quote about standing on the shoulders of giants? It turns out that it's not only a fun quote, but it's fundamentally how humans work.

Creativity is search. Social search. It's not coming from the brain itself, it comes from the encounter between brain and environment, and builds up over time in the social/cultural layer.

That is why I don't ask myself if LLMs really understand. As long as they search, generating ideas and validating them in the world, it does not matter.

It's also why I don't think substrate matters, only search does. But substrate might have to do with the search spaces we are afforded to explore.

Re: Building better AI tools

#57

Post by tptacek »

swiftcoder wrote: post #7
datadrivenangel wrote: post #5

Author makes some good points about designing human computer interfaces, but has a very opinionated view of how AI can be used in systems engineering tooling which seems like it misses a lot of places where AI can be useful even without humans in the loop?

The scenarios in the article are all about mission-critical disaster recovery - we don't even trust the majority of our human colleagues with those scenarios! AI won't make inroads there without humans in the loop, until AI is 100% trustworthy.

Right, so: having an agent go drop index segments from a search cluster to resolve a volume utilization problem is a bad idea, rather than just suggesting "these old index segments are using up 70% of the storage on this volume and your emergency search cluster outage would be resolved if you dropped them, here's how you'd do that".

But there are plenty of active investigative steps you'd want to take in generating hypotheses for an outage. Weakly's piece strongly suggests AI tools not take these actions, but rather suggest them to operators. This is a waste of time, and time is the currency of incident resolution.

Re: Building better AI tools

#59

Post by szundi »

add-sub-mul-div wrote: post #30
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.

Generalize this to: what's it going to look like in ten years when the majority of our society has outsourced general thinking and creativity rather than practicing it?

[dead]

Re: Building better AI tools

#60

Post by lucianbr »

donsupreme wrote: post #17
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.

Many analog to this IRL: 1) I can't remember the last time I write something meaningfully long with an actual pen/pencil. My handwriting is beyond horrible. 2) I can't no longer find my way driving without a GPS. Reading a map? lol

If you were a professional writer or driver, it might make sense to be able to do those things. You could still do without them, but they might make you better in your trade. For example, I sometimes drive with GPS on in areas I know very well, and the computer provided guidance is not the best.
Post reply on HN