Live data from Hacker News

AI coding

geohot.github.io

61–70 of 299 posts

Re: AI coding

#61
post #48

I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…

I love AI for speed running through all the boring stuff and getting to the good parts. In some cases, especially with the more senior devs in my org, fear of the good parts is why they're against AI. Devs often want the inherent safety of the boring, easy stuff for a while. AI changes the job to be a constant struggle with hard problems. That isn't necessarily a good thing. If you're actually senior by virtue of tim…

> AI changes the job to be a constant struggle with hard problems.

Very true. I think AI (especially Claude Code) forced me to actually think hard about the problem at hand before implementing the solution. And more importantly, write down my thoughts before they fleet away from my feeble mind. A discipline that I wished I had before.

Re: AI coding

#62

I started fully coding with Claude Code. It's not just vibe coding, but rather AI-assisted coding. I've noticed there's a considerable decrease in my understanding of the whole codebase, even though I'm the only one who has been coding this codebase for 2 years. I'm struggling to answer my colleagues' questions. I am not defending we should drop AI, but we should really measure its effects and take actions accordingl…

I keep wanting to go back to using claudecode but I get worried about this issue. How best to use it to complement you, without it rewriting everything behidn the scenes? whats the best protocol? constnat commit requests and reviews?

Re: AI coding

#63
It takes time. There are cycles of “Oh wow!” “Oh wait...” “What if?” and “Aha!” Each of those has made me more effective and resulted in reliable benefits with less zig zagging back and forth.

Re: AI coding

#64
AI coding is the one thing that got my back to programming. I got to the point in life, when my ability to focus is reducing, and I prefer to send the remaining energy elsewhere. I kind of gave up on programming, just doing architecture and occasionally doing very small programming tasks. It all changed when I discovered Claude Code and saw that the way it works, is kind of how I work. I also use a lot of grep to find my way through a new codebase, I also debug stuff by adding logs to see the context, I also rely on automated tests to tell me something is broken. I'm still very good at reading code, I'm good at architecture, and with these tools, I feel I can safely delegate the boring bits of writing code and debugging trivial things to AI. Yes, it's slower than if I focused on the task myself, but the point is that I'd not be able to focus on the task myself.

Re: AI coding

#65

Earlier quoted context omitted.

Research on _13_ people, that's a very important caveat when evaluating something like adderal.

I’m quite sure that there’s a ton more research on it. The drug’s been around for decades. Lots of time for plenty of studies. If legitimate research had found it to be drastically better, that study would definitely have been published in a big way. Unscientifically, I personally know quite a number of folks that sincerely believed that they couldn’t function without it, but have since learned that they do far bette…

My point is that micro-studies like that on a tiny random (or even counter-indicated, "healthy") selection of the general population don't tell you much for drugs that do specific things.

"Antibiotics don't improve your life, but can damage your health" would likely be the outcome on 13 randomly selected healthy individuals. But do the same study on 13 people with a bacterial infection susceptible to antibiotics and your results will be vastly different.

Re: AI coding

#67
post #55
post #48

Earlier quoted context omitted.

I love AI for speed running through all the boring stuff and getting to the good parts. In some cases, especially with the more senior devs in my org, fear of the good parts is why they're against AI. Devs often want the inherent safety of the boring, easy stuff for a while. AI changes the job to be a constant struggle with hard problems. That isn't necessarily a good thing. If you're actually senior by virtue of tim…

>AI changes the job to be a constant struggle with hard problems I find this hilarious. From what I've seen watching people do it, it changes the job from deep thought and figuring out a good design to pulling a lever on a slot machine and hoping something good pops out. The studies that show diminished critical thinking have matched what i saw anecdotally pairing with people who vibe coded. It replaced deep critical…

Which was my original point. Not that the outcome is shit. So much of what we write is absolutely low-skill and low-impact, but necessary and labor-intensive. Most of it is so basic and boilerplate you really can't look at it and know if it was machine- or human-generated. Why shouldn't that work get cranked out in seconds instead of hours? Then we can do the actual work we're paid to do.

To pair this with the comment you're responding to, the decline in critical thinking is probably a sign that there's many who aren't as senior as their paycheck suggests. AI will likely lead to us being able to differentiate between who the architects/artisans are, and who the assembly line workers are. Like I said, that's not a new problem, it's just that AI lays that truth bare. That will have an effect generation over generation, but that's been the story of progress in pretty much every industry for time eternal.

Re: AI coding

#68
LLMs are a tool to help match human thought to what computers can do. People would like them to have exact reproducible results, but they're on the other end of the spectrum, more like people than tools. George correctly points out there is a vast space to explore closer to the compute hardware that might profitably be explored. Thanks to the same LLMs, that's about to get a whole lot easier. If you marveled at the instant response of Turbo Pascal and IDEs, you're in for a whole lot more.

