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 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 time rather than skill, you can only take on a limited number of challenging things one after another before you get exhausted.
Companies need to realise that AI to go faster is great, but there's still a cognitive impact on the people. A little respite from the hardcore stuff is genuinely useful sometimes. Taking all of that away will be bad for people.
That said, some devs hate the boring easy bits and will thrive. As with everything, individuals need to be managed as individuals.
That makes me think of https://store.steampowered.com/app/2262930/Bombe/ which is a version of Minesweeper where instead of clicking on squares you define (parametric!) rules that propagate information around the board automatically. Your own rules skip all the easy parts for you. As a result, every challenge you get is by definition a problem that you've never considered before. It's fun, but also exhausting.
I remember listening to a talk about Candy Crush and how they designed the game to have a few easy levels in between the hard ones, to balance feeling like you're improving while also challenging players. If all the levels get progressively harder, then a lot of people lose motivation to keep playing.
There's also the fact that, while you're coding the easy stuff, your mind is thinking about the hard stuff, looking things up, seeing how they articulate. If you're spending 100% of your time on hard stuff, you might be hurting these preliminaries.
This makes no sense. Yes, having time to think about the hard part is good, but just because you’re not doing the boilerplate anymore doesn’t mean you can’t do the thinking part anymore! See how absurd it sounds when you actually describe it this way?
I know brilliant people who took up knitting to keep their hands busy while they think over their difficult problems. But that only works if you can knit in your work hours. Sadly, despite clearly improving the productivity of these people, this is a fireable offense in many jobs.
I'm not saying that the only way to think through a hard problem is to work on boilerplate. If you are in a workplace where you can knit, or play table soccer, by all means, and if these help you, by all means, go for it.
What I'm thinking out loud is that if we're dedicating 100% of our time to the hard problems, we'll hit a snag, and that boilerplate may (accidentally) serve as the padding that makes sure we're not at these 100%.
That being said, I'm not going to claim this as a certainty, just an idea.
I don't disagree, but I find a better use of my time is writing. Not code, but essentially a work journal. It's not big thoughts, it's bullet points. It's not documentation, but more of a open mind map: what's been done, what needs to be done, questions that inevitably pop up, etc. I use Obsidian for this, but if I write much more than what would go on a few post-it notes, it's too much.
Writing and coding use different parts of the brain. Writing is for creating a model to communicate about human things, and coding is for creating a model for communicating about computer things.
Sure, but we've all had one of those "ah-ha!" moments when we took ourselves out of the code. I feel like putting yourself in a position when you're thinking big picture is far more useful than hand-coding a routes file or adding validation to a model file.
> Devs often want the inherent safety of the boring, easy stuff for a while.
Part of the problem is that in big orgs, you need to show consistent progress in order to not get put on some PIP and kicked out of the company. There are performance review cycles and you have to show something continuously.
That ONLY works if you have boring, easy work. It's easy to deliver consistent progress on that.
Interesting and difficult work is nice only if you are trusted to try your best and given the freedom to fail. That's the nature of hard problems; progress in those domains is very sudden and Poissonian and not consistent by nature. If you're going to be judged on your ability to be sub-Poissonian and consistent, and get put on a PIP for not succeeding at it one review cycle (and possibly risking income that you use to put a roof over your head or feed your family) it's not worth the career risk to try difficult things.
Not saying this is the way I think, it's just the reality of how things often work in big orgs, and one of the reasons I dislike many big orgs.
> Devs often want the inherent safety of the boring, easy stuff for a while
That's matches my experience. In my first job, every time a new webapp project has been starting it was fun. Not because of challenges or design, but simply because of the trivial stuff done for n-th time - user accounts, login, password reset, admin panel. Probably should have been automated at this point, but we got away with reinventing the wheel each time.
>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 thinking with a kind of faith based gambler's mentality ("maybe if i tell it to think really hard it'll do it right next time...").
The only times ive seen a notable productivity improvement is when it was something not novel that didnt particularly matter if what popped out was shit - e.g. a proof of concept, ad hoc app, something that would naturally either work or fail obviously, etc. The buzz people get from these gamblers' highs when it works seems to make them happier than if they didnt use it at all though.
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.
> 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.
Is it really? Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction. I've seen people describing things as sludge, but they've never learned awk to write a simple script to take care of the work. Or learned how to use their editor, instead using the same pattern they would have with Notepad.
I think it's better to take a step back and reflect on why we're spending time on basic stuff instead. Instead of praying that the LLM will generate some good basic stuff.
If you're not able to review what it generates, you shouldn't be using it (and arguably are the wrong person to be doing the boilerplate work to begin with)
Put differently, I go back to my original comment, where AI is essentially a junior/mid dev that you can express what needs to be done with enough detail. In either case, AI or dev, you'd review and/or verify it.
> Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction.
One could say the same of installing packages in most modern programming languages instead of writing the code from first principles.
> One could say the same of installing packages in most modern programming languages instead of writing the code from first principles.
I disagree, because libraries define an interface with (ideally) precise, reproducible semantics, that you make use of. They provide exactly what the grandparent is saying, namely a formal abstraction. When you have the choice between a library and an LLM, requiring equal effort, the library is clearly preferable.
When an LLM is more time-efficient at a given coding task, it can be taken as an indication of a lack of a suitable library, tooling, or other abstraction for the use case.
>So much of what we write is absolutely low-skill and low-impact, but necessary and labor-intensive.
Ive never found this to be true once in my career.
I know a lot of devs who looked down on CRUD or whatever it was they were doing and produced boilerplate slop though.
Code isnt like pottery. There arent "artisanal" devs who produce lovely code for people to look at like it's a beautiful vase. Good code that is hooked into the right product-market fit can reach millions of people if it works well.
The world was replete with shitty code before AI and mostly it either got tossed away or it incurred epic and unnecessary maintenance costs because it actually did something useful. Nothing has changed on that front except the tsunami of shit got bigger.
I think there are two kinds of uses for these tools:
1) you try to explain what you want to get done
2) you try to explain what you want to get done and how to get it done
The first one is gambling, the second one has very small failure rate, at worst, the plan it presents shows it's not getting the solution you want it to do.
The thing is to understand that a model has "priors" which steer how it generates code. If what you're trying to build matches the priors of the model you can basically surf the gradients to working software with no steering using declarative language. If what you want to build isn't well encoded by the models priors it'll constantly drift, and you need to use shorter prompts and specify the how more (imperative).
In my experience, you need shorter prompts and steering it constantly for any kind of work, novel or not. You can be doing the most basic thing, if you let it iterate long enough, it will start doing something completely stupid. It's really sad watching Gemini CLI debugging something trivial, and trying to change it "one last time" again. Fortunately, Claude is better at this, but you still need to steer it. And try extremely hard not to give it pointers to something you DON'T want it to do, especially if it's easy and in it's training set, because it will so gladly pick it up.
> 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.
That's strange, I've never thought it can be done this way. Normally I'd read the docs, maybe sketch up some diagrams, then maybe take a walk while thinking on how to solve the problem, and by the time I got back to the screen I'd already have a good idea on how to do it.
These days the only difference is that I feed my ideas to a few different LLMs to have "different opinions". Usually they're crap but sometimes they present something useful that I can implement.
This is an interesting take on it. I've been using Cursor at work and notice that days where I have it generate all the "easy parts", I end up feeling much more mentally exhausted than if I spend the day writing everything by hand.
Yes I can see why some devs might prefer the safety of the boring and the familiar stuff. But the employers aren’t going to care about that. They’re going to hire and retain the devs who are more productive in the new era.
On the flip side, there have been lots of times where I personally didn’t have a lot of time to deeply research a topic (read papers, build prototypes of different ideas, etc) due to lack of time and resources. If all of the boring stuff is gone, and building prototypes is also 3x faster maybe what will end up happening is we can now use all of this free time to try lots of different ideas because the cost of exploration has been lowered.
I think you're describing things we already knew long before this era of AI. Less code is better code, and the vast majority of bugs come from the devs who "hate the boring easy bits".
I disagree that this has anything to do with people needing a break. All code eventually has to be reviewed. Regardless of who or what wrote it, writing too much of it is the problem. It's also worth considering how much more code could be eliminated if the business more critically planned what they think they want.
These tensions have existed even before computers and in all professions.
That's crazy to me. I solve problems. I'm not a janitor or tradesman, you bring me in to envision and orchestrate solutions that bring bottom line value. I live to crack hard nuts, if I never have to bother with rigging again I'll be so happy.
The main challenge with any creative effort, including and especially programming, is motivation. "Easy coding" gives you small mental wins that build your dopamine circuits and give you something to chase. When people say that "AI takes the fun out of coding" they mean that they're not getting those rewards anymore. It might make coding easier (though I'm not sure it actually does, ultimately), but in the process it takes away the motivation.
The ones who are excited about this are the ones who are motivated by the product. When AI can whip up some half-baked solution it sure looks like you can focus on the product and "get someone to code it up for you". But unless it's a well-understood and previously executed solution, you're going to run into actual technical problems and have to fix them. But your motivation to deal with the irritating pedantrics of the modern computing stack (which are the same as all technology ever, with orders of magnitude more parts) hasn't been built up. There's no beneficial flywheel, just a fleet of the Sorceror's Apprentice mindless brooms that you hope you can get work enough to ship.
> 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 time rather than skill, you can only take on a limited number of challenging things one after another before you get exhausted.
The issue of senior-juniors has always been a problem; AI simply means they're losing their hiding spots.
I'm just slightly younger than you, but have the exact same sentiment. Hell, even moreso maybe, because what I realized is that "writing code to implement interesting ideas" is not really what I enjoy - it's coming up with the interesting ideas and experimenting with them. I couldn't care less about writing the code - and I only did it because I had to...if I wanted to see my idea come to life.
AI has also been a really good brainstorming partner - especially if you prompt it to disable sycophancy. It will tell you straight up when you are over-engineering something.
It's also wonderful at debugging.
So I just talk to my computer, brainstorm architectures and approaches, create a spec, then let it implement it. If it was a bad idea, we iterate. The iteration loop is so fast that it doesn't matter.
Did you end up regretting a design choice, but normally you'd live with it because so much code would have to be changed? Not with Agentic coding tools - they are great at implementing changes throughout the entire codebase.
And its so easy to branch out to technologies you're not an expert in, and still be really effective as you gain that expertise.
I honestly couldn't be happier than I am right now. And the tools get better every week, sometimes a couple times a week.
> 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'm in the same boat (granted, 10 years less) but can't really relate with this. By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.
The parts in the middle – non-trivial but not big picture – in my experience are the parts where writing the code myself constantly uncovers better ways to improve both the big picture and the automation/generalization. Because of that, there are almost no lines of code that I write that I feel I want to offload. Almost every line of code either improves the future of the software or my skills as a developer.
But perhaps I've been lucky enough to work in the same place for long. If I couldn't bring my code with me and had to constantly start from scratch, I might have a different opinion.
> By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.
The two aren't mutually exclusive. You can use AI to build your tooling. (Unless it's of sufficient complexity or value that you need to do the work yourself)
The time spent on the tooling is very low. Using AI for that would be like renting a flamethrower because couple of times a year I like to go camping and light a fire. I'd rather just use a lighter.
I have a couple of niche areas of non-coding interest where I'm using AI to code. It is so amazing to write rust and just add `todo!(...)` through out the boiler plate. The AI is miserable at implementing domain knowledge in those niche areas, but now I can focus on describing the domain knowledge (in real rust code because I can't describe it precisely enough in English + pseudo code), and then say "fill in the todos, write some tests make sure it compiles, and passes linting", verify the tests check things properly and I'm done.
I've struggled heavily trying to figure out how to get it to write the exactly correct 10 lines of code that I need for a particularly niche problem, and so I've kind of given up on that, but getting it to write the 100 lines of code around those magic 10 lines saves me so much trouble, and opens me up to so many more projects.
I find it best as a "personal assistant," that I can use to give me information -sometimes, highly focused- at a moment's notice.
> The potential for then stunting the growth of actual juniors into tomorrow's senior developers is a serious concern
I think it's a very real problem. I am watching young folks being frozen out of the industry, at the very beginning of their careers. It is pretty awful.
I suspect that the executives know that AI isn't yet ready to replace senior-levels, but they are confident that it will, soon, so they aren't concerned that there aren't any more seniors being crafted from youngsters.
>> developer somewhere between junior and mid-level,
Analogies to humans don't work that well. AI is super-human in some respects while also lacking the ability to continually work toward a goal over long periods of time. AI can do very little on its own - just short / scoped / supervised tasks.
However, sometimes the situation is reversed, AI is the teacher who provides some examples on how to do things or provides hints on how to explore a new area and knows how others have approached similar things. Then, sometimes, AI is an astute code reviewer, typically providing valuable feedback.
Anyway, I've stopped trying anthropomorphize AI and simply try to reason about it based on working with it. That means combinations of direct ChatGPT usage with copy / paste / amend type workflows, async style / full PR style usage, one-shot "hail Mary" type throw away PRs just to establish an initial direction as well as PR reviews of my own code. I'm using AI all the time, but never anything like how I would work with another human.
Exactly. I tend to like Hotz, but by his description, every developer is also "a compiler", so it's a useless argument.
My life quality (as a startup cofounder wearing many different hats across the whole stack) would drop significantly if Cursor-like tools [1] were taken away from me, because it takes me a lot of mental effort to push myself to do the boring task, which leads to procrastination, which leads to delays, which leads to frustration. Being able to offload such tasks to AI is incredibly valuable, and since I've been in this space from "day 1", I think I have a very good grasp on what type of task I can trust it to do correctly. Here are some examples:
- Add logging throughout some code
- Turn a set of function calls that have gotten too deep into a nice class with clean interfaces
- Build a Streamlit dashboard that shows some basic stats from some table in the database
- Rewrite this LLM prompt to fix any typos and inconsistencies - yeah, "compiling" English instructions into English code also works great!
- Write all the "create index" lines for this SQL table, so that <insert a bunch of search usecases> perform well.
[1] I'm actually currently back to Copilot Chat, but it doesn't really matter that much.
That's one of the thing that I wouldn't delegate to LLM. Logging is like a report of things that happens. And just like a report, I need relevant information and the most useful information.
...
A lot of these use cases actually describes the what. But the most important questions is always the why. Why is it important to you? Or to the user? That's when things have a purpose and not be just toys.
Code with logging is "self reporting". Adding logging statements is not reporting itself. Adding `logger.error(f"{job} failed")` is not reporting itself, and LLMs are perfectly capable of adding such statements in applicable places.
As to why, it's because I'm building an app with a growing userbase and need to accommodate to their requirements and build new features to stay ahead of the competition. Why you decided I'm describing a toy project is beyond me.
As someone else said: Launch is only the first step. That's when practicality start to matter.
The reason senior engineers are being paid that well is not because they need to type a lot of code to get new features in. It's because they need to figure how to have less code while having more features.
Exactly. If you know how the whole thing works end to end, AI makes you incredibly dangerous. Anyone who specializes or never really learned how everything works is at a huge disadvantage.
However. There's also good news. AI is also an amazing tool for learning.
So what I see AI doing is simply separating people who want to put effort forth and those who don't.
> However. There's also good news. AI is also an amazing tool for learning.
Absolutely. For example, I've been learning Autodesk Fusion, and after establishing a small foundation through traditional learning techniques, I've been able to turbocharge my learning by asking precise questions to AI.
I image this really sucks for those whose business model relied on gatekeeping knowledge. (like training companies)
I agree. Having AI write your entire application is equivalent to having it write a song for your band, or even generate audio so you don't have to do record it yourself.
If you aren't talented enough to write or record your own music, you aren't really a musician.
If you have a quick question about music theory and you want a quick answer, AI can be a benefit.
This resonates with me. I'm also around the same age and have the same amount of experience.
I love AI and use it for both personal and work tasks for two reasons:
1. It's a way to bounce around ideas without (as much) bias as a human. This is indispensable because it gives you a fast feedback mechanism and validates a path.
2. It saves me typing and time. I give it one-shot, "basic work" to do and it's able to do accomplish at least 80% of what I'd say is complete. Although it may not be 100% it's still a net positive given the amount of time it saves me.
It's not lost on me that I'm effectively being trained to always add guardrails, be very specific about the instructions, and always check the work of AI.
> I can pretty much see projects in my head, and know exactly what to build.
This is where AI actually helps - you have a very precise vision of what you want, but perhaps you've forgotten about the specific names of certain API methods, etc. Maybe you don't want to implement all the cases by hand. Often validating the output can take just seconds when you know what it is you're looking for.
The other part of making the output do what you want is the ability to write a prompt that captures the most essential constraints of your vision. I've noticed the ability to write and articulate ideas well in natural language terms is the actual bottleneck for most developers. It takes just as much practice communicating your ideas as it does anything else to get good at it.
Yes, unfortunately the boring parts are what junior devs used to do so the senior devs could work on the good stuff. Now that AI is doing the boring stuff nobody has to hire those pesky jr developers anymore. Yay?
The problem is that junior developers are what we make senior developers with— so in 15 years, this is going to be yet another thing that the US used to be really good at, but is no longer capable of doing, just like many important trades in manufacturing. The manufacturers were all only concerned with their own immediate profit and made the basic sustainability of their workforce, let alone the health of the trades that supported their industries, a problem for everyone else to take care of. Well, everyone else did the same thing.
And nobody is obligated to make sure they aren’t walking off of a cliff.
Most people don’t share your confidence that we will replace senior engineers and I’d gobsmacked if we could. Just like the magical ‘automation’ can’t replace the people that actually make the physical things that the machines use to do their jobs, or fix the machines, no matter how good it gets. But the quantitatively-minded MBAs just kept kicking the can down the road and assumed it was someone else’s problem that the end of the road was approaching. It wasn’t their problem that there would be a problem in 30 years, and then it wasn’t their problem when it was 10 years, and now that we’re standing at the edge of a cliff, they’re realizing that it’s everybody’s problem and it’s going to be a hell of a lot more painful than if they’d had an extremely modest amount of foresight.
Now, US manufacturers are realizing that all of their skilled laborers are retiring or dying, and there isn’t enough time to transfer the more complex knowledge sets, like Tool and Die making, to a new set of apprentices. Many of these jobs are critical not only to national security, but also our country’s GDP because the things we do actually make are very useful, very specialized, and very expensive. Outsourcing jobs like making parts for fighter jets is really something we don’t want shipped overseas unless we want to see those parts pop up on aliexpress. If nobody is responsible for it and nobody wants to fund the government to fix it, but it is a real problem, it doesn’t take a genius to see the disconnect there.
It’s yet another place where we know our own capacity as a society is shrinking and hoping that ??? (Ai? Robots? Fusion?) will fix it before it’s too late. I never thought programming would join elder-care in this category though, that came as a surprise.
Most of my work is for my employer, but the bigger point is that you wouldn't be able to tell my "AI work" from my other work because I primarily use it for the boring stuff that is labor-intensive, while I work on the actual business cases. (Most of my work doesn't fall under the category of "web application", but rather, backend and background-processing intensive work that just happens to have an HTML front-end)
Yes, I wrote my own DSL, complete with BDD testing framework, to write my blog with. In Rust!
GET /hello/:world
|> jq: `{ world: .params.world }`
|> handlebars: `<p>hello, {{world}}</p>`
describe "hello, world"
it "calls the route"
when calling GET /hello/world
then status is 200
and output equals `<p>hello, world</p>`
100% agree. I am interested in seeing how this will change how I work. I'm finding that I'm now more concerned with how I can keep the AI busy and how I can keep the quality of outputs high. I believe it has a lot to do with how my projects are structured and documented. There are also some menial issues (e.g. structuring projects to avoid merge conflicts becoming bottlenecks)
I expect that in a year my relationship with AI will be more like a TL working mostly at the requirements and task definition layer managing the work of several agents across parallel workstreams. I expect new development toolchains to start reflecting this too with less emphasis on IDEs and more emphasis on efficient task and project management.
I think the "missed growth" of junior devs is overblown though. Did the widespread adoption of higher-level really hurt the careers of developers missing out on the days when we had to do explicit memory management? We're just shifting the skillset and removing the unnecessary overhead. We could argue endlessly about technical depth being important, but in my experience this hasn't ever been truly necessary to succeed in your career. We'll mitigate these issues the same way we do with higher-level languages - by first focusing on the properties and invariants of the solutions outside-in.
An important skill for software developers is the ability to reason about what the effects of their coce will be, over all possible conditions and inputs, as opposed to trial and error limited to specific inputs, or (as is the case with non-deterministic LLMs) limited to single executions. This skill is independent of whether you are coding in assembly or are using higher-level languages and tooling. Using LLMs exactly doesn’t train that skill, because the effective unpredictability of their results largely prevents any but the most vague logical reasoning about the connection between the prompt and the specific output.
I actually think this is one skill LLMs _do_ train, albeit for an entirely different reason. Claude is fairly bad at considering edge cases in my experience, so I generally have to prompt for them specifically.
Even for entirely “vibe-coded” apps I could theoretically have created without knowing any programming syntax, I was successful only because I knew about possible edge cases.
> I love AI for speed running through all the boring stuff and getting to the good parts.
But the issue is some of that speedrunning sometimes takes so much time, it becomes inefficient. It's slowly improving (gpt5 is incredible), but sometimes it get stuck on really mundane issue, and regress endlessly unless I intervene. And I am talking about straightforwars functional code.
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.
> I can pretty much see projects in my head, and know exactly what to build.
I think you’re the best case support for AI coding. You know clearly what you want, so you know clearly what you don’t want. So if you had decent verbal dexterity you could prompt the AI model and manage to accomplish what you intended.
A lot of programming problems / programmer contexts don’t match that situation. Which is the problem with universalizing the potency of AI / benefits of AI coding.
same. 50’s, coding since the 90’s, make more $$ than I can spend in 3 lifetimes. one constant thing in my 3 decade career has been that absolute best people I worked with all had one common thread - absolute laziness. sounds strange but every other trait of a great SWE has not been universal except laziness.
the laziness manifest itself into productivity as crazy as this sounds. how? lazy people find a way to automate repetitive tasks. what I have learned from these over the years is that anything you do twice has to find a way to be automated as third time is around the corner :)
what does this have to do with AI? the AI has taken automation to another level allowing us to automate so much of our work that was not previously possible. I found myriad of ways to use AI and several of my best (lazy) co-workers have as well. I cannot imagine doing my work anymore without it, not because of any “magic” but because my lazy ass will be able to do all the things that I have automated out
Yes! Once I've figured out that this problem is best solved using parser combinators, and that I have a good idea of how to model the transformation, I'm so glad I can delegate work to the LLM code gen and focus on the specification, test cases, corner cases, etc;
I don't think thats contrary to the article's claim: the current tools are so bad and tedious to use for repetitive work that AI is helpful with a huge amount of it.
That‘s exactly why i like AI too. I even let them play roles like „junior dev“, „product owner“ or „devops engineer“ and orchestrate them, to play together as a team - with guidance from me (usually the „solution architect“ or „investor“)! This „team“ achieves in weeks what we usually needed months for - for 2.40€/h*role!
I have a similar relation to AI with programming -- and my sense is very many HN readers do as well, evidenced not least by the terrific experience report from antirez [1]. Yet it is rare to see such honest and open statements even here. Instead, HN is full of endless anti-AI submissions on the front page where the discussion underneath is just an echo chamber of ill-substantiated attacks on 'AI hype' and where anything else is down-voted.
It's what is, to me, so bizarre about the present moment: certainly investment is exceptionally high in AI (and of course use), but the dominant position in the media is precisely such a strange 'anti-AI hype' that positions itself as a brave minority position. Obviously, OpenAI/Altman have made some unfortunate statements in self-promotion, but otherwise I genuinely can't think of something I've read that expresses the position attacked by the anti-AI-ers -- even talk of 'AGI' etc comes from the AI-critical camp.
In a sense, the world seems divided into three: obvious self-promotion from AI companies that nobody takes seriously, ever-increasingly fervent 'AI critique', and the people who, mostly silent, have found modern AI with all its warts to be an incomparably useful tool across various dimensions of their life and work. I hope the third camp becomes more vocal so that open conversations about the ways people have found AI to be useful or not can be the norm not the exception.
It’s hard to see how the current rate of progress is compatible with, 30 years from now, it being good business sense to pay human professionals six figure salaries. Opinions then split: the easiest option is pure denial, to assume that the current rate of progress doesn’t exist. Next easiest is to assume that progress will halt soon, then that we will be granted the lifestyle of well paid professionals when unsupervised AI can do our job for cheaper, then that Altman will at least deign to feed us.
antirez's success doesn't mean anything since antirez is far, far above average as a developer and is able to wield AI very effectively because of his talents and knowledge. Most developers are not remotely close to antirez's skill level (half are below average, by definition) and are likely going to suffer the problems that skeptics are already seeing.
> developer somewhere between junior and mid-level
Why the insistence on anthropomorphizing what is just a tool? It has no agency, does not 'think' in any meaningful manner, it is just pattern matching on a vast corpus of training data. That's not to say it can't be very useful - as you seem to have found - but it is still just a tool.
This isn’t necessarily anthropomorphizing, as from a company’s point of view, or uncharitably even from a tech leads point of view, developers are also just tools. The point being made is that LLMs (supposedly) fulfill those developer roles.
It's less about what the tool is, and more about the kind of work we often assign to less experienced developers. Pattern matching in meatspace is still pattern matching.
The difference is AI is closing on doing the EXACT work with the EXACT info as a junior dev. Give an LLM a Jira ticket and a codebase and it can push a PR. Spreadsheets are great, but that was a tool that minimized effort but didn't remove it. LLMs can directly replace a remote junior with no visible difference already.
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 surprised to see this. From my perspective, reading comments and seeing which posts rise to the top, HN as a whole seems pretty bullish on the tech as whole…
I think there might also just be a vocal minority and/or some astroturfing hyping AI coding around hackernews. I personally keep trying all the latest shit and always stop using it, because it actively slows me down.
It’s changing over time. When copilot came out a few years ago, people were very against it due to it being trained oh GitHub codebase. Now there’s more support around it.
We don't want to admit it but HN has similar characteristics as many other platforms; echo chamber / group think. You see it over and over again.
HN participants (generally speaking) are against: AI, Crypto, HFT. I've worked in 2/3 of these industries so have first hand experience. My basic summary is that the average commenter here has a lot of misinformation on these topics (as a insider).
It also seems wildly inconsistent for someone who founded a self driving company. If models can't write code, which is a very constrained problem space, how are they supposed to drive?
I don’t know. He covers this pretty early in the post.
> The only reason it works for many common programming workflows is because they are common. The minute you try to do new things, you need to be as verbose as the underlying language.
You've seen plenty of people who hacked the ps3 and iphone as teenagers and created a low level system analysis tool for doing such system hacks? You've seen plenty of people writing self driving car software a decade ago? Why did you write this when you know nothing?
I actually have seen plenty of people that could have done something like this, but did not because they simply never tried. Being daring by itself is a skill, but we're talking raw technical ability here.
I've actually seen another developer that was probably in the same category write his own self-driving software. It kind of worked, but couldn't have ever been production ready, so it was just an exercise in flexing without any practical application.
So, what product that George built do you actually use?
> you've seen plenty of people that didn't do what he did?
Yes, because I've seen them build software that was actually used. And I've seen a few that did just like him, impressive sounding projects that had no usage.
I understand it's something subjective. I get the same feeling when looking at Damien Hirst's monstrouly expensive stuff that leaves me cold. Even after I get the concepts behind the works, my end feeling is of "so what?".
For the comment above, the more relevant denominator is all humans vs. all developers. If you use all humans as the denominator, he's easily in the top 1% or 0.001% (I haven't followed his work closely, but you'd only have to be a good dev to be in top 1% of the global population).
Thank you, perhaps I worded it harshly, but that was my general feeling. Being a good developer already is a high level. Being able to start impressive-sounding projects that never materialize into anything is a luxury for which most competent developers simply don't have the extra energy.
"The best model of a programming AI is a compiler... You give it a prompt, which is “the code”, and it outputs a compiled version of that code. Sometimes you’ll use it interactively, giving updates to the prompt after it has returned code, but you find that, like most IDEs, this doesn’t work all that well and you are often better off adjusting the original prompt and “recompiling”."
I think his excellency in his own trade limited his vision for the 99% who just want to get by in the job. How many dev even deal with compiler directly these days? They write some code, fix some red underlines, then push, pray and wait for pipeline pass. LLMs will be gods in this process, and you can even beg another one if your current one does not work best.
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.
Author here. I agree with this comment, but if I wrote more like this my blog post would get less traction.
"LLM coding tools are search-based program synthesizers," in my mind this is what compilers are. I think most compilers do far too little search and opt for heuristics instead, often because they don't have an integrated runtime environment, but it's the same idea.
"Plenty of effective engineering tools are stochastic," sure but while a SAT solver might use randomness and that might adjust your time to solve, it doesn't change the correctness of the result. And for something like a fuzzer, that's a test, which are always more of a best effort thing. I haven't seen a fuzzer deployed in prod.
"Determinism comes from external specs and tests," my dream is a language where I can specify what it does instead of how it does it. Like the concept of Halide's schedule but more generic. The computer can spend its time figuring out the how. And I think this is the kind of tools AI will deliver. Maybe it'll be with LLMs, maybe it'll be something else, but the key is that you need a fairly rigorous spec and that spec itself is the programming. The spec can even be constraint based instead of needing to specify all behavior.
I'm not at all against AI, and if you are using it at a level described in this post, like a tool, aware of its strengths and limitations, I think it can be a great addition to a workflow. I'm against the idea that it's a magical English compiler, which is what I see in public discourse.
I think the key insight I walked away with from this whole thread, for me, was:
A compiler takes source and maps it to some output. Regardless of the compiler detail, this is an atomic operation; you end up with source (unmodified) and an artifact.
These “agent workflows” are distinctly different.
The process of mapping prompt to an output is the same; but these agent workflows are destructive; they modify the source.
Free reign over the entire code base; They modify the tests. The spec, the implementation.
It seems like this is a concept people are still struggling with; if your specification is poorly defined, and is dynamically updated during the compilation process, the results are more than just non deterministic.
Over time, the specification becomes non deterministic.
Thats why unsupervised agents go “off the rails”; not because the specification cant be executed, but because over time the spec drifts.
This is bait. The comment and the blog post say mostly the same thing, the debate is around the subtle edges.
It's not a "compiler," it's a "probabilistic code synthesizer guided by your constraints"
The latter is technically more specific and correct than the former, but it's 7 words instead of 1. And the word compiler is understood to encompass the latter, even if most compilers aren't that. They are both "a tool in a workflow"
People knock "English as a programming language", but in my opinion this is the whole value of AI programming: by the time you've expressed your design and constraints well enough that an LLM can understand it, then anyone can understand it, and you end up with a codebase that's way more maintainable than what we're used to.
The problem of course is when people throw away the prompt and keep the code, like the code is somehow valuable. This would be like everyone checking in their binaries and throwing away their source code every time, while arguments rage on HN about whether compilers are useful. (Meanwhile, compiler vendors compete on their ability to disassemble and alter binaries in response to partial code snippets.)
The right way to do AI programming is: English defines the program, generated code is exactly as valuable as compiler output is, i.e. it's the actual artifact that does the thing, so in one sense it's the whole point, but iterating on it or studying it in detail is a waste of time, except occasionally when debugging. It's going to take a while, but eventually this will be the only way anybody writes code. (Note: I may be biased, as I've built an AI programming tool.)
If you can explain what needs to be done to a junior programmer in less time than it takes to do it yourself, you can benefit from AI. But, it does require totally rethinking the programming workflow and tooling.
I don't think that a prompt can be a valuable object, similar to how code used to be. Unless Mira Murati is successful at scaling her approach to deterministic inference, a prompt is fragile and transient. And even if she is successful, LLM updates make a prompt much less useful over longer time horizons.
I think that the only useful objects to keep right now are DSPy programs together with well-crafted examples, with examples being the most valuable because they are transferable across models and architectures.
I also noticed several people in the thread comparing coding assistants to junior programmers. I disagree. The only parallel is that they will do what you tell them to. Otherwise, a coding assistant can hold an entire codebase in context, reason across patterns, and generate boilerplate faster than any human. That capability has no human analogue. And unlike a junior, they have no agency, so the comparison breaks down on multiple fronts.
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.
I think this comes down to levels of intelligence. Not knowledge, I mean intelligence. We often underestimate the amount of thinking/reasoning that goes into a certain task. Sometimes the AI can surprise you and do something very thoughtful, this often feels like magic.
Both CRUD and boilerplate are arguably a tooling issue. But there are also a bunch of things only AI will let you do.
My tests with full trace level logging enabled can get very verbose. It takes serious time for a human to parse where in the 100 lines of text the relevant part is.
Just telling an AI: "Run the tests and identify the root cause" works well enough, that nowadays it is always my first step.
Yesterday I used Opus to diagnose an error and it sent me down a bunch of wrong paths, suggested fixes with bad unintended consequences. If I hadn’t carefully guided it and corrected it, not only would the bug not have been fixed but it would have made things worse. My point being that if you don’t have the domain knowledge and put on your thinking cap then you will likely be screwed. But this is not how AI is sold.
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.
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!
It was such a great study imo and rightfully deserves a lot of attention since it's a great alternative to twitter vibes.
But to stop here and say AI coding doesn't work will just not hold up well. We have a sample size of 16 developers for 250 tasks.
Here is my data point: adding AI to your engineering team really is like adding a new member. At first it slows everybody down: explain this, explain that, stupid mistake made that the experienced dev would have avoided. But over the months you learn how to get the most out of them: they speak fluently all programming languages, don't mind writing 20 tests or coming up with good industry ideas to your problems.
Over time I have come to appreciate that the market is rather smart and even hype has its place. You often have to cross a line to know you crossed it, especially with something as fuzzy and quickly changing as technological progress hitting the messy real world. But then again, we need the heretics to stay smart and not follow an emperor without clothes.
Just putting this up as a reference the next time this comes up on HN. The study data shows that the median task is 1.5hrs and the 15 minutes that developers think they saved was actually more than that many minutes less researching, testing, and writing code and the 15 minutes longer they actually spent was more idle (5mins) and waiting for AI (5 mins) and reviewing and prompting dominating their work over actually writing code.
The person who showed a speed-up indicated over a week of prior experience with cursor while all others under a week.
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.
I feel the same way. After 30+ years coding, I know what I want to build, but finding the time to work on it and the focus is harder than it used to be.
I feel like many opinion pieces on AI coding are written from the perspective of highly experienced software engineers, often from a kind of ivory tower. (even that study they cite was based on “16 experienced open-source developers.”)
But for people who aren’t seasoned coders, these tools are incredibly valuable. I have some coding experience myself, but it’s never been my profession (I’m a visual artist). Now, I can accomplish in an afternoon what would otherwise take me days. Two months ago I left my job to work solo on my video game, and even though my budget is limited, I still make sure to keep Claude and ChatGPT. Also, being able to write something on my phone at 1 a.m. when I can’t sleep, send it to Codex, and then test it first thing in the morning at my computer feels pretty magical. It also takes away the worry of “what if this isn’t the best way to do it?” since refactoring parts of my codebase is now so easy. It helps not just with writing code, but also with removing the fear that might otherwise keep me from sitting down and getting the work done.
That said, I understand that much of the criticism is really aimed at the marketing hype around these tools and the broader “this will replace the engineers at your company” narrative.
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.
But what about the tests usefulness? Tests enforce contracts, contracts are about the domain, not the implementation. The number of tests don't actually matter as much as what is being actually verified. If you look at the code to know what to tests, you are doing it wrong.
The usefulness is in saving time boilerplating, plus figuring out tests I may not have thought of.
But I do closely review the code! It turns the usual drudge of writing tests into more of a code review. Last time I did it it had some mistakes I needed to fix for sure.
I'm not disagreeing per se, but in my experience my tests are so disposable they're never worth investing that much engineering effort in past getting them to pass
> 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.
I’m someone with ADHD who takes prescribed stimulants and they don’t make me work faster or smarter, they just make me work. Without them I’ll languish in an unfocused haze for hours, or zone in on irrelevant details until I realise I have an hour left in the day to get anything done. It could make me 20% less intelligent and it would still be worth it; this is obviously an extreme, but given the choice, I’d rather be an average developer that gets boring, functional code done on time than a dysfunctional genius who keeps missing deadlines and cannot be motivated to work on anything but the most exciting shiny new tech.
I have family that had ADHD, as a kid (they called it “hyperactivity,” back then). He is also dyslexic.
The ADHD was caught early, and treated, but the dyslexia was not. He thought he was a moron, for much of his early life, and his peers and employers did nothing to discourage that self-diagnosis.
Since he learned of his dyslexia, and started treating it, he has been an engineer at Intel, for most of his career (not that I envy him, right now).
You have to realize that ADD meds are meant only for people with ADD, not healthy people at the prime of their life. Excess neurochemicals can have the opposite effect.
Their benefits when used as intended are solidly documented in research literature.
It’s interesting how science can become closer to pseudoscience than proper research through paper-milling.
It seems like that with such small groups and effects you could run the same “study” again and again until you get the result that you initially desired.
It's very easy to find studies that prove that Adderall (etc.) improve non-ADHD people's cognition ability. And it's equally easy to find studies that prove otherwise. The parent comment is very spot on. You can find evidence supporting anything nowadays.
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 better on their own. I haven’t met a single one that actually had their productivity decline (after an adjustment period, of course), after giving up Adderall. In fact, I know several, that have had their careers really take off, after giving it up.
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.
I don't think that it matters, in this context, as a lot of folks here, have their minds made up, already, and won't let anything interfere.
They'll need to learn, the same way I see lots of people learn.
It's been around long enough, though, that all the Adderall-eating people should have established a Gattaca-like "elite," with all us "undermen," scrabbling around at their feet.
As someone with diagnosed ADHD, and prescribed something similar:
It's not that they make you superhuman - I don't think I'm any "smarter" on them. It's just that without them, my "productive" bursts would be at really random times (11PM or 2AM), and make it very hard to fit into a "normal" schedule with the rest of society (I would frequently fall asleep in classes or meetings).
So it's more that it allows you to "rearrange" the same (or slightly larger) amount of work but into a more reasonable, traditional schedule. And for certain things, helps more than that. But it's not a miracle drug by any means.
I had a problem client that I ended up firing and giving money back to about 15 years ago. Lot of red flags, but the breaking point was when they offered me adderall so I could "work faster".
That said, I'll leave the conclusions about whether it's valuable for those with ADHD to the mental health professionals.
Adderall is not Ritalin. They may both be stimulants, but they are different. They have different active ingredients, mechanisms of action, durations of action. Not really that similar in my experience. Ritalin is kind of weak, honestly.
>I’m pretty familiar with the illusion of productivity
II do not have ADHD and I'm familiar with successfully using Aderrall for actual productivity. YMMV. Turns out not everyone's brain chemistry is the same.
Kind of surprised by this take - I use openpilot often and also use claude code.
I kind of consider them the same thing. Openpilot can drive really well on highways for hours on end when nothing interesting is happening. Claude code can do straight forward refactors, write boilerplate, do scaffolding, do automated git bisects with no input from me.
Neither one is a substitute for the 'driver'. Claude code is like the level 2 self driving of programming.
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.
what is the cost of enabling someone to create little pieces of software if he otherwise wouldn't? I'm no advocate of vibe coding serious commercial software, but to do little DIY stuff - absolutely.
No one is forbidding people creating little pieces of software.
But creating little pieces of software was already available, for example I make most of my DIY software in a spreadsheet.
There are tons upon tons of low code possibilities or already existing software packages that need a bit of configuration that one can use and using AI or LLM's is not bringing anything that is revolutionizing access to computation or tailoring software. Just get your head around Excel or LibreOffice Calc and most of your DIY software needs are covered.
What LLM's and AI is bringing to the table is illusion of being able to create software exactly like people who have all the theoretical background or experience in building it. (which seems the person I originally replied to be one of those)
So as my original comment the problem is: that people building a forest hut are convinced that only if they just put more sticks on top, they will manage to build a skyscraper.
I'm so confused. So now you're an elitist gatekeeper to the world of programming? I entered w/o knowledge, and my apps are pretty useful to myself and some others.
They're not "little pieces of software". They are fully-working, self-contained, apps with lots of unique code. Some are better than many apps that existed 10 years ago, but you seem to resent that. Also, whatever you do is relatively "high-level" programming on top of the work of those who created hardware and engineered programming languages, compilers and SDKs.
its awesome and fun but people throwing shit they dont understand how it 100% works online is a tale as old as people paying attention. which apprentnly isnt that long. fuck off
> I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me.
This describes me pretty well too, though I do have a tiny bit of programming experience. I wrote maybe 5000 lines of code unassisted between 1995-2024. I didn't enjoy it for the most part, nor did I ever feel I was particularly good at it. On the more complex stuff I made, it might take several weeks of effort to produce a couple hundred lines of working code.
Flash forward to 2025 and I co-wrote (with LLMs) a genuinely useful piece of back office code to automate a logistics problem I was previously solving via a manual process in a spreadsheet. It would hardly be difficult for most people here to write this program, its just making some API calls, doing basic arithmetic, and displaying the results in a TUI. But I took a crack at it several times on my own and unfortunately between the API documentation being crap and my own lack of experience, I never got to the point where I could even make a single API call. LLMs got me over that hump and greatly assisted with writing the rest of the codebase, though I did write some of it by hand and worked through some debugging to solve issues in edge cases. Unlike OP, I do think I reasonably well understand what >90% of the code is doing.
> 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.
So yeah, to the people here saying the above sentiment is BS - its not. For people who have never worked in programming or even in tech, these tools can be immensely useful.
I think it's like CMS and page builders enabling people to build their own websites without html and server knowledge. They're not making web developers disappear, instead there are more web developers now because those some of those people would eventually outgrow their page builders and need to hire web developers.
This is the optimistic view that I see around. I go back and forth. I've had some work that was the result of "vibe coders" hitting a wall with its capabilities.
Apps running locally can also be subject to security issues. What you're trying to say is probably "apps not using untrusted input". If an app takes no input all, I guess we could say that security isn't an issue, but there could still be safety issues.
It’s a pretty good solution for creating live mockups. A designer on my team came back eight hours after a meeting with a fully vibe coded, multi-page interface. I was honestly blown away. I had no idea this was the state of what’s possible with these tools.
Was it a real website? No, but it’s a live mockup way better than any Figma mock or rigid demo-ware.
I could say the same for lots of non-vibe-coded apps. Have you considered that modern vibe-coding can easily produce apps that look better than anything from 20 years ago thanks to all the modern frameworks? Heck, one-shotting a GUI or website will yield better-looking results than anything published by Debian or FreeBSD, lol.
The Internet is awash with people making the same claims you are, but where are the actual results that we can see and use? Where are all these supposed new programs that were only possible to make because of generative ai? The number of new apps in the app store is flat. Still getting the same amount in 2025 as in 2022.
App-store listing is a whole other animal. I don't care to go through all that just to share my app. I also don't care to resolve every technical issue others experience.
Every time I've thought about generating revenue by selling my apps, two thoughts come to mind: my code is not professional-grade, and the field is so competitive than within months a professional will likely create a better app so why pollute the web with something subpar.
The hacker on the street corner isn't distributing his "secret sauce" because it wouldn't meet standards, but it works well for him, and it was cheap/free.
Sounds like were getting at something in the conversation. For the professional developer generative ai is another tool, making us maybe a bit more capable than before. For the amateur it is a breakthrough enabling amateurs to tackle things that are wildly more ambitious than what they could before. But it's still amateur just-good–enough–for-personal-use software. Productising software is still 90% of the work of professional software development, and this is why we're not seeing a jump in the amount of for-sale software. What numbers should we track for the amount of amateur software? One number I have seen is that the npm downloads of React have jumped a lot in the last year. What this tells us about what additional stuff people are doing with React I don't know.
Valid inquiry. In relative terms I'm the Indian on a street corner who hacks things together using tools professionally designed by others. Among the repos I've chosen to publicly share: https://github.com/sm18lr88
> Don't ask me how they work; they just do. Sure the engineering may be abysmal, but it's good enough to work.
I've worked on several projects from a few different engineering disciplines. Let me tell you from that experience alone, this is a statement that most of us dread to hear. We had nothing but pain whenever someone said something similar. We live by the code that nothing good is an accident, but is always the result of deliberate care and effort. Be it quality, reliability, user experience, fault tolerance, etc. How can you be deliberate and ensure any of those if you don't understand even the abstractions that you're building? (My first job was this principle applied to the extreme. The mission demanded it. Just documenting and recording designs, tests, versioning, failures, corrections and even meetings and decisions was a career in itself.) Am I wrong about this when it comes to AI? I could be. I concede that I can't keep up with the new trends to assess all of them. It would be foolish to say that I'm always right. But my experience with AI tools hasn't been great so far. It's far easier to delegate the work to a sufficiently mentored junior staff. Perhaps I'm doing something wrong. I don't know. But that statement I said earlier - it's a fundamental guiding principle in our professional lives. I find it hard to just drop it like that.
> But the article is highly opinionated. It's like saying only phD's can be called scientists, or only programmers can be computer hackers.
Almost every single quality professional in my generation - especially the legends - started those pursuits in their childhood under self-motivation (not as part of school curriculum even). You learn these things by pushing your boundary a little bit every day. You are a novice one day. You are the master on another. Are you absolutely pathetic at dancing? Try ten minutes a day. See what happens in ten years. Meanwhile, kids don't even care about others' opinion while learning. Nobody is gatekeeping you on account of your qualifications.
What they're challenging are the assumptions that vibe/AI coders seem to hold, but don't agree with their intuition. They are old fashioned developers. But their intuitions are honed over decades and they tend be surprisingly accurate for reputed developers like Geohotz. (There are numerous hyped up engineering projects out there that made me regret ignoring my own intuition!) It's even more valid if they can articulate their intuition into reasons. This is a very formal activity, even if they express them as blog posts. Geohotz clearly articulates why he thinks that AI copilots are nothing more than glorified compilers with a very leaky specification language. It means that you need to be very careful with your prompts, on top of tracking the interfaces, abstractions and interactions that the AI currently doesn't do at all for you. Perhaps it works for you at the scale you're trying. But lessons like the Therac-25 horror story [1] always remind us how bad things can go wrong. I just don't want to put that extra effort and waste my time reviewing AI generated code. I want to review code from a person whom I can ask for clarifications and provide critiques and feedback that they can follow later.
I'm 72, a dev for 40 years. I've lost a step or two. It's harder to buckle down and focus, but using AI tools have enabled me to keep building stuff. I can spec a project, have an agent build it then make sure it works. I just code for fun anyway.
I love using AI to prototype that something is possible then go and build it myself while borrowing bits from that initial MVP. The other night I wanted to build a browser extension that could intercept requests from a tab, claude got me something working in about 10 minutes with a couple prompts and a local storage session and then I toyed with the UI a bit to see what was possible.
Now after a weekend morning I have something much slimmer, predictable and sophisticated running... my extension shows a list of repeated responses and I can toggle which one to send to a localhost api that has a simple job queue to update a sqlite db with each new entry, extract the important parts and send it to my lm studio gpt oss 20b endpoint for some analysis and finally and send me a summary on telegram.
I know what I want in my head but cutting down the experimenting or PoC step down to minutes vs hours is pretty useful and as a competent enough dev it's elevated what I can get done now so I can take on more work than I would have by myself previously.
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).
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.
The truth will emerge naturally through labor market competition in the long-run. You do you. I will be using these tools extensively. Good luck out there in the arena.
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.
I agree. I think a better analogy than a compiler is a search engine that has an excellent grasp of semantics but is also drunk and schizophrenic.
LLMs are really valuable for finding information that you aren't able to formulate a proper search query for.
To get the most out of them, ask them to point you to reliable sources instead of explaining directly. Even then, it pays to be very critical of where they're leading you to. To make an LLM the primary window through which you seek new information is extremely precarious epistemologically. Personally, I'd use it as a last resort.
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.
> Personal experience (data points count = 1), as a somewhat seasoned dev (>30yrs of coding), it makes me WAY faster.
> 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.
One of these is not true.
With libraries, it's either you HAVE to use it, so you spend time being acquainted with it (usually a couple hours to make sense of its design, the rest will come on a needed basis) or you are evaluating multiple ones (and that task is much quicker).
> you are evaluating multiple ones (and that task is much quicker).
Of course the latter. And of course I ask the AI to help me select a libray/module/project/whatever that provides what I need. And I ask the AI to classify them by popularity/robustness. And then I apply whatever little/much I know about the space to refine the choice.
may go as far as looking at examples that use the API. And maybe rummage through the code being the API to see if I like what I see.
The whole thing is altogether still way faster than having to pick what I need by hand with my rather limited data ingestion capabilities.
And then, once I've picked one, connecting to the API's is a no-brainer with an LLM, goes super fast.
By the author's implied definition of compiler, a human is also a compiler. (Coffee in, code out, so the saying goes.)
But code is distinct from design, and unlike compilers, humans are synthesizers of design. LLMs let you spend more time as system architect instead of code monkey.
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.
Waymo's driving people around with an injuries-per-mile rate that's lower than having humans do it. I don't see how that reconciles with "obviously made no sense".
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.
I expect much of this can be solved with better architecture: smaller, more independent components. Break large code bases up into independent libraries, and LLMs can work again because they need much less code in their context.
Suggesting I restructure my code base to work better with a non-deterministic black box feels like an instance of Conway’s law[1] that should be avoided.
You’re free to avoid it but maybe your competition will do it and may outpace you because of it. Conways law just states that architecture follows organizational structure so it’s only to be expected that ai generated software has an ai influenced architecture.
Yes, I think that’s the other position. But my bet is that significant software projects built today on today’s LLMs will be outpaced by teams in the future who avoided delegating that complexity to them. It’s a bet, but perhaps it’s wrong.
People repeating articles or papers. I know myself. I know from my own experiences what the good and bad of practice A or database B is. I don't need to read a conclusion by some Muppet.
Chill. Interesting times. Learn stuff, like always. Iterate. Be mindful and intentional and don't just chase mirrors but be practical.
The takeaway from the paper is you don’t know yourself. It’s one paper, and a small sample size, but attempting to refute its conclusion by stating it’s false doesn’t really get us anywhere.
Lol. Maybe you need enough experience to understand if you think "it's written in a paper" is proof of anything, specially over the experience of people who do actual work and have been profilic over long periods.
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.
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 the chief reason I don't use integrations. I just use chat, because I want to physically understand and insert code myself. Else you end up with the code overtaking your understanding of it.
Yes. I'm happy to have a sometimes-wrong expert to hand. Sometimes it provides just what I need, sometimes like with a human (who are also fallible), it helps to spur my own thinking along, clarify, converge on a solution, think laterally, or other productivity boosting effects.
I’m experiencing something similar. We have a codebase of about 150k lines of backend code. On one hand, I feel significantly more productive - perhaps 400% more efficient when it comes to actually writing code. I can iterate on the same feature multiple times, refining it until it’s perfect.
However, the challenge has shifted to code review. I now spend the vast majority of my time reading code rather than writing it. You really need to build strong code-reading muscles. My process has become: read, scrap it, rewrite it, read again… and repeat until it’s done. This approach produces good results for me.
The issue is that not everyone has the same discipline to produce well-crafted code when using AI assistance. Many developers are satisfied once the code simply works. Since I review everything manually, I often discover issues that weren’t even mentioned. During reviews, I try to visualize the entire codebase and internalize everything to maintain a comprehensive understanding of the system’s scope.
I'm very surprised you find this workflow more efficient than just writing the code. I find constructing the mental model of the solution and how it fits into existing system and codebase to be 90% of effort, then actually writing the code is 10%. Admittedly, I don't have to write any boilerplate due to the problem domain and tech choices. Coding agents definitely help with the last 10% and also all the adjacent work - one-off scripts where I don't care about code quality.
I doubt it actually is. All the extra effort it takes to make the AI do something useful on non trivial tasks is going to end up being a wash in terms of productivity, if not a net negative. But it feels more productive because of how fast the AI can iterate.
And you get to pay some big corporation for the privilege.
> Many developers are satisfied once the code simply works.
In the general case, the only way to convince oneself that the code truly works is to reason through it, as testing only tests particular data points for particular properties. Hence, “simply works” is more like “appears to work for the cases I tried out”.
I wrote a couple python scripts this week to help me with a midi integration project (3 devices with different cable types) and for quick debugging if something fails (yes, I know there are tools out there that do this but I like learning).
I’m could have used an LLM to assist but then I wouldn’t have learned much.
But I did use an LLM to make a
management wrapper to present a menu of options (cli right now) and call the scripts. That probably saved me an hour, easily.
That’s my comfort level for anything even remotely “complicated”.
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?
> AI workflows are, in practice, highly non-deterministic. While different versions of a compiler might give different outputs, they all promise to obey the spec of the language, and if they don’t, there’s a bug in the compiler. English has no similar spec.
AI coding shines when this is a good thing. For instance, say you have to adapt the results of one under-documented API into another. Coding agents like Claude Code can write a prototype, get the real-world results of that API, investigate the contents, write code that tries to adapt, test the results, rewrite that code, test again, rewrite again, test again, ad nauseam.
There are absolutely problem domains where this kind of iterative adaptation is slower than bespoke coding, where you already have the abstractions such that every line you write is a business-level decision that builds on years of your experience.
Arguably, Geohot's low-level work on GPU-adjacent acceleration is a "wild west" where his intuition outstrips the value of experimentation. His advice is likely sound for him. If he's looking for a compiler for the highly detailed specifications that pop into his head, AI may not help him.
But for many, many use cases, the analogy is not a compiler; it is a talented junior developer who excels at perseverance, curiosity, commenting, and TDD. They will get stuck at times. They will create things that do not match the specification, and need to be code-reviewed like a hawk. But by and large, if the time-determining factor is not code review but tedious experimentation, they can provide tremendous leverage.
> 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.
Yes. He mentions that in passing that saying people will accuse him of hating on it because he didn't profit from it. I think his point of view is that his company's attempt was smaller scale and not part of the $10B+ waste?
In any case I don't fully understand what he's trying to say other than negating the hype (which i generally agree with), but not offering any alternative thoughts of his own other than- we have bad tools and programming language. (why? how are they bad? what needs to change for them to be good?)
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.
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.
I used to be a bit more open minded on this topic but im increasingly viewing any programmers who use AI for anything other than brainstorming and looking stuff up/explaining it as simply bad at what they do.
Even when copy-pasting an entire function from stack overflow, you generally still need to have some understanding of what the inputs and outputs are, even if it remains somewhat of a black box, so that you can plug it into your existing code.
AI removes that need. You don't need to know what the function does at all, so your brain devotes no energy towards remembering or understanding it.
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 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)
Having something at our disposal that you can write code specs in, that is as easy as natural language yet, more concise, easy to learn and most of all not so anal/rigid as typical code languages are would be fantastic.
nice misspelling (or a joke?), related to all the lawsuits around LLMs.
Joking aside, it’s already there in a sense. Several times I started with a brief outline of what the prototype should do (an HTML/CSS/JS app), and sure enough, refinements and corrections followed. When the final version worked more or less as expected, I asked the LLM to create a specification (a reproducing prompt) of everything we made together. Even if the vibe-coded prototype is dropped, the time wasn’t wasted, I probably would never have come to the same bullet list specification without having an actual working app at my disposal to test and evaluate. So paradoxically this specification even might be used by a human later
Natural language becomes like an abstraction above the high-level languages then, even above things like Scratch and Basic. But you can't define how big of an abstraction it is exactly, like I can say "write an GPS app" or "write a function that does x"
The former is more abstracted and the latter is less. It's this ambiguity and non-determinism that's tricky.
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.
We are turning specifications into software precisely because English (and any natural languages) lacks the formality that makes it not reliable (necessary quality for a tool), but great for imagination (the source of invention).
We always start from natural language. RFC, docs, tickets,... are in natural language. But gaining formality (losing ambiguity) is what programming is (software engineering is doing programming well). People that struggled with programming struggle in fact with formality.
These workflows always surprise me. Isn’t this what you’ve been doing with humans all along? Write up a basic project plan likely following some structure the product team likes. Share it with the eng team. One to a few members of the eng team writes up a more specific plan. Everyone gets together again and goes through the specific plan to iron out the kinks. You the implement the plan.
I’ve seen at my workplace people are more willing to help Claude with a plan than their fellow humans. I pointed that out and one engineer replied with “well I know Claude will read the documentation”. It’s a depressing observation but I don’t know if it’s wrong.
This is just basic spec based development, don't see what's so interesting about this. People have been using this method for quite a while, even Kiro now uses this for its entire process.
Anyone dismissing AI coding without having seriously tried it or looked at the outputs of people who have can't be taken seriously. Yes, it shouldn't worked in theory. But it's disturbingly good in practice, for someone who knows what they are doing.
So anyone that doesn't know what they're doing can dismiss it without seriously trying it? I mean, I agree, but I feel like you wouldn't with this implication of what you're saying...
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!
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.
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.
George famously started a self driving hardware-as-an-addon company. He started after both claiming self driving was easy, and reportedly taking up an Elon bounty/bet in the seven figure range to make self driving AI for Tesla.
I think some of the “hate” is the hype. We’re all tired of companies announcing ground breaking tech that isn’t readily available a decade later.
I don’t live in California (like most of the population of the planet) - Toronto for 18 years and now the American side of the Great Lakes.
Ice storms, snow, sleet, cold weather 5-6 months out of the year. Batteries suck in the cold, sensors fail or under-perform. Hell, door handles and windows struggle in this weather.
Waymo is not a thing in NY or Chicago or Minneapolis or Philadelphia (I could go on).
And that's just in North America where cities were built for cars and with cars in mind. Autonomous driving in Europe or Asia is likely a magnitude harder due to windy roads, non trivial intersections, complex interactions of humans, bikes, trams and cars etc.
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
By the same token, a software developer could perhaps also be likened to a compiler, taking language and/or visual information as input and turning it into code.
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%.
> 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.
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.
We've had 50+ years to do that. Progress has been unimpressive, to be charitable. It's time to let some different people try something else.
I really hate the comparison of AI to a compiler. It's not like I'm writing a codebase in English. I'm still writing codebases in programming languages. AI just helps manage all the text.
> 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.
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 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
Dunno how it'll work with Claude Code, but I use the context7 MCP to feed up-to-date docs in copilot.
Sometimes that also doesn't work so I make a guiding document using whatever llms.txt the framework/language/platform offers or just wget the entire documentation, condense it into a single text file and use that while prompting.
Seems to work ok, especially for Svelte 5 where most LLMs except Gemini don't give me runes from the get-go.
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
> That's the point - it's a higher level of abstraction.
That's not what abstraction is. When I type `echo Hello, World`, I don't have to deal with graphic drivers and test rendering to have the text on the screen. And I don't have to worry that "Goodbye" will appear instead.
> Not unlike say a boss telling a junior to change something?
Junior don't stay junior for long. And bosses usually give juniors less time to grow than people are allocating AI tools to actually prove themselves. Github copilot was more than 3 years ago. Today a new hire is expected to be productive on day one.
> The only reason it works for many common programming workflows is because they are common. The minute you try to do new things, you need to be as verbose as the underlying language.
You can stop here. This is enough to change the game. SO MUCH time and money is spent on mostly-boilerplate line of business apps. If you don't understand this, you are in a bubble of some kind. The corporate world's IT departments and consulting agencies are filled with developers who write nothing but what boil down to custom-tailored CRUD apps. AI is absolutely KILLER for this kind of work.
If you're doing novel research, perhaps not. But that describes a relatively small portion of the worldwide developer community.
George, you post this after everyone already realized that LLMs plateaued.
Before that you were crying about the singularity and how we're super close it and in 6 months AI will be basically Einstein. Nothing has given me more joy than to see this AI slop fail.
Here's a 100 page document generated with AI and the other person will shrink it with AI at the end of the day those 2 lines of cognitive effort would've been a better deal than sending slop back and forth.
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}}
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).
> 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?
Because geo fenced driving in a few select cities with very favourable conditions is not what was promised. That's the crux. They promised us that we have self drive anywhere at anytime at the press of a button.
> Not a billion dollar business yet, maybe, but 300 cars generating five or six figures revenue per year each isn't far off.
I'm not sure how you get to 6 figures revenue. Assuming the car makes $100 per hour for 24x7 52 weeks a year we still fall short of 1 million. But let's assume you're right $300M revenue (not profit, are they even operating at a plus even disregarding R&D costs?) on investment of >10 billion (probably more like 100), seems like the definition of hype.
> (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).
What I don't understand with this argument, how are you proposing they become the dominant mode of transport. These services are competing with taxis, what do they offer over taxis that people suddenly switch on mass to self driving taxis? They need to become cost competitive (and convenience competitive) with driving your own car, which would significantly drive down revenue. Secondly if robotaxi companies take over transport, why would the public continue to build their infrastructure and not demand that these robotaxi companies start to finance the infrastructure they exclusively use?
I got to six figures by assuming that a human taxi driver makes maybe $30-40k at a guess, and an autonomous car can work 24/7. 6 figures is $100k minimum.
So yeah, right now they'd have to be at ten cities x 300 cars each to hit 300M revenue, but there's still plenty of room for growth. Or should be, assuming the Waymo model isn't maxed out supporting the current handful of cities.
But I'm not convinced they have to hit cost parity with personal cars, because the huge advantage is you can work and drive (or be driven). If NYC and LA rush-hour congestion time becomes productive time, there's your billions.
I drive but prefer to take transit for this reason - some of my colleagues are able to join work calls effectively while driving, but for whatever reason my brain doesn't allow that. Just paying attention to calls is enough, you want me to pay attention to the road AND the call?
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 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 time rather than skill, you can only take on a limited number of challenging things one after another before you get exhausted.
Companies need to realise that AI to go faster is great, but there's still a cognitive impact on the people. A little respite from the hardcore stuff is genuinely useful sometimes. Taking all of that away will be bad for people.
That said, some devs hate the boring easy bits and will thrive. As with everything, individuals need to be managed as individuals.
That makes me think of https://store.steampowered.com/app/2262930/Bombe/ which is a version of Minesweeper where instead of clicking on squares you define (parametric!) rules that propagate information around the board automatically. Your own rules skip all the easy parts for you. As a result, every challenge you get is by definition a problem that you've never considered before. It's fun, but also exhausting.
I remember listening to a talk about Candy Crush and how they designed the game to have a few easy levels in between the hard ones, to balance feeling like you're improving while also challenging players. If all the levels get progressively harder, then a lot of people lose motivation to keep playing.
Oooohhh....
That looks like plenty of hours of fun! Thanks for the link :)
I just tried that game and it looks very interesting but the interface is cryptic.
Interesting point.
There's also the fact that, while you're coding the easy stuff, your mind is thinking about the hard stuff, looking things up, seeing how they articulate. If you're spending 100% of your time on hard stuff, you might be hurting these preliminaries.
I haven't yet found a "boring, easy" problem that an AI could generate more easily than Vim.
Vim can write basic unit tests?
This makes no sense. Yes, having time to think about the hard part is good, but just because you’re not doing the boilerplate anymore doesn’t mean you can’t do the thinking part anymore! See how absurd it sounds when you actually describe it this way?
Let me rephrase.
I know brilliant people who took up knitting to keep their hands busy while they think over their difficult problems. But that only works if you can knit in your work hours. Sadly, despite clearly improving the productivity of these people, this is a fireable offense in many jobs.
I'm not saying that the only way to think through a hard problem is to work on boilerplate. If you are in a workplace where you can knit, or play table soccer, by all means, and if these help you, by all means, go for it.
What I'm thinking out loud is that if we're dedicating 100% of our time to the hard problems, we'll hit a snag, and that boilerplate may (accidentally) serve as the padding that makes sure we're not at these 100%.
That being said, I'm not going to claim this as a certainty, just an idea.
I don't disagree, but I find a better use of my time is writing. Not code, but essentially a work journal. It's not big thoughts, it's bullet points. It's not documentation, but more of a open mind map: what's been done, what needs to be done, questions that inevitably pop up, etc. I use Obsidian for this, but if I write much more than what would go on a few post-it notes, it's too much.
Writing and coding use different parts of the brain. Writing is for creating a model to communicate about human things, and coding is for creating a model for communicating about computer things.
Sure, but we've all had one of those "ah-ha!" moments when we took ourselves out of the code. I feel like putting yourself in a position when you're thinking big picture is far more useful than hand-coding a routes file or adding validation to a model file.
> Devs often want the inherent safety of the boring, easy stuff for a while.
Part of the problem is that in big orgs, you need to show consistent progress in order to not get put on some PIP and kicked out of the company. There are performance review cycles and you have to show something continuously.
That ONLY works if you have boring, easy work. It's easy to deliver consistent progress on that.
Interesting and difficult work is nice only if you are trusted to try your best and given the freedom to fail. That's the nature of hard problems; progress in those domains is very sudden and Poissonian and not consistent by nature. If you're going to be judged on your ability to be sub-Poissonian and consistent, and get put on a PIP for not succeeding at it one review cycle (and possibly risking income that you use to put a roof over your head or feed your family) it's not worth the career risk to try difficult things.
Not saying this is the way I think, it's just the reality of how things often work in big orgs, and one of the reasons I dislike many big orgs.
> Devs often want the inherent safety of the boring, easy stuff for a while
That's matches my experience. In my first job, every time a new webapp project has been starting it was fun. Not because of challenges or design, but simply because of the trivial stuff done for n-th time - user accounts, login, password reset, admin panel. Probably should have been automated at this point, but we got away with reinventing the wheel each time.
>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 thinking with a kind of faith based gambler's mentality ("maybe if i tell it to think really hard it'll do it right next time...").
The only times ive seen a notable productivity improvement is when it was something not novel that didnt particularly matter if what popped out was shit - e.g. a proof of concept, ad hoc app, something that would naturally either work or fail obviously, etc. The buzz people get from these gamblers' highs when it works seems to make them happier than if they didnt use it at all though.
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.
> 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.
Is it really? Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction. I've seen people describing things as sludge, but they've never learned awk to write a simple script to take care of the work. Or learned how to use their editor, instead using the same pattern they would have with Notepad.
I think it's better to take a step back and reflect on why we're spending time on basic stuff instead. Instead of praying that the LLM will generate some good basic stuff.
If you're not able to review what it generates, you shouldn't be using it (and arguably are the wrong person to be doing the boilerplate work to begin with)
Put differently, I go back to my original comment, where AI is essentially a junior/mid dev that you can express what needs to be done with enough detail. In either case, AI or dev, you'd review and/or verify it.
> Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction.
One could say the same of installing packages in most modern programming languages instead of writing the code from first principles.
> One could say the same of installing packages in most modern programming languages instead of writing the code from first principles.
I disagree, because libraries define an interface with (ideally) precise, reproducible semantics, that you make use of. They provide exactly what the grandparent is saying, namely a formal abstraction. When you have the choice between a library and an LLM, requiring equal effort, the library is clearly preferable.
When an LLM is more time-efficient at a given coding task, it can be taken as an indication of a lack of a suitable library, tooling, or other abstraction for the use case.
>So much of what we write is absolutely low-skill and low-impact, but necessary and labor-intensive.
Ive never found this to be true once in my career.
I know a lot of devs who looked down on CRUD or whatever it was they were doing and produced boilerplate slop though.
Code isnt like pottery. There arent "artisanal" devs who produce lovely code for people to look at like it's a beautiful vase. Good code that is hooked into the right product-market fit can reach millions of people if it works well.
The world was replete with shitty code before AI and mostly it either got tossed away or it incurred epic and unnecessary maintenance costs because it actually did something useful. Nothing has changed on that front except the tsunami of shit got bigger.
I think there are two kinds of uses for these tools:
1) you try to explain what you want to get done
2) you try to explain what you want to get done and how to get it done
The first one is gambling, the second one has very small failure rate, at worst, the plan it presents shows it's not getting the solution you want it to do.
The thing is to understand that a model has "priors" which steer how it generates code. If what you're trying to build matches the priors of the model you can basically surf the gradients to working software with no steering using declarative language. If what you want to build isn't well encoded by the models priors it'll constantly drift, and you need to use shorter prompts and specify the how more (imperative).
In my experience, you need shorter prompts and steering it constantly for any kind of work, novel or not. You can be doing the most basic thing, if you let it iterate long enough, it will start doing something completely stupid. It's really sad watching Gemini CLI debugging something trivial, and trying to change it "one last time" again. Fortunately, Claude is better at this, but you still need to steer it. And try extremely hard not to give it pointers to something you DON'T want it to do, especially if it's easy and in it's training set, because it will so gladly pick it up.
> 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.
That's strange, I've never thought it can be done this way. Normally I'd read the docs, maybe sketch up some diagrams, then maybe take a walk while thinking on how to solve the problem, and by the time I got back to the screen I'd already have a good idea on how to do it.
These days the only difference is that I feed my ideas to a few different LLMs to have "different opinions". Usually they're crap but sometimes they present something useful that I can implement.
This is an interesting take on it. I've been using Cursor at work and notice that days where I have it generate all the "easy parts", I end up feeling much more mentally exhausted than if I spend the day writing everything by hand.
That tracks. Being in flow on a task you're confident about is a low arousal, satisfying state.
Monitoring AI output on any task is high arousal, low satisfaction, unless you're constantly prompting for quick wins.
Yes I can see why some devs might prefer the safety of the boring and the familiar stuff. But the employers aren’t going to care about that. They’re going to hire and retain the devs who are more productive in the new era.
On the flip side, there have been lots of times where I personally didn’t have a lot of time to deeply research a topic (read papers, build prototypes of different ideas, etc) due to lack of time and resources. If all of the boring stuff is gone, and building prototypes is also 3x faster maybe what will end up happening is we can now use all of this free time to try lots of different ideas because the cost of exploration has been lowered.
I think you're describing things we already knew long before this era of AI. Less code is better code, and the vast majority of bugs come from the devs who "hate the boring easy bits".
I disagree that this has anything to do with people needing a break. All code eventually has to be reviewed. Regardless of who or what wrote it, writing too much of it is the problem. It's also worth considering how much more code could be eliminated if the business more critically planned what they think they want.
These tensions have existed even before computers and in all professions.
That's crazy to me. I solve problems. I'm not a janitor or tradesman, you bring me in to envision and orchestrate solutions that bring bottom line value. I live to crack hard nuts, if I never have to bother with rigging again I'll be so happy.
This is exactly why people hate AI. It disrupts the comfort of easy coding.
The main challenge with any creative effort, including and especially programming, is motivation. "Easy coding" gives you small mental wins that build your dopamine circuits and give you something to chase. When people say that "AI takes the fun out of coding" they mean that they're not getting those rewards anymore. It might make coding easier (though I'm not sure it actually does, ultimately), but in the process it takes away the motivation.
The ones who are excited about this are the ones who are motivated by the product. When AI can whip up some half-baked solution it sure looks like you can focus on the product and "get someone to code it up for you". But unless it's a well-understood and previously executed solution, you're going to run into actual technical problems and have to fix them. But your motivation to deal with the irritating pedantrics of the modern computing stack (which are the same as all technology ever, with orders of magnitude more parts) hasn't been built up. There's no beneficial flywheel, just a fleet of the Sorceror's Apprentice mindless brooms that you hope you can get work enough to ship.
> 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 time rather than skill, you can only take on a limited number of challenging things one after another before you get exhausted.
The issue of senior-juniors has always been a problem; AI simply means they're losing their hiding spots.
I'm just slightly younger than you, but have the exact same sentiment. Hell, even moreso maybe, because what I realized is that "writing code to implement interesting ideas" is not really what I enjoy - it's coming up with the interesting ideas and experimenting with them. I couldn't care less about writing the code - and I only did it because I had to...if I wanted to see my idea come to life.
AI has also been a really good brainstorming partner - especially if you prompt it to disable sycophancy. It will tell you straight up when you are over-engineering something.
It's also wonderful at debugging.
So I just talk to my computer, brainstorm architectures and approaches, create a spec, then let it implement it. If it was a bad idea, we iterate. The iteration loop is so fast that it doesn't matter.
Did you end up regretting a design choice, but normally you'd live with it because so much code would have to be changed? Not with Agentic coding tools - they are great at implementing changes throughout the entire codebase.
And its so easy to branch out to technologies you're not an expert in, and still be really effective as you gain that expertise.
I honestly couldn't be happier than I am right now. And the tools get better every week, sometimes a couple times a week.
> 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'm in the same boat (granted, 10 years less) but can't really relate with this. By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.
The parts in the middle – non-trivial but not big picture – in my experience are the parts where writing the code myself constantly uncovers better ways to improve both the big picture and the automation/generalization. Because of that, there are almost no lines of code that I write that I feel I want to offload. Almost every line of code either improves the future of the software or my skills as a developer.
But perhaps I've been lucky enough to work in the same place for long. If I couldn't bring my code with me and had to constantly start from scratch, I might have a different opinion.
> By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.
The two aren't mutually exclusive. You can use AI to build your tooling. (Unless it's of sufficient complexity or value that you need to do the work yourself)
The time spent on the tooling is very low. Using AI for that would be like renting a flamethrower because couple of times a year I like to go camping and light a fire. I'd rather just use a lighter.
I have a couple of niche areas of non-coding interest where I'm using AI to code. It is so amazing to write rust and just add `todo!(...)` through out the boiler plate. The AI is miserable at implementing domain knowledge in those niche areas, but now I can focus on describing the domain knowledge (in real rust code because I can't describe it precisely enough in English + pseudo code), and then say "fill in the todos, write some tests make sure it compiles, and passes linting", verify the tests check things properly and I'm done.
I've struggled heavily trying to figure out how to get it to write the exactly correct 10 lines of code that I need for a particularly niche problem, and so I've kind of given up on that, but getting it to write the 100 lines of code around those magic 10 lines saves me so much trouble, and opens me up to so many more projects.
I have a similar view of AI.
I find it best as a "personal assistant," that I can use to give me information -sometimes, highly focused- at a moment's notice.
> The potential for then stunting the growth of actual juniors into tomorrow's senior developers is a serious concern
I think it's a very real problem. I am watching young folks being frozen out of the industry, at the very beginning of their careers. It is pretty awful.
I suspect that the executives know that AI isn't yet ready to replace senior-levels, but they are confident that it will, soon, so they aren't concerned that there aren't any more seniors being crafted from youngsters.
Would suck, if they bet wrong, though…
>> developer somewhere between junior and mid-level,
Analogies to humans don't work that well. AI is super-human in some respects while also lacking the ability to continually work toward a goal over long periods of time. AI can do very little on its own - just short / scoped / supervised tasks.
However, sometimes the situation is reversed, AI is the teacher who provides some examples on how to do things or provides hints on how to explore a new area and knows how others have approached similar things. Then, sometimes, AI is an astute code reviewer, typically providing valuable feedback.
Anyway, I've stopped trying anthropomorphize AI and simply try to reason about it based on working with it. That means combinations of direct ChatGPT usage with copy / paste / amend type workflows, async style / full PR style usage, one-shot "hail Mary" type throw away PRs just to establish an initial direction as well as PR reviews of my own code. I'm using AI all the time, but never anything like how I would work with another human.
Exactly. I tend to like Hotz, but by his description, every developer is also "a compiler", so it's a useless argument.
My life quality (as a startup cofounder wearing many different hats across the whole stack) would drop significantly if Cursor-like tools [1] were taken away from me, because it takes me a lot of mental effort to push myself to do the boring task, which leads to procrastination, which leads to delays, which leads to frustration. Being able to offload such tasks to AI is incredibly valuable, and since I've been in this space from "day 1", I think I have a very good grasp on what type of task I can trust it to do correctly. Here are some examples:
- Add logging throughout some code
- Turn a set of function calls that have gotten too deep into a nice class with clean interfaces
- Build a Streamlit dashboard that shows some basic stats from some table in the database
- Rewrite this LLM prompt to fix any typos and inconsistencies - yeah, "compiling" English instructions into English code also works great!
- Write all the "create index" lines for this SQL table, so that <insert a bunch of search usecases> perform well.
[1] I'm actually currently back to Copilot Chat, but it doesn't really matter that much.
> Add logging throughout some code
That's one of the thing that I wouldn't delegate to LLM. Logging is like a report of things that happens. And just like a report, I need relevant information and the most useful information.
...
A lot of these use cases actually describes the what. But the most important questions is always the why. Why is it important to you? Or to the user? That's when things have a purpose and not be just toys.
Code with logging is "self reporting". Adding logging statements is not reporting itself. Adding `logger.error(f"{job} failed")` is not reporting itself, and LLMs are perfectly capable of adding such statements in applicable places.
As to why, it's because I'm building an app with a growing userbase and need to accommodate to their requirements and build new features to stay ahead of the competition. Why you decided I'm describing a toy project is beyond me.
As someone else said: Launch is only the first step. That's when practicality start to matter.
The reason senior engineers are being paid that well is not because they need to type a lot of code to get new features in. It's because they need to figure how to have less code while having more features.
Exactly. If you know how the whole thing works end to end, AI makes you incredibly dangerous. Anyone who specializes or never really learned how everything works is at a huge disadvantage.
However. There's also good news. AI is also an amazing tool for learning.
So what I see AI doing is simply separating people who want to put effort forth and those who don't.
> However. There's also good news. AI is also an amazing tool for learning.
Absolutely. For example, I've been learning Autodesk Fusion, and after establishing a small foundation through traditional learning techniques, I've been able to turbocharge my learning by asking precise questions to AI.
I image this really sucks for those whose business model relied on gatekeeping knowledge. (like training companies)
I agree. Having AI write your entire application is equivalent to having it write a song for your band, or even generate audio so you don't have to do record it yourself.
If you aren't talented enough to write or record your own music, you aren't really a musician.
If you have a quick question about music theory and you want a quick answer, AI can be a benefit.
Yeah, I don't buy this. Creating art is in no way equivalent to making logic to perform a task.
This resonates with me. I'm also around the same age and have the same amount of experience.
I love AI and use it for both personal and work tasks for two reasons:
1. It's a way to bounce around ideas without (as much) bias as a human. This is indispensable because it gives you a fast feedback mechanism and validates a path.
2. It saves me typing and time. I give it one-shot, "basic work" to do and it's able to do accomplish at least 80% of what I'd say is complete. Although it may not be 100% it's still a net positive given the amount of time it saves me.
It's not lost on me that I'm effectively being trained to always add guardrails, be very specific about the instructions, and always check the work of AI.
> I can pretty much see projects in my head, and know exactly what to build.
This is where AI actually helps - you have a very precise vision of what you want, but perhaps you've forgotten about the specific names of certain API methods, etc. Maybe you don't want to implement all the cases by hand. Often validating the output can take just seconds when you know what it is you're looking for.
The other part of making the output do what you want is the ability to write a prompt that captures the most essential constraints of your vision. I've noticed the ability to write and articulate ideas well in natural language terms is the actual bottleneck for most developers. It takes just as much practice communicating your ideas as it does anything else to get good at it.
Yes, unfortunately the boring parts are what junior devs used to do so the senior devs could work on the good stuff. Now that AI is doing the boring stuff nobody has to hire those pesky jr developers anymore. Yay?
The problem is that junior developers are what we make senior developers with— so in 15 years, this is going to be yet another thing that the US used to be really good at, but is no longer capable of doing, just like many important trades in manufacturing. The manufacturers were all only concerned with their own immediate profit and made the basic sustainability of their workforce, let alone the health of the trades that supported their industries, a problem for everyone else to take care of. Well, everyone else did the same thing.
> The problem is that junior developers are what we make senior developers with— so in 15 years
In 15 years senior developers will not be needed as well. Anyway no company is obliged to worry about 15 years timescale
And nobody is obligated to make sure they aren’t walking off of a cliff.
Most people don’t share your confidence that we will replace senior engineers and I’d gobsmacked if we could. Just like the magical ‘automation’ can’t replace the people that actually make the physical things that the machines use to do their jobs, or fix the machines, no matter how good it gets. But the quantitatively-minded MBAs just kept kicking the can down the road and assumed it was someone else’s problem that the end of the road was approaching. It wasn’t their problem that there would be a problem in 30 years, and then it wasn’t their problem when it was 10 years, and now that we’re standing at the edge of a cliff, they’re realizing that it’s everybody’s problem and it’s going to be a hell of a lot more painful than if they’d had an extremely modest amount of foresight.
Now, US manufacturers are realizing that all of their skilled laborers are retiring or dying, and there isn’t enough time to transfer the more complex knowledge sets, like Tool and Die making, to a new set of apprentices. Many of these jobs are critical not only to national security, but also our country’s GDP because the things we do actually make are very useful, very specialized, and very expensive. Outsourcing jobs like making parts for fighter jets is really something we don’t want shipped overseas unless we want to see those parts pop up on aliexpress. If nobody is responsible for it and nobody wants to fund the government to fix it, but it is a real problem, it doesn’t take a genius to see the disconnect there.
It’s yet another place where we know our own capacity as a society is shrinking and hoping that ??? (Ai? Robots? Fusion?) will fix it before it’s too late. I never thought programming would join elder-care in this category though, that came as a surprise.
Would love to see a project you built with the help of AI, can you share any links?
Most of my work is for my employer, but the bigger point is that you wouldn't be able to tell my "AI work" from my other work because I primarily use it for the boring stuff that is labor-intensive, while I work on the actual business cases. (Most of my work doesn't fall under the category of "web application", but rather, backend and background-processing intensive work that just happens to have an HTML front-end)
https://github.com/williamcotton/webpipe
Shhh, WIP blog post (on webpipe powered blog)
https://williamcotton.com/articles/introducing-web-pipe
Yes, I wrote my own DSL, complete with BDD testing framework, to write my blog with. In Rust!
My blog source code written in webpipe:http://github.com/williamcotton/williamcotton.com
100% agree. I am interested in seeing how this will change how I work. I'm finding that I'm now more concerned with how I can keep the AI busy and how I can keep the quality of outputs high. I believe it has a lot to do with how my projects are structured and documented. There are also some menial issues (e.g. structuring projects to avoid merge conflicts becoming bottlenecks)
I expect that in a year my relationship with AI will be more like a TL working mostly at the requirements and task definition layer managing the work of several agents across parallel workstreams. I expect new development toolchains to start reflecting this too with less emphasis on IDEs and more emphasis on efficient task and project management.
I think the "missed growth" of junior devs is overblown though. Did the widespread adoption of higher-level really hurt the careers of developers missing out on the days when we had to do explicit memory management? We're just shifting the skillset and removing the unnecessary overhead. We could argue endlessly about technical depth being important, but in my experience this hasn't ever been truly necessary to succeed in your career. We'll mitigate these issues the same way we do with higher-level languages - by first focusing on the properties and invariants of the solutions outside-in.
An important skill for software developers is the ability to reason about what the effects of their coce will be, over all possible conditions and inputs, as opposed to trial and error limited to specific inputs, or (as is the case with non-deterministic LLMs) limited to single executions. This skill is independent of whether you are coding in assembly or are using higher-level languages and tooling. Using LLMs exactly doesn’t train that skill, because the effective unpredictability of their results largely prevents any but the most vague logical reasoning about the connection between the prompt and the specific output.
> Using LLMs exactly doesn’t train that skill
I actually think this is one skill LLMs _do_ train, albeit for an entirely different reason. Claude is fairly bad at considering edge cases in my experience, so I generally have to prompt for them specifically.
Even for entirely “vibe-coded” apps I could theoretically have created without knowing any programming syntax, I was successful only because I knew about possible edge cases.
> I love AI for speed running through all the boring stuff and getting to the good parts.
But the issue is some of that speedrunning sometimes takes so much time, it becomes inefficient. It's slowly improving (gpt5 is incredible), but sometimes it get stuck on really mundane issue, and regress endlessly unless I intervene. And I am talking about straightforwars functional code.
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.
> I can pretty much see projects in my head, and know exactly what to build.
I think you’re the best case support for AI coding. You know clearly what you want, so you know clearly what you don’t want. So if you had decent verbal dexterity you could prompt the AI model and manage to accomplish what you intended.
A lot of programming problems / programmer contexts don’t match that situation. Which is the problem with universalizing the potency of AI / benefits of AI coding.
same. 50’s, coding since the 90’s, make more $$ than I can spend in 3 lifetimes. one constant thing in my 3 decade career has been that absolute best people I worked with all had one common thread - absolute laziness. sounds strange but every other trait of a great SWE has not been universal except laziness.
the laziness manifest itself into productivity as crazy as this sounds. how? lazy people find a way to automate repetitive tasks. what I have learned from these over the years is that anything you do twice has to find a way to be automated as third time is around the corner :)
what does this have to do with AI? the AI has taken automation to another level allowing us to automate so much of our work that was not previously possible. I found myriad of ways to use AI and several of my best (lazy) co-workers have as well. I cannot imagine doing my work anymore without it, not because of any “magic” but because my lazy ass will be able to do all the things that I have automated out
Yes! Once I've figured out that this problem is best solved using parser combinators, and that I have a good idea of how to model the transformation, I'm so glad I can delegate work to the LLM code gen and focus on the specification, test cases, corner cases, etc;
I don't think thats contrary to the article's claim: the current tools are so bad and tedious to use for repetitive work that AI is helpful with a huge amount of it.
+1. I agree with George when he says that AI is many times being used as a replacement for poor tooling, but you know what? So be it.
That‘s exactly why i like AI too. I even let them play roles like „junior dev“, „product owner“ or „devops engineer“ and orchestrate them, to play together as a team - with guidance from me (usually the „solution architect“ or „investor“)! This „team“ achieves in weeks what we usually needed months for - for 2.40€/h*role!
This sounds a bit like creating a Humanoid robot to do dishes instead of a machine specifically designed to do dishes.
I can't tell if you are being sarcastic but this sounds absurd. Why let the AI be junior, why not an expert?
This persona driven workflow is so weird to me. Feels like stuck in old ways.
Avoiding context bloat and scoping the chain of thought
Per @vgr, LLMs are an old person’s technology. (I, too, am an old person.)
I have a similar relation to AI with programming -- and my sense is very many HN readers do as well, evidenced not least by the terrific experience report from antirez [1]. Yet it is rare to see such honest and open statements even here. Instead, HN is full of endless anti-AI submissions on the front page where the discussion underneath is just an echo chamber of ill-substantiated attacks on 'AI hype' and where anything else is down-voted.
It's what is, to me, so bizarre about the present moment: certainly investment is exceptionally high in AI (and of course use), but the dominant position in the media is precisely such a strange 'anti-AI hype' that positions itself as a brave minority position. Obviously, OpenAI/Altman have made some unfortunate statements in self-promotion, but otherwise I genuinely can't think of something I've read that expresses the position attacked by the anti-AI-ers -- even talk of 'AGI' etc comes from the AI-critical camp.
In a sense, the world seems divided into three: obvious self-promotion from AI companies that nobody takes seriously, ever-increasingly fervent 'AI critique', and the people who, mostly silent, have found modern AI with all its warts to be an incomparably useful tool across various dimensions of their life and work. I hope the third camp becomes more vocal so that open conversations about the ways people have found AI to be useful or not can be the norm not the exception.
[1] https://antirez.com/news/154
It’s hard to see how the current rate of progress is compatible with, 30 years from now, it being good business sense to pay human professionals six figure salaries. Opinions then split: the easiest option is pure denial, to assume that the current rate of progress doesn’t exist. Next easiest is to assume that progress will halt soon, then that we will be granted the lifestyle of well paid professionals when unsupervised AI can do our job for cheaper, then that Altman will at least deign to feed us.
antirez's success doesn't mean anything since antirez is far, far above average as a developer and is able to wield AI very effectively because of his talents and knowledge. Most developers are not remotely close to antirez's skill level (half are below average, by definition) and are likely going to suffer the problems that skeptics are already seeing.
> developer somewhere between junior and mid-level
Why the insistence on anthropomorphizing what is just a tool? It has no agency, does not 'think' in any meaningful manner, it is just pattern matching on a vast corpus of training data. That's not to say it can't be very useful - as you seem to have found - but it is still just a tool.
This isn’t necessarily anthropomorphizing, as from a company’s point of view, or uncharitably even from a tech leads point of view, developers are also just tools. The point being made is that LLMs (supposedly) fulfill those developer roles.
It's less about what the tool is, and more about the kind of work we often assign to less experienced developers. Pattern matching in meatspace is still pattern matching.
It's not anthropomorphising though, is it? It's just a comparison of the tool's ability. Like talking about the horsepower of an engine.
But we didn't do this with spreadsheets or word processors - and those tools really did replace small armies of clerical and secretarial workers.
The difference is AI is closing on doing the EXACT work with the EXACT info as a junior dev. Give an LLM a Jira ticket and a codebase and it can push a PR. Spreadsheets are great, but that was a tool that minimized effort but didn't remove it. LLMs can directly replace a remote junior with no visible difference already.
> Give an LLM a Jira ticket and a codebase and it can push a PR
Not really though can it, unless that codebase and Jira happens to pattern match correctly somewhere.
I'd say that the difference is just that LLMs have a natural language interface (for good or for ill).
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.
> the general hacker news group think about AI
I’m surprised to see this. From my perspective, reading comments and seeing which posts rise to the top, HN as a whole seems pretty bullish on the tech as whole…
I think there might also just be a vocal minority and/or some astroturfing hyping AI coding around hackernews. I personally keep trying all the latest shit and always stop using it, because it actively slows me down.
It’s changing over time. When copilot came out a few years ago, people were very against it due to it being trained oh GitHub codebase. Now there’s more support around it.
We don't want to admit it but HN has similar characteristics as many other platforms; echo chamber / group think. You see it over and over again.
HN participants (generally speaking) are against: AI, Crypto, HFT. I've worked in 2/3 of these industries so have first hand experience. My basic summary is that the average commenter here has a lot of misinformation on these topics (as a insider).
It also seems wildly inconsistent for someone who founded a self driving company. If models can't write code, which is a very constrained problem space, how are they supposed to drive?
I work in aerospace, trust me some of the aerospace engineers aren't any better.
But don't worry. The company puts them somewhere they can't do any damage. Most of them become managers.
I don’t know. He covers this pretty early in the post.
> The only reason it works for many common programming workflows is because they are common. The minute you try to do new things, you need to be as verbose as the underlying language.
[flagged]
In the early days of Bitcoin, I was able to send transactions programmatically. Built my own js library using json-rpc to communicate with a node.
Geohot live streamed himself broadcasting a transaction from scratch.
For that I respect his level of knowledge. Plus he built comma which is a product I use almost everyday.
You've seen plenty of people who hacked the ps3 and iphone as teenagers and created a low level system analysis tool for doing such system hacks? You've seen plenty of people writing self driving car software a decade ago? Why did you write this when you know nothing?
I actually have seen plenty of people that could have done something like this, but did not because they simply never tried. Being daring by itself is a skill, but we're talking raw technical ability here.
I've actually seen another developer that was probably in the same category write his own self-driving software. It kind of worked, but couldn't have ever been production ready, so it was just an exercise in flexing without any practical application.
So, what product that George built do you actually use?
So, if I understand correctly, you've seen plenty of people that didn't do what he did? This was not a compelling argument.
> you've seen plenty of people that didn't do what he did?
Yes, because I've seen them build software that was actually used. And I've seen a few that did just like him, impressive sounding projects that had no usage.
I understand it's something subjective. I get the same feeling when looking at Damien Hirst's monstrouly expensive stuff that leaves me cold. Even after I get the concepts behind the works, my end feeling is of "so what?".
Your calibration around skill gradients but also cause and effect is so far off that I'm wondering how you manage to navigate reality.
You have absolutely no idea about me or my life, but chose to insult me based on not being impressed by some github profile.
Why did you feel the need to say that?
For the comment above, the more relevant denominator is all humans vs. all developers. If you use all humans as the denominator, he's easily in the top 1% or 0.001% (I haven't followed his work closely, but you'd only have to be a good dev to be in top 1% of the global population).
Thank you, perhaps I worded it harshly, but that was my general feeling. Being a good developer already is a high level. Being able to start impressive-sounding projects that never materialize into anything is a luxury for which most competent developers simply don't have the extra energy.
>> Geohot is easily a 99.999 percentile developer
Really?
"The best model of a programming AI is a compiler... You give it a prompt, which is “the code”, and it outputs a compiled version of that code. Sometimes you’ll use it interactively, giving updates to the prompt after it has returned code, but you find that, like most IDEs, this doesn’t work all that well and you are often better off adjusting the original prompt and “recompiling”."
Really?
Programming languages, "the code", are languages specifically designed to concisely convey intent to a compiler.
If you do not understand his point, you need to read more about our field.
This.
I think his excellency in his own trade limited his vision for the 99% who just want to get by in the job. How many dev even deal with compiler directly these days? They write some code, fix some red underlines, then push, pray and wait for pipeline pass. LLMs will be gods in this process, and you can even beg another one if your current one does not work best.
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.
Author here. I agree with this comment, but if I wrote more like this my blog post would get less traction.
"LLM coding tools are search-based program synthesizers," in my mind this is what compilers are. I think most compilers do far too little search and opt for heuristics instead, often because they don't have an integrated runtime environment, but it's the same idea.
"Plenty of effective engineering tools are stochastic," sure but while a SAT solver might use randomness and that might adjust your time to solve, it doesn't change the correctness of the result. And for something like a fuzzer, that's a test, which are always more of a best effort thing. I haven't seen a fuzzer deployed in prod.
"Determinism comes from external specs and tests," my dream is a language where I can specify what it does instead of how it does it. Like the concept of Halide's schedule but more generic. The computer can spend its time figuring out the how. And I think this is the kind of tools AI will deliver. Maybe it'll be with LLMs, maybe it'll be something else, but the key is that you need a fairly rigorous spec and that spec itself is the programming. The spec can even be constraint based instead of needing to specify all behavior.
I'm not at all against AI, and if you are using it at a level described in this post, like a tool, aware of its strengths and limitations, I think it can be a great addition to a workflow. I'm against the idea that it's a magical English compiler, which is what I see in public discourse.
I think the key insight I walked away with from this whole thread, for me, was:
A compiler takes source and maps it to some output. Regardless of the compiler detail, this is an atomic operation; you end up with source (unmodified) and an artifact.
These “agent workflows” are distinctly different.
The process of mapping prompt to an output is the same; but these agent workflows are destructive; they modify the source.
Free reign over the entire code base; They modify the tests. The spec, the implementation.
It seems like this is a concept people are still struggling with; if your specification is poorly defined, and is dynamically updated during the compilation process, the results are more than just non deterministic.
Over time, the specification becomes non deterministic.
Thats why unsupervised agents go “off the rails”; not because the specification cant be executed, but because over time the spec drifts.
That doesnt happen with compilers.
In your blog post: “Most people do not care to find the truth, they care about what pumps their bags”
in your HN comment: “I agree with this comment, but if I wrote more like this my blog post would get less traction.”
Seems like you also not care about the truth.
This is bait. The comment and the blog post say mostly the same thing, the debate is around the subtle edges.
It's not a "compiler," it's a "probabilistic code synthesizer guided by your constraints"
The latter is technically more specific and correct than the former, but it's 7 words instead of 1. And the word compiler is understood to encompass the latter, even if most compilers aren't that. They are both "a tool in a workflow"
He cares for the truth by making it accessible to more people.
You said it before I could. Amen.
People knock "English as a programming language", but in my opinion this is the whole value of AI programming: by the time you've expressed your design and constraints well enough that an LLM can understand it, then anyone can understand it, and you end up with a codebase that's way more maintainable than what we're used to.
The problem of course is when people throw away the prompt and keep the code, like the code is somehow valuable. This would be like everyone checking in their binaries and throwing away their source code every time, while arguments rage on HN about whether compilers are useful. (Meanwhile, compiler vendors compete on their ability to disassemble and alter binaries in response to partial code snippets.)
The right way to do AI programming is: English defines the program, generated code is exactly as valuable as compiler output is, i.e. it's the actual artifact that does the thing, so in one sense it's the whole point, but iterating on it or studying it in detail is a waste of time, except occasionally when debugging. It's going to take a while, but eventually this will be the only way anybody writes code. (Note: I may be biased, as I've built an AI programming tool.)
If you can explain what needs to be done to a junior programmer in less time than it takes to do it yourself, you can benefit from AI. But, it does require totally rethinking the programming workflow and tooling.
I don't think that a prompt can be a valuable object, similar to how code used to be. Unless Mira Murati is successful at scaling her approach to deterministic inference, a prompt is fragile and transient. And even if she is successful, LLM updates make a prompt much less useful over longer time horizons.
I think that the only useful objects to keep right now are DSPy programs together with well-crafted examples, with examples being the most valuable because they are transferable across models and architectures.
I also noticed several people in the thread comparing coding assistants to junior programmers. I disagree. The only parallel is that they will do what you tell them to. Otherwise, a coding assistant can hold an entire codebase in context, reason across patterns, and generate boilerplate faster than any human. That capability has no human analogue. And unlike a junior, they have no agency, so the comparison breaks down on multiple fronts.
Excellent response, completely agree.
It's not surprising that you're finding problems with the article. It's written by George Hotz aka Geohot.
I've seen some engaging, thought-provoking, and original thoughts from Geohot in the past, but this post absolutely was not one of them.
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.
I think this comes down to levels of intelligence. Not knowledge, I mean intelligence. We often underestimate the amount of thinking/reasoning that goes into a certain task. Sometimes the AI can surprise you and do something very thoughtful, this often feels like magic.
Both CRUD and boilerplate are arguably a tooling issue. But there are also a bunch of things only AI will let you do.
My tests with full trace level logging enabled can get very verbose. It takes serious time for a human to parse where in the 100 lines of text the relevant part is.
Just telling an AI: "Run the tests and identify the root cause" works well enough, that nowadays it is always my first step.
Yesterday I used Opus to diagnose an error and it sent me down a bunch of wrong paths, suggested fixes with bad unintended consequences. If I hadn’t carefully guided it and corrected it, not only would the bug not have been fixed but it would have made things worse. My point being that if you don’t have the domain knowledge and put on your thinking cap then you will likely be screwed. But this is not how AI is sold.
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.
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!
It was such a great study imo and rightfully deserves a lot of attention since it's a great alternative to twitter vibes.
But to stop here and say AI coding doesn't work will just not hold up well. We have a sample size of 16 developers for 250 tasks.
Here is my data point: adding AI to your engineering team really is like adding a new member. At first it slows everybody down: explain this, explain that, stupid mistake made that the experienced dev would have avoided. But over the months you learn how to get the most out of them: they speak fluently all programming languages, don't mind writing 20 tests or coming up with good industry ideas to your problems.
Over time I have come to appreciate that the market is rather smart and even hype has its place. You often have to cross a line to know you crossed it, especially with something as fuzzy and quickly changing as technological progress hitting the messy real world. But then again, we need the heretics to stay smart and not follow an emperor without clothes.
Just putting this up as a reference the next time this comes up on HN. The study data shows that the median task is 1.5hrs and the 15 minutes that developers think they saved was actually more than that many minutes less researching, testing, and writing code and the 15 minutes longer they actually spent was more idle (5mins) and waiting for AI (5 mins) and reviewing and prompting dominating their work over actually writing code.
The person who showed a speed-up indicated over a week of prior experience with cursor while all others under a week.
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.
I feel the same way. After 30+ years coding, I know what I want to build, but finding the time to work on it and the focus is harder than it used to be.
I feel like many opinion pieces on AI coding are written from the perspective of highly experienced software engineers, often from a kind of ivory tower. (even that study they cite was based on “16 experienced open-source developers.”)
But for people who aren’t seasoned coders, these tools are incredibly valuable. I have some coding experience myself, but it’s never been my profession (I’m a visual artist). Now, I can accomplish in an afternoon what would otherwise take me days. Two months ago I left my job to work solo on my video game, and even though my budget is limited, I still make sure to keep Claude and ChatGPT. Also, being able to write something on my phone at 1 a.m. when I can’t sleep, send it to Codex, and then test it first thing in the morning at my computer feels pretty magical. It also takes away the worry of “what if this isn’t the best way to do it?” since refactoring parts of my codebase is now so easy. It helps not just with writing code, but also with removing the fear that might otherwise keep me from sitting down and getting the work done.
That said, I understand that much of the criticism is really aimed at the marketing hype around these tools and the broader “this will replace the engineers at your company” narrative.
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.
But what about the tests usefulness? Tests enforce contracts, contracts are about the domain, not the implementation. The number of tests don't actually matter as much as what is being actually verified. If you look at the code to know what to tests, you are doing it wrong.
The usefulness is in saving time boilerplating, plus figuring out tests I may not have thought of.
But I do closely review the code! It turns the usual drudge of writing tests into more of a code review. Last time I did it it had some mistakes I needed to fix for sure.
There shouldn't be boilerplate in test code. It should be refactored into harnesses, utils, and fixtures instead.
While absolutist, I think this is a good goal! AI wont do that unprompted. It will get the job done TM. But not elegantly.
A lot of the tests have those things. Boilerplate becomes knowing which to use, as well as the it.each(...) etc. ceremonies
I'm not disagreeing per se, but in my experience my tests are so disposable they're never worth investing that much engineering effort in past getting them to pass
> 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/
I’m someone with ADHD who takes prescribed stimulants and they don’t make me work faster or smarter, they just make me work. Without them I’ll languish in an unfocused haze for hours, or zone in on irrelevant details until I realise I have an hour left in the day to get anything done. It could make me 20% less intelligent and it would still be worth it; this is obviously an extreme, but given the choice, I’d rather be an average developer that gets boring, functional code done on time than a dysfunctional genius who keeps missing deadlines and cannot be motivated to work on anything but the most exciting shiny new tech.
I have family that had ADHD, as a kid (they called it “hyperactivity,” back then). He is also dyslexic.
The ADHD was caught early, and treated, but the dyslexia was not. He thought he was a moron, for much of his early life, and his peers and employers did nothing to discourage that self-diagnosis.
Since he learned of his dyslexia, and started treating it, he has been an engineer at Intel, for most of his career (not that I envy him, right now).
You have to realize that ADD meds are meant only for people with ADD, not healthy people at the prime of their life. Excess neurochemicals can have the opposite effect.
Their benefits when used as intended are solidly documented in research literature.
Research on _13_ people, that's a very important caveat when evaluating something like adderal.
It’s interesting how science can become closer to pseudoscience than proper research through paper-milling.
It seems like that with such small groups and effects you could run the same “study” again and again until you get the result that you initially desired.
So it should be easy to find studies that prove that non-ADHD people that take it, have dramatically improved productivity.
It's very easy to find studies that prove that Adderall (etc.) improve non-ADHD people's cognition ability. And it's equally easy to find studies that prove otherwise. The parent comment is very spot on. You can find evidence supporting anything nowadays.
https://pmc.ncbi.nlm.nih.gov/articles/PMC3489818/table/tbl1/
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 better on their own. I haven’t met a single one that actually had their productivity decline (after an adjustment period, of course), after giving up Adderall. In fact, I know several, that have had their careers really take off, after giving it up.
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.
I don't think that it matters, in this context, as a lot of folks here, have their minds made up, already, and won't let anything interfere.
They'll need to learn, the same way I see lots of people learn.
It's been around long enough, though, that all the Adderall-eating people should have established a Gattaca-like "elite," with all us "undermen," scrabbling around at their feet.
Not sure why that never happened...
As someone with diagnosed ADHD, and prescribed something similar:
It's not that they make you superhuman - I don't think I'm any "smarter" on them. It's just that without them, my "productive" bursts would be at really random times (11PM or 2AM), and make it very hard to fit into a "normal" schedule with the rest of society (I would frequently fall asleep in classes or meetings).
So it's more that it allows you to "rearrange" the same (or slightly larger) amount of work but into a more reasonable, traditional schedule. And for certain things, helps more than that. But it's not a miracle drug by any means.
Ironically the METR study n=20
Note that the study is just n=13 and on subjects without ADHD.
That’s the deal.
People without ADHD take it, believing that it makes them “super[wo]men.”
I had a problem client that I ended up firing and giving money back to about 15 years ago. Lot of red flags, but the breaking point was when they offered me adderall so I could "work faster".
That said, I'll leave the conclusions about whether it's valuable for those with ADHD to the mental health professionals.
Thanks again, diarrhea
I suppose you've never used Adderall during coding sessions before (and assuming you don't have a prescription for ADHD).
I used it when it was called Ritalin. It interacts with alcohol, too. Interesting stuff (not exactly the same stuff, but damn similar).
A lot of it. Other stuff, too, that makes it look like a cup of weak tea, but it’s been 45 years.
I’m pretty familiar with the illusion of productivity.
Adderall is not Ritalin. They may both be stimulants, but they are different. They have different active ingredients, mechanisms of action, durations of action. Not really that similar in my experience. Ritalin is kind of weak, honestly.
>I’m pretty familiar with the illusion of productivity
II do not have ADHD and I'm familiar with successfully using Aderrall for actual productivity. YMMV. Turns out not everyone's brain chemistry is the same.
Eh. Not worth arguing over. I know the drill.
I just make sure there's a place to go, if the wheels fall off.
Cheers.
Kind of surprised by this take - I use openpilot often and also use claude code.
I kind of consider them the same thing. Openpilot can drive really well on highways for hours on end when nothing interesting is happening. Claude code can do straight forward refactors, write boilerplate, do scaffolding, do automated git bisects with no input from me.
Neither one is a substitute for the 'driver'. Claude code is like the level 2 self driving of programming.
Again, can't help but wonder when we might improve this conversation by more strongly defining "what kind of programming."
It's just like "Are robots GOOD or BAD at building things?"
WHAT THINGS?
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.
You made a forest hut and you are calling out people who build skyscrapers - gatekeepers.
No. I'm just saying: "yes, AI can code."
no one is disagreeing. you just havent discovered the true costs yet
what is the cost of enabling someone to create little pieces of software if he otherwise wouldn't? I'm no advocate of vibe coding serious commercial software, but to do little DIY stuff - absolutely.
No one is forbidding people creating little pieces of software.
But creating little pieces of software was already available, for example I make most of my DIY software in a spreadsheet.
There are tons upon tons of low code possibilities or already existing software packages that need a bit of configuration that one can use and using AI or LLM's is not bringing anything that is revolutionizing access to computation or tailoring software. Just get your head around Excel or LibreOffice Calc and most of your DIY software needs are covered.
What LLM's and AI is bringing to the table is illusion of being able to create software exactly like people who have all the theoretical background or experience in building it. (which seems the person I originally replied to be one of those)
So as my original comment the problem is: that people building a forest hut are convinced that only if they just put more sticks on top, they will manage to build a skyscraper.
I'm so confused. So now you're an elitist gatekeeper to the world of programming? I entered w/o knowledge, and my apps are pretty useful to myself and some others. They're not "little pieces of software". They are fully-working, self-contained, apps with lots of unique code. Some are better than many apps that existed 10 years ago, but you seem to resent that. Also, whatever you do is relatively "high-level" programming on top of the work of those who created hardware and engineered programming languages, compilers and SDKs.
its awesome and fun but people throwing shit they dont understand how it 100% works online is a tale as old as people paying attention. which apprentnly isnt that long. fuck off
> I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me.
This describes me pretty well too, though I do have a tiny bit of programming experience. I wrote maybe 5000 lines of code unassisted between 1995-2024. I didn't enjoy it for the most part, nor did I ever feel I was particularly good at it. On the more complex stuff I made, it might take several weeks of effort to produce a couple hundred lines of working code.
Flash forward to 2025 and I co-wrote (with LLMs) a genuinely useful piece of back office code to automate a logistics problem I was previously solving via a manual process in a spreadsheet. It would hardly be difficult for most people here to write this program, its just making some API calls, doing basic arithmetic, and displaying the results in a TUI. But I took a crack at it several times on my own and unfortunately between the API documentation being crap and my own lack of experience, I never got to the point where I could even make a single API call. LLMs got me over that hump and greatly assisted with writing the rest of the codebase, though I did write some of it by hand and worked through some debugging to solve issues in edge cases. Unlike OP, I do think I reasonably well understand what >90% of the code is doing.
> 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.
So yeah, to the people here saying the above sentiment is BS - its not. For people who have never worked in programming or even in tech, these tools can be immensely useful.
I think it's like CMS and page builders enabling people to build their own websites without html and server knowledge. They're not making web developers disappear, instead there are more web developers now because those some of those people would eventually outgrow their page builders and need to hire web developers.
This is the optimistic view that I see around. I go back and forth. I've had some work that was the result of "vibe coders" hitting a wall with its capabilities.
The crucial part is security.
If the apps runs locally it doesn’t matter, if it‘s connected to the net it could be the seed for the next Mirai bot network.
Apps running locally can also be subject to security issues. What you're trying to say is probably "apps not using untrusted input". If an app takes no input all, I guess we could say that security isn't an issue, but there could still be safety issues.
It’s a pretty good solution for creating live mockups. A designer on my team came back eight hours after a meeting with a fully vibe coded, multi-page interface. I was honestly blown away. I had no idea this was the state of what’s possible with these tools.
Was it a real website? No, but it’s a live mockup way better than any Figma mock or rigid demo-ware.
Oh I'd never argue that. Cloud stuff is truly beyond the complexity I'd get involved with at the moment.
Also design. All the vibe coded apps always look like absolute ass.
I could say the same for lots of non-vibe-coded apps. Have you considered that modern vibe-coding can easily produce apps that look better than anything from 20 years ago thanks to all the modern frameworks? Heck, one-shotting a GUI or website will yield better-looking results than anything published by Debian or FreeBSD, lol.
What have you actually made?
What's the intent behind your question?
The Internet is awash with people making the same claims you are, but where are the actual results that we can see and use? Where are all these supposed new programs that were only possible to make because of generative ai? The number of new apps in the app store is flat. Still getting the same amount in 2025 as in 2022.
App-store listing is a whole other animal. I don't care to go through all that just to share my app. I also don't care to resolve every technical issue others experience. Every time I've thought about generating revenue by selling my apps, two thoughts come to mind: my code is not professional-grade, and the field is so competitive than within months a professional will likely create a better app so why pollute the web with something subpar.
The hacker on the street corner isn't distributing his "secret sauce" because it wouldn't meet standards, but it works well for him, and it was cheap/free.
Sounds like were getting at something in the conversation. For the professional developer generative ai is another tool, making us maybe a bit more capable than before. For the amateur it is a breakthrough enabling amateurs to tackle things that are wildly more ambitious than what they could before. But it's still amateur just-good–enough–for-personal-use software. Productising software is still 90% of the work of professional software development, and this is why we're not seeing a jump in the amount of for-sale software. What numbers should we track for the amount of amateur software? One number I have seen is that the npm downloads of React have jumped a lot in the last year. What this tells us about what additional stuff people are doing with React I don't know.
I like that take, and confirms I shouldn't yet spend my time trying to sell what I make.
Evaluating your empirical experience by judging the complexity you're impressed by.
Valid inquiry. In relative terms I'm the Indian on a street corner who hacks things together using tools professionally designed by others. Among the repos I've chosen to publicly share: https://github.com/sm18lr88
> Don't ask me how they work; they just do. Sure the engineering may be abysmal, but it's good enough to work.
I've worked on several projects from a few different engineering disciplines. Let me tell you from that experience alone, this is a statement that most of us dread to hear. We had nothing but pain whenever someone said something similar. We live by the code that nothing good is an accident, but is always the result of deliberate care and effort. Be it quality, reliability, user experience, fault tolerance, etc. How can you be deliberate and ensure any of those if you don't understand even the abstractions that you're building? (My first job was this principle applied to the extreme. The mission demanded it. Just documenting and recording designs, tests, versioning, failures, corrections and even meetings and decisions was a career in itself.) Am I wrong about this when it comes to AI? I could be. I concede that I can't keep up with the new trends to assess all of them. It would be foolish to say that I'm always right. But my experience with AI tools hasn't been great so far. It's far easier to delegate the work to a sufficiently mentored junior staff. Perhaps I'm doing something wrong. I don't know. But that statement I said earlier - it's a fundamental guiding principle in our professional lives. I find it hard to just drop it like that.
> But the article is highly opinionated. It's like saying only phD's can be called scientists, or only programmers can be computer hackers.
Almost every single quality professional in my generation - especially the legends - started those pursuits in their childhood under self-motivation (not as part of school curriculum even). You learn these things by pushing your boundary a little bit every day. You are a novice one day. You are the master on another. Are you absolutely pathetic at dancing? Try ten minutes a day. See what happens in ten years. Meanwhile, kids don't even care about others' opinion while learning. Nobody is gatekeeping you on account of your qualifications.
What they're challenging are the assumptions that vibe/AI coders seem to hold, but don't agree with their intuition. They are old fashioned developers. But their intuitions are honed over decades and they tend be surprisingly accurate for reputed developers like Geohotz. (There are numerous hyped up engineering projects out there that made me regret ignoring my own intuition!) It's even more valid if they can articulate their intuition into reasons. This is a very formal activity, even if they express them as blog posts. Geohotz clearly articulates why he thinks that AI copilots are nothing more than glorified compilers with a very leaky specification language. It means that you need to be very careful with your prompts, on top of tracking the interfaces, abstractions and interactions that the AI currently doesn't do at all for you. Perhaps it works for you at the scale you're trying. But lessons like the Therac-25 horror story [1] always remind us how bad things can go wrong. I just don't want to put that extra effort and waste my time reviewing AI generated code. I want to review code from a person whom I can ask for clarifications and provide critiques and feedback that they can follow later.
[1] https://thedailywtf.com/articles/the-therac-25-incident
I'm 72, a dev for 40 years. I've lost a step or two. It's harder to buckle down and focus, but using AI tools have enabled me to keep building stuff. I can spec a project, have an agent build it then make sure it works. I just code for fun anyway.
I love using AI to prototype that something is possible then go and build it myself while borrowing bits from that initial MVP. The other night I wanted to build a browser extension that could intercept requests from a tab, claude got me something working in about 10 minutes with a couple prompts and a local storage session and then I toyed with the UI a bit to see what was possible.
Now after a weekend morning I have something much slimmer, predictable and sophisticated running... my extension shows a list of repeated responses and I can toggle which one to send to a localhost api that has a simple job queue to update a sqlite db with each new entry, extract the important parts and send it to my lm studio gpt oss 20b endpoint for some analysis and finally and send me a summary on telegram.
I know what I want in my head but cutting down the experimenting or PoC step down to minutes vs hours is pretty useful and as a competent enough dev it's elevated what I can get done now so I can take on more work than I would have by myself previously.
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).
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.
The truth will emerge naturally through labor market competition in the long-run. You do you. I will be using these tools extensively. Good luck out there in the arena.
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.
I’ve found that ChatGPT and Perplexity are great tools for finding “that article I skimmed a year ago that talked about…”.
I agree. I think a better analogy than a compiler is a search engine that has an excellent grasp of semantics but is also drunk and schizophrenic.
LLMs are really valuable for finding information that you aren't able to formulate a proper search query for.
To get the most out of them, ask them to point you to reliable sources instead of explaining directly. Even then, it pays to be very critical of where they're leading you to. To make an LLM the primary window through which you seek new information is extremely precarious epistemologically. Personally, I'd use it as a last resort.
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.
> Personal experience (data points count = 1), as a somewhat seasoned dev (>30yrs of coding), it makes me WAY faster.
> 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.
One of these is not true.
With libraries, it's either you HAVE to use it, so you spend time being acquainted with it (usually a couple hours to make sense of its design, the rest will come on a needed basis) or you are evaluating multiple ones (and that task is much quicker).
> you are evaluating multiple ones (and that task is much quicker).
Of course the latter. And of course I ask the AI to help me select a libray/module/project/whatever that provides what I need. And I ask the AI to classify them by popularity/robustness. And then I apply whatever little/much I know about the space to refine the choice.
may go as far as looking at examples that use the API. And maybe rummage through the code being the API to see if I like what I see.
The whole thing is altogether still way faster than having to pick what I need by hand with my rather limited data ingestion capabilities.
And then, once I've picked one, connecting to the API's is a no-brainer with an LLM, goes super fast.
Altogether major time saved.
What an aggressive tone.
By the author's implied definition of compiler, a human is also a compiler. (Coffee in, code out, so the saying goes.)
But code is distinct from design, and unlike compilers, humans are synthesizers of design. LLMs let you spend more time as system architect instead of code monkey.
I wouldn't over index on his tone here- that's the only tone I've seen him use.
Doesn’t make it any better.
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.
"that obviously made no sense" is bizarre.
Waymo's driving people around with an injuries-per-mile rate that's lower than having humans do it. I don't see how that reconciles with "obviously made no sense".
"He hates 'em because he ain't 'em" is essentially the whole theme of this rather-disappointing post.
I think he's having a bad day. He's smarter than this.
> Playing , trying and failing is crucial to make our world nicer. Not overthinking is key, see later what works and why.
It would be, if there weren't actual important works that needs funding.
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.
I expect much of this can be solved with better architecture: smaller, more independent components. Break large code bases up into independent libraries, and LLMs can work again because they need much less code in their context.
Suggesting I restructure my code base to work better with a non-deterministic black box feels like an instance of Conway’s law[1] that should be avoided.
https://en.m.wikipedia.org/wiki/Conway%27s_law
You’re free to avoid it but maybe your competition will do it and may outpace you because of it. Conways law just states that architecture follows organizational structure so it’s only to be expected that ai generated software has an ai influenced architecture.
Yes, I think that’s the other position. But my bet is that significant software projects built today on today’s LLMs will be outpaced by teams in the future who avoided delegating that complexity to them. It’s a bet, but perhaps it’s wrong.
> 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.
People repeating articles or papers. I know myself. I know from my own experiences what the good and bad of practice A or database B is. I don't need to read a conclusion by some Muppet.
Chill. Interesting times. Learn stuff, like always. Iterate. Be mindful and intentional and don't just chase mirrors but be practical.
The rest is fluff. You know yourself.
The takeaway from the paper is you don’t know yourself. It’s one paper, and a small sample size, but attempting to refute its conclusion by stating it’s false doesn’t really get us anywhere.
Lol. Maybe you need enough experience to understand if you think "it's written in a paper" is proof of anything, specially over the experience of people who do actual work and have been profilic over long periods.
This is shown in figure 5 of the paper. https://arxiv.org/pdf/2507.09089
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.
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 the chief reason I don't use integrations. I just use chat, because I want to physically understand and insert code myself. Else you end up with the code overtaking your understanding of it.
Yes. I'm happy to have a sometimes-wrong expert to hand. Sometimes it provides just what I need, sometimes like with a human (who are also fallible), it helps to spur my own thinking along, clarify, converge on a solution, think laterally, or other productivity boosting effects.
I’m experiencing something similar. We have a codebase of about 150k lines of backend code. On one hand, I feel significantly more productive - perhaps 400% more efficient when it comes to actually writing code. I can iterate on the same feature multiple times, refining it until it’s perfect.
However, the challenge has shifted to code review. I now spend the vast majority of my time reading code rather than writing it. You really need to build strong code-reading muscles. My process has become: read, scrap it, rewrite it, read again… and repeat until it’s done. This approach produces good results for me.
The issue is that not everyone has the same discipline to produce well-crafted code when using AI assistance. Many developers are satisfied once the code simply works. Since I review everything manually, I often discover issues that weren’t even mentioned. During reviews, I try to visualize the entire codebase and internalize everything to maintain a comprehensive understanding of the system’s scope.
I'm very surprised you find this workflow more efficient than just writing the code. I find constructing the mental model of the solution and how it fits into existing system and codebase to be 90% of effort, then actually writing the code is 10%. Admittedly, I don't have to write any boilerplate due to the problem domain and tech choices. Coding agents definitely help with the last 10% and also all the adjacent work - one-off scripts where I don't care about code quality.
I doubt it actually is. All the extra effort it takes to make the AI do something useful on non trivial tasks is going to end up being a wash in terms of productivity, if not a net negative. But it feels more productive because of how fast the AI can iterate.
And you get to pay some big corporation for the privilege.
> Many developers are satisfied once the code simply works.
In the general case, the only way to convince oneself that the code truly works is to reason through it, as testing only tests particular data points for particular properties. Hence, “simply works” is more like “appears to work for the cases I tried out”.
I wrote a couple python scripts this week to help me with a midi integration project (3 devices with different cable types) and for quick debugging if something fails (yes, I know there are tools out there that do this but I like learning).
I’m could have used an LLM to assist but then I wouldn’t have learned much.
But I did use an LLM to make a management wrapper to present a menu of options (cli right now) and call the scripts. That probably saved me an hour, easily.
That’s my comfort level for anything even remotely “complicated”.
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?
> AI workflows are, in practice, highly non-deterministic. While different versions of a compiler might give different outputs, they all promise to obey the spec of the language, and if they don’t, there’s a bug in the compiler. English has no similar spec.
AI coding shines when this is a good thing. For instance, say you have to adapt the results of one under-documented API into another. Coding agents like Claude Code can write a prototype, get the real-world results of that API, investigate the contents, write code that tries to adapt, test the results, rewrite that code, test again, rewrite again, test again, ad nauseam.
There are absolutely problem domains where this kind of iterative adaptation is slower than bespoke coding, where you already have the abstractions such that every line you write is a business-level decision that builds on years of your experience.
Arguably, Geohot's low-level work on GPU-adjacent acceleration is a "wild west" where his intuition outstrips the value of experimentation. His advice is likely sound for him. If he's looking for a compiler for the highly detailed specifications that pop into his head, AI may not help him.
But for many, many use cases, the analogy is not a compiler; it is a talented junior developer who excels at perseverance, curiosity, commenting, and TDD. They will get stuck at times. They will create things that do not match the specification, and need to be code-reviewed like a hawk. But by and large, if the time-determining factor is not code review but tedious experimentation, they can provide tremendous leverage.
> 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?
Yes. He mentions that in passing that saying people will accuse him of hating on it because he didn't profit from it. I think his point of view is that his company's attempt was smaller scale and not part of the $10B+ waste?
In any case I don't fully understand what he's trying to say other than negating the hype (which i generally agree with), but not offering any alternative thoughts of his own other than- we have bad tools and programming language. (why? how are they bad? what needs to change for them to be good?)
Well, he’s currently running a startup aimed at making better tooling for the space. So, he’s putting his time where mouth is.
Before he deleted his Twitter account, he claimed AI was already being better than humans and that singularity was only a few years away.
He's confidently wrong a lot. (Even if I happen to agree with his new, more sober take on AI coding here.)
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.
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.
Me too.
I used to be a bit more open minded on this topic but im increasingly viewing any programmers who use AI for anything other than brainstorming and looking stuff up/explaining it as simply bad at what they do.
Is this fundamentally different from them copy pasting code from StackOverflow or random blog posts, without understanding it?
You know, aside from AI making it super easy and fast to generate this tech debt in whatever amounts they desire?
Even when copy-pasting an entire function from stack overflow, you generally still need to have some understanding of what the inputs and outputs are, even if it remains somewhat of a black box, so that you can plug it into your existing code.
AI removes that need. You don't need to know what the function does at all, so your brain devotes no energy towards remembering or understanding it.
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 that most natural languages are a very poor tool to write code specification in.
Specifically, natural language is:
Having something at our disposal that you can write code specs in, that is as easy as natural language yet, more concise, easy to learn and most of all not so anal/rigid as typical code languages are would be fantastic.Maybe LLMs can be sued to design such a thing ?
> Maybe LLMs can be sued to design such a thing
nice misspelling (or a joke?), related to all the lawsuits around LLMs.
Joking aside, it’s already there in a sense. Several times I started with a brief outline of what the prototype should do (an HTML/CSS/JS app), and sure enough, refinements and corrections followed. When the final version worked more or less as expected, I asked the LLM to create a specification (a reproducing prompt) of everything we made together. Even if the vibe-coded prototype is dropped, the time wasn’t wasted, I probably would never have come to the same bullet list specification without having an actual working app at my disposal to test and evaluate. So paradoxically this specification even might be used by a human later
Natural language becomes like an abstraction above the high-level languages then, even above things like Scratch and Basic. But you can't define how big of an abstraction it is exactly, like I can say "write an GPS app" or "write a function that does x"
The former is more abstracted and the latter is less. It's this ambiguity and non-determinism that's tricky.
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.
We are turning specifications into software precisely because English (and any natural languages) lacks the formality that makes it not reliable (necessary quality for a tool), but great for imagination (the source of invention).
We always start from natural language. RFC, docs, tickets,... are in natural language. But gaining formality (losing ambiguity) is what programming is (software engineering is doing programming well). People that struggled with programming struggle in fact with formality.
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
These workflows always surprise me. Isn’t this what you’ve been doing with humans all along? Write up a basic project plan likely following some structure the product team likes. Share it with the eng team. One to a few members of the eng team writes up a more specific plan. Everyone gets together again and goes through the specific plan to iron out the kinks. You the implement the plan.
I’ve seen at my workplace people are more willing to help Claude with a plan than their fellow humans. I pointed that out and one engineer replied with “well I know Claude will read the documentation”. It’s a depressing observation but I don’t know if it’s wrong.
I can implement 20 such features on my own each day with no input from others though. That's why i am using this method in the first place.
This is just basic spec based development, don't see what's so interesting about this. People have been using this method for quite a while, even Kiro now uses this for its entire process.
>People have been using this method for quite a while, even Kiro now uses this for its entire process.
Kiro is terrible at this (I assume it's your product), maybe stop shilling it every now and then
Anyone dismissing AI coding without having seriously tried it or looked at the outputs of people who have can't be taken seriously. Yes, it shouldn't worked in theory. But it's disturbingly good in practice, for someone who knows what they are doing.
So anyone that doesn't know what they're doing can dismiss it without seriously trying it? I mean, I agree, but I feel like you wouldn't with this implication of what you're saying...
> It’s why the world wasted $10B+ on self driving car companies that obviously made no sense
Anyone knows what the author is referring to here?
I'm guessing a lot more than $10B has been invested into self driving. So probably referring to failed companies. But which ones?
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!
There's the rub: AI coding is like super tab complete. It's a useful tool. Full stop.
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.
On a sidetrack, I was looking at the email address in the footer and wondered how cool it would have looked if geohot actually had a Hotmail address.
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.
George famously started a self driving hardware-as-an-addon company. He started after both claiming self driving was easy, and reportedly taking up an Elon bounty/bet in the seven figure range to make self driving AI for Tesla.
I think some of the “hate” is the hype. We’re all tired of companies announcing ground breaking tech that isn’t readily available a decade later.
I don’t live in California (like most of the population of the planet) - Toronto for 18 years and now the American side of the Great Lakes.
Ice storms, snow, sleet, cold weather 5-6 months out of the year. Batteries suck in the cold, sensors fail or under-perform. Hell, door handles and windows struggle in this weather.
Waymo is not a thing in NY or Chicago or Minneapolis or Philadelphia (I could go on).
And that's just in North America where cities were built for cars and with cars in mind. Autonomous driving in Europe or Asia is likely a magnitude harder due to windy roads, non trivial intersections, complex interactions of humans, bikes, trams and cars etc.
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...
“Some people go as far as to believe that perception is reality and that truth is a construction.” To the author: ask them what they mean.
By the same token, a software developer could perhaps also be likened to a compiler, taking language and/or visual information as input and turning it into code.
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%.
This sounds like you haven't used one of these coding agents.
I'm piloting a swarm of coding agents 12+ hours a day, friend.
Seems like you should know that you're spouting bullshit if that's the case.
Seems like you should get better at picking up on when your priors are miscalibrated.
I use LLMs like autocomplete on steroids - fast but need reviews
> 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!
> 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.
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.
We've had 50+ years to do that. Progress has been unimpressive, to be charitable. It's time to let some different people try something else.
I really hate the comparison of AI to a compiler. It's not like I'm writing a codebase in English. I'm still writing codebases in programming languages. AI just helps manage all the text.
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.
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.
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
Dunno how it'll work with Claude Code, but I use the context7 MCP to feed up-to-date docs in copilot.
Sometimes that also doesn't work so I make a guiding document using whatever llms.txt the framework/language/platform offers or just wget the entire documentation, condense it into a single text file and use that while prompting.
Seems to work ok, especially for Svelte 5 where most LLMs except Gemini don't give me runes from the get-go.
>Dunno how it'll work with Claude Code, but I use the context7 MCP to feed up-to-date docs in copilot.
No wonder you've no idea about current capability of LLM based coding, copilot is far behind competition.
>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
> That's the point - it's a higher level of abstraction.
That's not what abstraction is. When I type `echo Hello, World`, I don't have to deal with graphic drivers and test rendering to have the text on the screen. And I don't have to worry that "Goodbye" will appear instead.
> Not unlike say a boss telling a junior to change something?
Junior don't stay junior for long. And bosses usually give juniors less time to grow than people are allocating AI tools to actually prove themselves. Github copilot was more than 3 years ago. Today a new hire is expected to be productive on day one.
> The only reason it works for many common programming workflows is because they are common. The minute you try to do new things, you need to be as verbose as the underlying language.
You can stop here. This is enough to change the game. SO MUCH time and money is spent on mostly-boilerplate line of business apps. If you don't understand this, you are in a bubble of some kind. The corporate world's IT departments and consulting agencies are filled with developers who write nothing but what boil down to custom-tailored CRUD apps. AI is absolutely KILLER for this kind of work.
If you're doing novel research, perhaps not. But that describes a relatively small portion of the worldwide developer community.
This kid is 35, by the way.
George, you post this after everyone already realized that LLMs plateaued.
Before that you were crying about the singularity and how we're super close it and in 6 months AI will be basically Einstein. Nothing has given me more joy than to see this AI slop fail.
Here's a 100 page document generated with AI and the other person will shrink it with AI at the end of the day those 2 lines of cognitive effort would've been a better deal than sending slop back and forth.
Who hurt you georgie?
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...
[dead]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
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).
> 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?
Because geo fenced driving in a few select cities with very favourable conditions is not what was promised. That's the crux. They promised us that we have self drive anywhere at anytime at the press of a button.
> Not a billion dollar business yet, maybe, but 300 cars generating five or six figures revenue per year each isn't far off.
I'm not sure how you get to 6 figures revenue. Assuming the car makes $100 per hour for 24x7 52 weeks a year we still fall short of 1 million. But let's assume you're right $300M revenue (not profit, are they even operating at a plus even disregarding R&D costs?) on investment of >10 billion (probably more like 100), seems like the definition of hype.
> (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).
What I don't understand with this argument, how are you proposing they become the dominant mode of transport. These services are competing with taxis, what do they offer over taxis that people suddenly switch on mass to self driving taxis? They need to become cost competitive (and convenience competitive) with driving your own car, which would significantly drive down revenue. Secondly if robotaxi companies take over transport, why would the public continue to build their infrastructure and not demand that these robotaxi companies start to finance the infrastructure they exclusively use?
I got to six figures by assuming that a human taxi driver makes maybe $30-40k at a guess, and an autonomous car can work 24/7. 6 figures is $100k minimum.
So yeah, right now they'd have to be at ten cities x 300 cars each to hit 300M revenue, but there's still plenty of room for growth. Or should be, assuming the Waymo model isn't maxed out supporting the current handful of cities.
But I'm not convinced they have to hit cost parity with personal cars, because the huge advantage is you can work and drive (or be driven). If NYC and LA rush-hour congestion time becomes productive time, there's your billions.
I drive but prefer to take transit for this reason - some of my colleagues are able to join work calls effectively while driving, but for whatever reason my brain doesn't allow that. Just paying attention to calls is enough, you want me to pay attention to the road AND the call?