This doesn't seem like a well-thought-out post. I mean, I probably could have told you that from the fact that it's either pro-AI or anti-AI (in this case the latter), but this is a particularly poorly thought out post. Others here have pointed out the water-wasting red herring, but there are several other pieces of nonsense here — the general environmental doom-mongering, and labeling recursive self-improvement as "mystical", for example.
Me, I pointed Claude Opus 5 at a C codebase I've been working on for years and it immediately found five serious bugs and told me how to fix them, as well as how to use Linux system calls I wasn't familiar with to solve some other problems. And I gave it a new language for PEGs I'd written up a couple of years ago, and it wrote me a working implementation in OCaml that afternoon, fixing several bugs in my example grammars along the way and resolving a conceptual problem I'd had a roadblock on. I asked Fable 5.1 to implement a minimal proof assistant, and it wrote a clone of J-Bob in Python, which I'm studying now. Although there is a certain firehose quality to this stuff, I sure don't intend to use AI to actively de-skill my brain.
That doesn't guarantee that AI will be a beneficial innovation overall, of course! As with most innovations, it probably depends on the balance between people being able to use the innovation to gain control over their own lives, and people being able to use it to gain control over others' lives. (Barring a FOOM scenario, of course, where our prediction ability is nonexistent.)
So, I don't think a pro-AI post can be well thought out, either. It's too early and chaotic to understand what's going to happen, and it may actually be uncertain. Pro and anti are both far too simplistic.
Well, for example, in one afternoon, I have a parsing engine to understand, which is 9 pages of code. I thought I knew OCaml, having written a few interpreters in it, but I didn't know the {foo| |foo} multiline string syntax, I didn't know about Printf.ksprintf, I didn't know about Buffer.create, I didn't know about String.escaped, I must have once known about List.exists and List.rev_append and forgotten, I'd never thought of pattern-matching Array.to_list Sys.argv as a way to parse a command line, I didn't know about Sys.file_exists, and now I also have to think about what the parse result should look like and how to use it. And Claude correctly pointed out that the way I had thought about handling things like heredocs (or {foo| |foo} strings) would violate the preconditions for using the Packrat parsing algorithm, and suggested that I use the alternative approach of parameterized productions as in OMeta, which I need to think over.
I think that was the same day I prototyped an approach to using Service Workers from localhost as a platform for persistent mobile apps that don't show up in the app list but also don't rely on the TLS CA system for their security. Which involved learning a lot of stuff about the Service Worker lifecycle and localStorage and IndexedDB that I didn't know before.
I love how well this comment captures the experience of engaging with LLMs as a way to deliberately challenge and expand knowledge.
When I see people worry about LLMs atrophying their mental abilities I assume they haven't thought very hard about ways to lean into using them to expand their mental capabilities.
I have been prototyping some network proxies in a largely "vibe coded" fashion and it has been a mixed experience.
It has definitely accelerated my learning: through the process of writing rigorous plans, I have learned so much about network programming... the intricacies of HTTP2, how to design a fast MITM proxy, performance pitfalls in SSL...
These are things I studiously avoided learning for a decade, now demystified, mostly through Claude patiently rendering many figures and diagrams.
And with Fable, I was able to ship a working Envoy Rust extension in a one-shot.
On the other hand, my grasp on the details is tenuous. Every so often the agent can't progress and I am stuck for ideas, hitting different prompts like they were slot machines. I forget how to solve problems by myself.
I can feel myself becoming supine and dependent on something I know is going to become more expensive, a dependency AI vendors will seek to exploit. It has happened quickly. I do not really consent; it is forced on me by my employer.
One thing I may try this week is typing in all the code myself. With the level of back and forth that I've been happy with so far, Claude Pro seems to only be able to produce about 1000 lines of code a day in two or three five-hour sessions. I can totally type 1000 lines of code in a couple of hours if no problem-solving is needed. So maybe I'll look at Claude's code, switch screens to my editor, and type until I don't know what to type, and repeat.
Obviously there are higher-level design issues that I might not notice while engaging with the code at the byte-by-byte level, but I won't have the embarrassing problem I had a couple of weeks ago where duck.ai wrote me a CPU in Verilog, and after I tested it, I tried to write something in Verilog myself and couldn't even figure out how to write a syntactically correct XOR-gate module. (Verilator's parse errors are not designed as a Verilog tutorial, it turns out.)
kragen · · focus · HN ↗
Me, I pointed Claude Opus 5 at a C codebase I've been working on for years and it immediately found five serious bugs and told me how to fix them, as well as how to use Linux system calls I wasn't familiar with to solve some other problems. And I gave it a new language for PEGs I'd written up a couple of years ago, and it wrote me a working implementation in OCaml that afternoon, fixing several bugs in my example grammars along the way and resolving a conceptual problem I'd had a roadblock on. I asked Fable 5.1 to implement a minimal proof assistant, and it wrote a clone of J-Bob in Python, which I'm studying now. Although there is a certain firehose quality to this stuff, I sure don't intend to use AI to actively de-skill my brain.
That doesn't guarantee that AI will be a beneficial innovation overall, of course! As with most innovations, it probably depends on the balance between people being able to use the innovation to gain control over their own lives, and people being able to use it to gain control over others' lives. (Barring a FOOM scenario, of course, where our prediction ability is nonexistent.)
So, I don't think a pro-AI post can be well thought out, either. It's too early and chaotic to understand what's going to happen, and it may actually be uncertain. Pro and anti are both far too simplistic.
ghostbrainalpha · · focus · HN ↗
kragen · · focus · HN ↗
I think that was the same day I prototyped an approach to using Service Workers from localhost as a platform for persistent mobile apps that don't show up in the app list but also don't rely on the TLS CA system for their security. Which involved learning a lot of stuff about the Service Worker lifecycle and localStorage and IndexedDB that I didn't know before.
It's just a lot.
simonw · · focus · HN ↗
When I see people worry about LLMs atrophying their mental abilities I assume they haven't thought very hard about ways to lean into using them to expand their mental capabilities.
zero_shift · · focus · HN ↗
It has definitely accelerated my learning: through the process of writing rigorous plans, I have learned so much about network programming... the intricacies of HTTP2, how to design a fast MITM proxy, performance pitfalls in SSL...
These are things I studiously avoided learning for a decade, now demystified, mostly through Claude patiently rendering many figures and diagrams.
And with Fable, I was able to ship a working Envoy Rust extension in a one-shot.
On the other hand, my grasp on the details is tenuous. Every so often the agent can't progress and I am stuck for ideas, hitting different prompts like they were slot machines. I forget how to solve problems by myself.
I can feel myself becoming supine and dependent on something I know is going to become more expensive, a dependency AI vendors will seek to exploit. It has happened quickly. I do not really consent; it is forced on me by my employer.
kragen · · focus · HN ↗
Obviously there are higher-level design issues that I might not notice while engaging with the code at the byte-by-byte level, but I won't have the embarrassing problem I had a couple of weeks ago where duck.ai wrote me a CPU in Verilog, and after I tested it, I tried to write something in Verilog myself and couldn't even figure out how to write a syntactically correct XOR-gate module. (Verilator's parse errors are not designed as a Verilog tutorial, it turns out.)
zero_shift · · focus · HN ↗
jakzurr · · focus · HN ↗