--- (that was the tl;dr, here's how I got there) ---

As a mapper[3], I tend to bounce all the things I know against each new bit of knowledge I acquire. Here's what happens when that coincides with GeoHot's observation about LLMs vs Compilers. I'm sorry this is so long, right now it's mostly just stream of thought with some editing. It's an exploration of bouncing the idea of impedance matching against the things that have helped advance programming and computer science.

--

I've got a cognitive hammer that I tend to over-use, and that is seeing the world through the lens of a Ham Radio operator, and impedance matching[2]. In a normal circuit, maximum power flows when the source of power and the load being driven have the same effective resistance. In radio frequency circuits (and actually any AC circuit) there's another aspect, reactance. It's a time shifted form of current. This is trickier there are now 2 dimensions to consider instead of one, but most of the time, a single value, VSWR is sufficient to tell how well things are matched.

VSWR is adequate to know if a transmitter is going to work, or power bouncing back from the antenna might destroy equipment, but making sure it will work across a wide range of frequencies, yields at least a 3rd dimension. As time progresses, if you actually work with those additional dimensions, it slowly sinks in what works, and how, and what had previously seemed like magic, becomes engineering.

For example, vacuum tube based transmitters have higher resistances that almost any antenna, transformers and coupling through elements that shift power back and forth between the two dimensions allow optimum transfer without losses at the cost of complexity.

On the other hand, semiconductor based transmitters tend to have the opposite problem, their impedances are lower, so different patters work for them, but most people still just see it as "antenna matching", and focus on the single number, ignoring the complexity.

{{Wow... this is a book, not an answer on HN... it'll get shorter after a few edits, I hope, NOPE... it's getting longer...}}

Recently, a tool that used to cost thousands of dollars, the Vector Network Analyzer, has become available at less than $100. It allows for measuring resistance, reactance, and gain simultaneously across frequency. It's like compilers, making things manageable in scope that otherwise seemed too complex. It only took a few times playing with a NanoVNA to understand things that previously would have been some intense EE classwork with Smith Charts.

Similarly, tools like Software Defined Radios for $30, and GNU Radio (for $0.00) allowed understanding digital signal processing in ways that would have been equally difficult without professional instruction. With these tools, you can build a signal flow graph in an interactive window, and in moments have a working radio for FM, AM, Sideband, or any other thing you can imagine. It's magic!

-- back to computing and HN --

In the Beginning was ENIAC, a computer that took days to set up and get working on a given problem by a team with some experience. Then John Von Neumann came along, and added the idea of stored programs, which involved sacrificing the inherently parallel nature of the machine, losing 70% of its performance, but making it possible to set it up for a task simply by loading a "program" onto it's back of instruction switches.

Then came cards and paper tape storage, further increasing the speed at which data and programs could be handled.

It seems to me that compilers were like one of the above tools, they made it possible for humans to do things that only Alan Turing or others similarly skilled could do in the beginning of programming.

Interactive programming increased the availability of compute, and make machines that were much faster that programmers, more easily distributed among teams of programmers.

IDEs were another. Turbo Pascal allowed compile, linking, and execution to happen almost instantly. It widely opened the space for experimentation by reducing the time required to get feedback from minutes to almost zero.

I've done programming on and off through 4 decades of work. Most of my contemplation is as an enthusiast, instead of professional. As far as compilers and the broader areas of Computer Science I haven't formally studied, it seems to me that LLMS, especially the latest "agentic" versions, will allow me to explore things far easier than I might have otherwise done. LLMs have helped me to match my own thoughts across a much wider cognitive impedance landscape. (There's that analogy/hammer in use...)

Compilers are an impedance matching mechanism. Allowing a higher level of abstraction gives flexibility. One of the ideas I've had in the past for helping with better interaction between people and compilers is to allow compilers that also work backwards.[1] I'm beginning to suspect that with LLMs, I might actually be able to attempt to build this system, it's always seemed out of reach because of the levels of complexity involved.

I have several other ideas that might warrant a new attempt, now that I'm out of the job market, and have the required free time and attention.

{{Sorry this turned out to be an essay... I'm not sure how to condense it back down right now}}

[1] https://wiki.c2.com/?BidirectionalCompiler

[2] https://en.wikipedia.org/wiki/Impedance_matching

[3] https://garden.joehallenbeck.com/container/mappers-and-packe...

Re: AI coding

#69

I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…

What’s the tooling you’re using, and the workflow you find yourself drawn to that boosts productivity?

I've used many different ones, and find the result pretty similar. I've used Copilot in VS Code, Chat GPT stand-alone, Warp.dev's baked in tools, etc. Often it's a matter of what kind of work I'm doing, since it's rarely single-mode.

Re: AI coding

#70
This is a more extreme example of the general hacker news group think about AI.

Geohot is easily a 99.999 percentile developer, and yet he can’t seem to reconcile that the other 99.999 percent are doing something much more basic than he can ever comprehend.

It’s some kind of expert paradox, if everyone was as smart and capable as the experts, then they wouldn’t be experts.

I have come across many developers that behave like the AI. Can’t explain codebases they’ve built, can’t maintain consistency.

It’s like a aerospace engineer not believing that the person that designs the toys in an Kinder egg doesn’t know how fluid sims work.

Post reply on HN