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 good parts.

I liken AI development to a developer somewhere between junior and mid-level, someone I can given a paragraph or two of thought out instructions and have them bang out an hour of work. (The potential for then stunting the growth of actual juniors into tomorrow's senior developers is a serious concern, but a separate problem to solve)

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 accordingly. It's more than just getting more productivity.

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.

I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me. Don't ask me how they work; they just do.

Sure the engineering may be abysmal, but it's good enough to work.

It only takes basic english to produce these results, plus complaining to the AI agent that "The GUI is ugly and overcrowded. Make it look better, and dark mode."

Want specs? "include a specs.md"

This isn't a 20% more productive feeling. It's productivity beyond what I will ever do on my own, given this is not my field.

This is all possible because AI was trained on the outstanding work of CS engineers like ya'll.

But the article is highly opinionated. It's like saying only phD's can be called scientists, or only programmers can be computer hackers. But in reality every human is a scientist and a hacker in the real world. The guy in a street corner in India came up with novel ways to make and sell his product, but never wrote a research paper on it. The guy on his fourth marriage noted a statistical correlation in the outcome when meeting women at a bar vs. at a church. The plant that grew in the crevice of a rock noted sunlight absorption was optimal at an angle of 78.3 degrees and grew in that direction.

That METR study gets a lot of traction for its headline; and I doubt many people read the whole thing—it was long—but the data showed a 50% speed up for the one dev with the most experience with Cursor/AI, suggesting a learning curve and also wild statistical variation on a small sample set. An errata later suggested another dev who did not have a speedup had not represented their experience correctly, but still strongly draws into question the significance of the findings.

The specific time sucks measured in the study are addressable with improved technology like faster LLMs and improved methodology like running parallel agents—the study was done in March running Claude 3.7 and before Claude Code.

We also should value the perception of having worked 20% less even if you actually spent more time. Time flies when you’re having fun!

This post is such a cold take, and is going to age horribly.

Self driving cars fail because of regulatory requirements for five nines reliability, and they're doing inference over a dynamic noisy domain.

Autonomous engineering does not have these issues. Code doesn't need to be five nines correct, and the domain of inference is logical and basically static.

If the AI agent/coding companies didn't have their heads up their collective asses we could have fully spec driven autonomous coding within ~3 years, 100%.

Ofcourse, there is some truth in what you say. But business is desperate for new tech where they can redefine the order (who is big and who is small). There are floating billions which chase short term returns. Fund managers will be fired if they are not jumping on the new fad in the town. CIO's and CEO's will be fired if they are not jumping on AI. It's just nuclear arms race. It's good for none. but the other guy is on it, so you need to be too.

Think about this. Before there were cars on roads, people were just as much happy. Cars came, cities were redesigned for cars with buildings miles apart, and commuting miles became the new norm. You can no longer say cars are useless because the context around them has changed to make the cars a basic need.

AI does same thing. It changes the context in which we work. Everyone expects you use AI (and cars). It becomes a basic need, though a forced one.

To go further, hardly anything produced by science or technology is a basic need for humans. The context got twisted, making them basic needs. Tech solutions create the problems which they claim to solve. The problem did not exist before the solution came around. That's core driving force of business.

I have a boring opinion. A cold take? served straight from the freezer.

He is right, however AI is still darn useful. He hints at why: patterns.

Writing a test suite for a new class when an existing one is in place is a breeze. It even can come up with tests you wouldnt have thought of or would have been too time pressed to check.

It also applies to non-test code too. If you have the structure it can knock a new one out.

You could have some lisp contraption that DRYs all the WETs so there is zero boilerplate. But in reality we are not crafting these perfect cosebases, we make readable, low-magic and boilerplatey code on tbe whole in our jobs.

So I have all kinds of problems with this post.

First, the assertion that the best model of "AI coding" is that it is a compiler. Compilers deterministically map a formal language to another under a spec. LLM coding tools are search-based program synthesizers that retrieve, generate, and iteratively edit code under constraints (tests/types/linters/CI). That’s why they can fix issues end-to-end on real repos (e.g., SWE-bench Verified), something a compiler doesn’t do. Benchmarks now show top agents/models resolving large fractions of real GitHub issues, which is evidence of synthesis + tool use, not compilation.

Second, that the "programming language is English". Serious workflows aren’t "just English." They use repo context, unit tests, typed APIs, JSON/function-calling schemas, diffs, and editor tools. The "prompt" is often code + tests + spec, with English as glue. The author attacks the weakest interface, not how people actually ship with these tools.

Third, non-determinism isn't disqualifying. Plenty of effective engineering tools are stochastic (fuzzers, search/optimization, SAT/SMT with heuristics). Determinism comes from external specs: unit/integration tests, type systems, property-based tests, CI gates.

False dichotomy: "LLMs are popular only because languages/libraries are bad." Languages are improving (e.g. Rust, Typescript), yet LLMs still help because the real bottlenecks are API lookup, cross-repo reading, boilerplate, migrations, test writing, and refactors, the areas where retrieval and synthesis shine. These are complementary forces, not substitutes.

Finally, no constructive alternatives are offered. "Build better compilers/languages" is fine but modern teams already get value by pairing those with AI: spec-first prompts, test-gated edits, typed SDK scaffolds, auto-generated tests, CI-verified refactors, and repo-aware agents.

A much better way to think about AI coding and LLMs is that they aren’t compilers. They’re probabilistic code synthesizers guided by your constraints (types, tests, CI). Treat them like a junior pair-programmer wired into your repo, search, and toolchain. But not like a magical English compiler.

I think this gets to a fundamental problem with the way the AI labs have been selling and hyping AI. People keep on saying that the AI is actually thinking and it's not just pattern matching. Well, as someone that uses AI tools and develops AI tools, my tools are much more useful when I treat the AI as a pattern matching next-token predictor than an actual intelligence. If I accidentally slip too many details into the context, all of a sudden the AI fails to generalize. That sounds like pattern matching and next token prediction to me.

> This isn’t to say “AI” technology won’t lead to some extremely good tools. But I argue this comes from increased amounts of search and optimization and patterns to crib from, not from any magic “the AI is doing the coding”

* I can tell claude code to crank out some basic crud api and it will crank it out in a minute saving me an hour or so.

* I need an implementation of an algorithm that has been coded a million times on github, I ask the AI to do it and it cranks out a correct working implementation.

If I only use the AI in its wheelhouse it works very well, otherwise it sucks.

> AI makes you feel 20% more productive but in reality makes you 19% slower. How many more billions are we going to waste on this?

Adderall is similar. It makes people feel a lot more productive, but research on its effectiveness[0] seems to show that, at best, we get only a mild improvement in productivity, and marked deterioration of cognitive abilities.

[0] https://pmc.ncbi.nlm.nih.gov/articles/PMC6165228/

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.

Great short read. But this “ It’s why the world wasted $10B+ on self driving car companies that obviously made no sense.”

Not everything should make sense. Playing , trying and failing is crucial to make our world nicer. Not overthinking is key, see later what works and why.

Pretty much nailed it. Once you’re at about 40k LOC you can just turn off the autocomplete features and use Claude or GPT to evaluate specific high-level issues. My sense is 40k LOC is the point at which the suggestions are offset by the rabbit holes they sometimes send you down, but, more importantly by obscuring from you the complexity of the thing you’re building—temporarily.

There's a lot of complaining about current compilers / languages / codebase in similar posts, but barely any ideas for how to make them better. It doesn't seem surprising that people go for the easier problem (make the current process simpler with LLMs) than for the harder one (change the whole programming landscape to something new and actually make it better).

I have been working on finding out ways to make use of AI a net-positive in my professional life as opposed to yet another thing I have to work around and have cognitive load of. Some notes so far in getting great benefits out of it on couple projects -

* Getting good results from AI forced me to think through and think clearly - up front and even harder.

* AI almost forces me to structure and break down my thoughts into smaller more manageable chunks - which is a good thing. (You can't just throw a giant project at it - it gets really far off from what you want if you do that.)

* I have to make it a habit of reading what code it has added - so I understand it and point to it some improvements or rarely fixes (Claude)

* Everyone has what they think are uninteresting parts of a project that they have to put effort into to see the bigger project succeed - AI really helps with those mundane, cog in the wheel things - it not only speeds things up, personally it gives me more momentum/energy to work on the parts that I think are important.

* It's really bad at reusability - most humans will automatically know oh I have a function I wrote to do this thing in this project which I can use in that project. At some point they will turn that into a library. With AI that amount of context is a problem. I found that filling in for AI for this is just as much work and I best do that myself upfront before feeding it to AI - then I have a hope of getting it to understand the dependency structure and what does what.

* Domain specific knowledge - I deal with Google Cloud a lot and use Gemini for understanding what features exist in some GCP product and how I can use it to solve a problem - works amazingly well to save me time. At the least optioning the solution is a big part of work it makes easier.

* Your Git habits have to be top notch so you can untangle any mess AI creates - you reach a point where you have iterated over a feature addition using AI and it's a mess and you know it went off the rails after some point. If you just made one or two commits now you have to unwind everything and hope the good parts return or try to get AI to deal with it which can be risky.

> AI makes you feel 20% more productive but in reality makes you 19% slower. How many more billions are we going to waste on this?

True in the long run. Like a car with a high acceleration but low top speed.

AI makes you start fast, but regret later because you don't have the top speed.

Vibe coding large projects isn’t feasible yet, but as a developer here’s how I use AI to great effect, to the point where losing the tool greatly decreases my productivity:

- Autocomplete in Cursor. People think of AI agents first when they talk about AI coding but LLM-powered autocomplete is a huge productivity boost. It merges seamlessly with your existing workflow, prompting is just writings comments, it can edit multiple lines at once or redirect you to the appropriate part of the codebase, and if the output isn’t what you need you don’t waste much time because you can just choose to ignore it and write code as you usually do.

- Generating coding examples from documentation. Hallucination is basically a non-problem with Gemini Pro 2.5 especially if you give it the right context. This gets me up to speed on a new library or framework very quickly. Basically a stack overflow replacement.

- Debugging. Not always guaranteed to work, but when I’m stuck at a problem for too long, it can provide a solution, or give me a fresh new perspective.

- Self contained scripts. It’s ideal for this, like making package installers, cmake configurations, data processing, serverless micro services, etc.

- Understanding and brainstorming new solutions.

- Vibe coding parts of the codebase that don’t need deep integration. E.g. create a web component with X and Y feature, a C++ function that does a well defined purpose, or a simple file browser. I do wonder if a functional programming paradigm would be better when working with LLMs since by avoiding side effects you can work around their weaknesses when it comes to large codebases.

Code has a lot of bits of information the compiler users to construct the program. But not all because software needs iteration to get right both in bugs and in solving the intended problem.

The llm prompt has even fewer bits of information specifying the system than code. The model has a lot more bits but still finite. A perfect llm cannot build a perfect app in one shot.

However AIs can research, inquire, and iterate to gain more bits than when you started.

So the comparison to a compiler is not apt because the compiler can’t fix bugs or ask the user for more information about what the program should be.

Most devs are using ai at the autocomplete level which is like this compiler analogy which makes sense in 2025 but that isn’t where we will be in 2030.

What we don’t know is how good the technology will be in the future and how cheap and how fast. But it’s already very different than a compiler.

I agree.

I use LLM to do things like brainstorm, explaining programming concepts and debug. I will not use it to write code. The output is not good enough, and I feel dumber.

I only see the worst of my programming collegues coding with AI. And the results are actual trash. They have no actual understanding of the code "they" are writing, and they have no idea how to actually debug what "they" made, if LLM is not helpful. I can smell the technical debt.

These articles are beyond the point of exhausting. Guys, just go use the tools and see if you like them and feel more capable with them. If you do, great, if you don’t, then stop.

> It’s why the world wasted $10B+ on self driving car companies that obviously made no sense. There’s a much bigger market for truths that pump bags vs truths that don’t.

Did geohot not found one of these?

This pre-AI article makes a very similar argument: https://mortoray.com/programming-wont-be-automated-or-it-alr...

Once we realize that what we actually want is turning specifications into software, I think that English will become the base for a new, high level specification language.

AI coding is working really good for us.

My teammate shared 3 phase workflow we are using on our team to deliver project at rapid phase.

It's shared on ClaudeCode subreddit https://www.reddit.com/r/ClaudeCode/s/iy058fH4sZ

I've been using it for months with great success

Instead of everyone telling their personal anecdote, we should look at the actual research.

Asking ChatGPT to summarize the state of AI coding research that’s not done by one of the providers, and I feel like I got the sanest summary of the actual state of things:

> If you weight independent work more heavily: current best evidence says don’t expect speedups for senior devs in complex, well-known codebases without process changes; expect security pitfalls unless you add guardrails. Gains look more reliable for novices, unfamiliar code, and templated tasks

Seems the most sane PoV on the actual benefits I’ve seen.

Actual link if you want to pick apart GPT-5s summary

https://chatgpt.com/share/68c56214-1038-8004-b1ed-359393eb15...

I also had a compiler related description come to me after using Copilot. It allows you to partially generate imperative code declaratively, by writing a comment like

//now I will get rows X, Y, Z from ContentsProvider

then tab tab complete. You can then even tweak the generated code, very useful!

> Or we could, you know, do the hard work and build better programming languages, compilers, and libraries. But that can’t be hyped up for billions.

100% this. I fear that AI will cause us to be stuck in a local optimum for the next decades where most of the code will be Python or JS because these are the languages best supported by LLMs. Don't get me wrong, Python and JS and mature and productive languages. That's fine. But we could have it so much better if there was more effort put into a next generation of tools that take all the harsh lessons learnt from the tools before and "just" do it better. I acknowledge that we get incremental improvements here and there but some things are just unfixable without breaking existing ecosystems.

There is some amount of truth on the AI coding claims.

But, what's with the self driving hate? I take Waymos on a regular basis, and he is basing his credibility on the claim that they are not a thing. Makes him sound bitter more than insightful.

That was a really great read. Not saying I agree with it all, I’m maybe more in the camp that believes AI assisted coding is a time-saver but it’s refreshing (and overdue) to have a counterpoint to the deafening and repetitive drumbeat of the VC-backed hype machine.

Even though I don’t buy that LLMs are going to replace developers and quite agree with what is said, this is more of a critique of LLMs as English-to-code translators. LLMs are very useful for many other things.

Researching concepts, for one, has become so much easier, especially for things where you don’t know anything yet and would have a hard time to even formulate a search engine query.

Just started using Claude Code recently.

It seems to speed up feature development but requires one to have a good understanding of the codebase to guide it and be aware of edge cases it missed.

Also, it doesn't seem to be able to take advantage of latest information or new SDK features unless deliberately informed. Not sure if I'm doing it right, but I resorted to feeding it documentation when it can't seem to something right.

The only thing I'm still unsure is the context management with /compact and /clear

I do agree with many points in the article, but not about the last part, namely that coding with AI assist makes you slower.

Personal experience (data points count = 1), as a somewhat seasoned dev (>30yrs of coding), it makes me WAY faster. I confess to not read the code produced at each iteration other than skimming through it for obvious architectural code smell, but I do read the final version line by line and make a few changes until I'm happy.

Long story short: things that would take me a week to put together now take a couple of hours. The vast bulk of the time saved is not having to identify the libraries I need, and not to have to rummage through API documentation.

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.

>It’s not precise in specifying things.

That's the point - it's a higher level of abstraction.

>highly non-deterministic

...not unlike say a boss telling a junior to change something?

The bet here isn't that AI can be as precise as something hand coded but rather that you can move up a step in the abstraction layer. To use his compiler example...I don't care what the resulting assembly instructions look like, just whether it works. It's the same thing here just one level higher

> It’s why the world wasted $10B+ on self driving car companies that obviously made no sense.

Obviously... in what way? I feel the anti-ai pattern is clear.

Self-driving cars don't work in my city so the whole concept is a hoax. LLMs don't code my proprietary language so it's a bubble.

> From this study (https://arxiv.org/abs/2507.09089)

I can tell this is going to be the most misquoted study in blogs and pop-sci books after the 10,000-hour mastery study. And it's just a preprint!

I agree that most natural languages are a very poor tool to write code specification in.

Specifically, natural language is:

   - ambiguous (LLMs solve this to a certain extent)

   - extremely verbose

   - doesn't lend itself well to refactoring

   - the same thing can be expressed in way too many different ways, which leads to instability in specs -> code -> specs -> code -> specs loops (and these are essential to do incremental work)

Maybe LLMs can be sued to design such a thing ?

he lagged behind that's why.

I stopped reading at this point:

> It’s why the world wasted $10B+ on self driving car companies that obviously made no sense. There’s a much bigger market for truths that pump bags vs truths that don’t.

This reeks of bias-dismissing massive investments as ‘obvious’ nonsense while hyping its own tinygrad as the ‘truth’ in AI coding.

Author is allowed to claim ‘most people do not care to find the truth’ but it’s hypocritical when the post ignores counterpoints, like PyTorch’s dominance in efficient coding benchmarks.

Author doesn’t seem to care about finding the full truth either, just the version that pumps its bag.

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...

ok boomer. its silly to read such generalizations. ai is a tool, and as every other tool it needs the right job and the right user to be useful and productive.

i am not agree with your opinions @realGeorgeHotz

if you know the fundamentals really well. AI coding actually speeds up development process.

source to the article: https://geohot.github.io//blog/jekyll/update/2025/09/12/ai-c...

are you planning to stream it? @ThePrimeagen

X.com: https://x.com/abdibrokhim/status/1966815369441542381

How do we resolve the observable tension here with the fact that self-driving cars are operating right now, relatively successfully, in ten or so major American cities?

Not a billion dollar business yet, maybe, but 300 cars generating five or six figures revenue per year each isn't far off.

(And I say this as someone who is skeptical that totally autonomous cars worldwide will ever be a thing, but you can get to £10Bn far, far before that point. Become the dominant mode of transport in just ONE major American city and you're most of the way there).