Karpathy on Programming: “I've never felt this much behind”

4 days ago (twitter.com)

I admit to pangs of this, but it's really never made any sense because the implication is that the profession is now magically closed off to newcomers.

Imagine someone in the 90s saying "if you don't master the web NOW you will be forever behind!" and yet 20 years later kids who weren't even born then are building web apps and frameworks.

Waiting for it to all shake out and "mastering" it then is still a strategy. The only thing you'll sacrifice is an AI funding lottery ticket.

  • Finally a voice of reason. The tools will just get better and easier to use. I use LLMs now, but I'm not going to dump a bunch of time learning the new hotness. I'll let other people do that and pickup the useful pieces later.

    Unless your gunning for a top position as a vibe coder, this whole concept of "falling behind" is just pure FOMO.

    • Doing small project for customer. They have explicit instructions that I can't even use some unapproved AI... So well they are paying. So until it is actually forced I see no pressure to move there.

      And rest of my field. Automated tools do part of work. AI probably some, but not enough of actually verifying findings and then properly explaining the context and implications.

    • Yeah that's my view too. It's definitely fine to wait a couple of years (at least), and see what emerged as most effective and then just learn that, instead of dumping a ton of time now into keeping up with the hamster wheel.

      Unless you're in web dev because it seems like that's one of the few domains where AI actually works pretty well today.

      1 reply →

  • If anything I'd expect all these tools to be easier for new engineers to adopt, unburdened by how things were before.

    • > unburdened by how things were before.

      What burden are you talking about? Using LLMs isn't that hard, we have done harder things before.

      Sure, there will be people that refuses to "let go" and want to keep doing things the way the like them, but hey! I've been productive with vim (now neovim) for 25 years and I work with engineers that haven't mastered their IDEs at the same level. Not even close!

      Sure, they have have never been "burdened" by knowing other editors before those IDEs existed, but claiming that I would have it harder to use any of those because I've mastered other tools before is ridiculous.

  • Absolutely agree.

    I took this approach when the Kubernetes hype hit and it never limited my prospects.

  • People did say that in the 90s. Hence the rush to put everything on the web, whether there was any real business case for it or not. And most of it went up in flames at the end of that decade.

  • Eh, for myself as a middle-aged software engineer, it feels a little like the last chopper out of Saigon. I feel less and less confident that I can make as good a living in software for the next decade as I have for the last couple. Or if I want to. The job is changing so fast right now, and I’m not sure I like it. When I worked in big tech, I preferred being an IC over an EM or tech lead because I like writing code. Now it feels increasingly like you can’t be an IC in that way anymore. You’re now coding through others, either humans or AI.

    Sure, I can write code manually, but in my case I’m working full time on my own SaaS and I am absolutely faster and more effective with AI. It’s not even close. And the gains are so extreme that I can’t justify writing beautiful hand-crafted artisanal code anymore. It turns out that code that’s “good enough” will do, and that’s all I can afford right now.

    But long-term, I don’t know that I want to do that work, especially for some corporation. It feels like the difference between being a master furniture craftsman, and then going work in an IKEA factory.

I feel like many people in the comments aren't aware that Karpathy is an ML scientist for whom programming is a complementary skill, not a profession. The only reason he came up with "vibe coding" is because maximum complexity of his hobby projects made it seem believable. Maybe take his opinions about fate of programming with a grain of salt.

He is brilliant no doubt, but not in that field.

  • Maybe that's true, but I will say that one of the reasons I recommend his Python ML videos to people is not just the ML content but also his Python is good and idiomatic. So I would not agree; I think his programming is a well practiced skill.

    FWIW though I think his predicted worldview will render it very difficult to acquire this skill, as people grow reliant on gen AI for programming rudiments.

    • As far as "programming skill" goes, writing "good and idiomatic" Python is pretty bottom of the barrel. I don't think the GP is all that off, most people who are famous for some programming-adjacent skill (or even programming) aren't good at programming.

  • He's a pretty decent programmer.

    It's interesting that some months ago when his nanochat project came out the HN Anti-AI crowd celebrated him saying "I tried to use claude/codex agents a few times but they just didn't work well enough at all and net unhelpful, possibly the repo is too far off the data distribution"

    But now it is working for him he's suddenly not an expert...

    [1] https://news.ycombinator.com/item?id=45573521

    • What you’re calling the “crowd” was not the same people. Every time someone makes a claim like yours, I go and check and don’t see the same usernames in the conversation. “Different people have different opinions and different ways to express them” isn’t really an insight; it tells us nothing nor does it make anyone worthy of criticism.

      You can’t, in an honest argument, lump different strangers into a group you invented to accuse them of duplicity or hypocrisy.

    • > But now it is working for him he's suddenly not an expert...

      Or maybe he didn't lie then but is lying now?

  • Exactly, I would put more weight on this if it were coming from someone who actually works as a regular programmer in the industry

As an Opus user, I genuinely don’t understand how someone can work for weeks or months without regularly opening an IDE. The output almost always fails.

I repeatedly rewrite prompts, restate the same constraints, and write detailed acceptance criteria, yet still end up with broken or non-functional code.its very frustrating to say the least Yesterday alone I spent about $200 on generations that now require significant manual rewrites just to make them work.

At that point, the gains are questionable. My biggest success is having the model take over the first Design in my app and I take it from there, but those hundred lines if not thousand lines of code it generates are so Messi, it's insanely painful to refactor the mess afterwards

  • I have a hell of a time just getting any LLM to write SQL queries that have things like window functions, aggregates and lateral left joins - even when shoving the entire database schema DDL into the context.

    It's so frustrating, it regularly makes me want to just quit the profession. Which is why I still just write most code by hand.

    • I write a lot of SQL and I haven't had these issues for months, even with smaller models. Opus can one shot most of my queries faster than I could type them.

      Instead of stuffing the context with DDL I suggest:

      1. Reorganize your data warehouse. It needs to be easy to find the correct data. Make sure you use ELT clear layers, meaningful schemas, and have per-model documentation. This is a ton of work, but if done right the payoff is massive.

      2. I built a tool for myself to pull our warehouse into a graph for fuzzy search+dependency chain analysis. In the spring I made an MCP server for it and Claude uses that tool incredibly well for almost all queries. I haven't actually used the GUI or scripts since I built the MCP.

      Claude and Devstral are the best models I've used for SQL. I cannot get Gemini to write decent modern sql -- even the Gemini data science/engineer agents in Google Cloud. I occasionally try the paid models through the API and still haven't been impressed.

      5 replies →

    • If you really know SQL, writing an SQL query basically just feels like writing a prompt for a database client anyway, except it does exactly what you ask for.

      1 reply →

  • Most people have not fully grasped how LLM's work and how to properly utilize agentic coding solutions. That is the reason for issues when it comes to vibe coders having low quality code. But that is not the limitation of technology but the user (at this stage). Basically think of it this way everyone is the grandma that has been handed a palm pilot to use to get things done. Grandma needs an iPhone not a palm pilot but the problem is that we are not in that territory yet. So now consider the people who were able to use the palm pilot very successfully and well, they were few and they were the exception, but they existed. Same here. I have been using coding agent for over 7 months now and have written zero lines of code, in fact I don't know how to code at all. But i have been able to architect very complex software projects from scratch. Text to speech , automated llm benchmarking systems for testing all possible llama.cpp sampling parameters and more, and now im building my own agentic framework from scratch. All of these things are possible and more without writing one line of code yourself. But it does require understanding how to use the technology well to get this done.

    • If you don't know how to code then you are not able to judge what your producing accurately.

    • All of the applications you mention could be scoped as beginner projects. I don't think they represent good proofs of capability.

  • I hardly ever open an IDE anymore.

    I use Claude Code and Cursor. What I do:

    - use statically typed languages: TypeScript, Go, Rust, Python w/ types

    - Setup linters. For TS I have a bunch of custom lint rules (authored by AI) for common feedback that I've given. (https://github.com/shepherdjerred/monorepo/tree/main/package...)

    - For Cursor, lots of feedback on my desired style. https://github.com/shepherdjerred/scout-for-lol/tree/main/.c...

    - Heavy usage of plan mode. Tell AI something like "make at least 20 searches to online documentation", support every claim with a reference, etc. Tell AI "make a task for every little thing you'll implement"

    - Have the AI write tests, particularly the more expensive ones like integration and end-to-end, so you have an easy way to verify functionality.

    - Setup Claude Code GHA to automatically review PRs. Give the review feedback to the agent that implemented it, either via copy-pasting or tell the agent "fetch review comments and fix them".

    Some examples of what I've made:

    - Many features for https://scout-for-lol.com/, a League of Legends bot for Discord

    - A program to generate TypeScript types for Helm charts (https://github.com/shepherdjerred/homelab/tree/main/src/helm...)

    - A program to summarize all of the dependency updates for my Homelab (https://github.com/shepherdjerred/homelab/tree/main/src/deps...)

    - A program to manage multiple instances of CLI agents like Claude Code (https://github.com/shepherdjerred/monorepo/tree/main/package...)

    - A Discord AI bot in the style of my friends (https://github.com/shepherdjerred/monorepo/tree/main/package...)

    • Thanks for sharing. So the dumb question - do you feel like Claude Code & Cursor have made you significantly more productive? You have an impressive list of personal projects, and I can see how a power user of AI tools can be very effective with green field projects. Does the productivity boost translate as well to your day job?

      1 reply →

    • > make at least 20 searches to online documentation

      Lol sometimes I have to spend two turns convincing Claude to use its goddamn search and look up the damn doc instead of trying to shoot from the hip for the fifth time. ChatGPT at least has forced search mode.

      1 reply →

  • My trick is to explicitly roll play that we’re doing a spike. This gets all of the models to ignore all of the details they normally get hung up on. Once I have the basics in place, I can tell it to fix details.

    It’s _always_ easier to add more code than it is to fix broken code.

  • What does your software creation workflow look like? Do you have a design phase?

  • Why would you spend $200 a day on Opus if you can pay that for a month via the highest tier Claude Max subscription? Are you using the API in some special way?

  • Sometimes I have a similar file or related files. I copy their names and say use them as reference. Code quality improves by 10 times if you do so. Even providing a a example from framework's getting started works great too for new project.

    Yeah the pain of cleaning up small mess is great too. I had some tests failing and type failing issues, I thought I will fix it later by only using AI prompt. As the size was growing, failing Typescript issues was growing too. At some point it was 5000+ type issues and countless number of failing unit tests. Then more and more. I tried to fix with AI, since it was not possible fixing old way. Then I discarded the whole project when it was around 500k lines of code.

The only time I've felt this much behind was in high school when everyone was talking about how much sex they were having.

AI code is the Canadian girlfriend of programming.

  • Not being from the US, it took me a moment to realise that "she's in Canada" is a nice excuse for why nobody has met her.

  • Time to shell out the $200 my friend.

    • You need a lot more money than $200 if your code base is more than 100,000 lines.

      If only more people understood what quadratic attention means in the real world.

I am a software developer and mainly a programmer for decades now. I love programming. I love to be "once" with the computer. I will never give this joy up. If I need to sell shoes at daytime, I will program real computer programs in the evenings. If it won't be possible with modern machinery anymore, I will take my Commodore 64. I am a free man.

Edit: Corrected since/for. :-)

What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore.

This agentic arms race by C-suite know-nothings feels less like leverage and more like denial. We took a stochastic text generator, noticed it lies confidently, wipes entire databases and harddrives, and responded by wrapping it in managers, sub-agents, memories, tools, permissions, workflows, and orchestration layers so we don’t have to look directly at the fact that it still doesn’t understand anything.

Now we’re expected to maintain a mental model not just of our system, but of a swarm of half-reliable interns talking to each other in a language that isn’t executable, reproducible, or stable.

Work now feels duller than dishwater, enough to have forced me to career pivot for 2026.

  • I think AI-assisted programming may be having the opposite effect, at least for me.

    I'm now incentivized to use less abstractions.

    Why do we code with React? It's because synchronizing state between a UI and a data model is difficult and it's easy to make mistakes, so it's worth paying the React complexity/page-weight tax in order for a "better developer experience" that allows us to build working, reliable software with less typing of code into a text editor.

    If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all.

    How often have you dropped in a big complex library like Moment.js just because you needed to convert a time from one format to another, and it would take too long to hand-write that one feature (and add tests for it to make sure it's robust)? With an LLM that's a single prompt and a couple of minutes of wait.

    Using LLMs to build black box abstraction layers is a choice. We can choose to have them build LESS abstraction layers for us instead.

    • > If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all.

      I'm worried that there is a tendency in LLM-generated code to avoid even local abstractions, such as putting common code into separate (local functions), and even use records/structures. You end up with code that is best maintained with an LLM, which is good for the LLM provider and their future revenue. But we humans as reviewers and ultimate long-term maintainers benefit from those minor abstractions.

    • > If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all.

      I've had plenty of junior devs justify massive code bases of random scripts and 100+ line functions with the same logic. There's a reason senior devs almost always push back on this when it's encountered.

      Everything hinges on that "if". But you're baking a tautology into your reasoning: "if LLMs can do everything we need them to, we can use LLMs for everything we need".

      The reason we stop junior devs from going down this path is because experience teaches us that things will break and when they do, it will incur a world of pain.

      So "LLM as abstraction" might be a possible future, but it assumes LLMs are significantly more capable than a junior dev at managing a growing mess of complex code.

      This is clearly not the case with simplistic LLM usage today. "Ah! But you need agents and memory and context management, etc!" But all of these are abstractions. This is what I believe the parent comment is really pointing out.

      If AI could do what we originally hoped it could: follow simple instructions to solve complex tasks. We'd be great, and I would agree with your argument. But we are very clearly not in that world. Especially since Karpathy can't even keep up with the sophisticated machinery necessary to properly orchestrate these tools. All of the people decrying "you're not doing it right!" are emphatically proving that LLMs cannot perform these tasks at the level we need them to.

      51 replies →

    • > I'm now incentivized to use less abstractions.

      I'm incentivised to use abstractions that are harder to learn, but execute faster or more safely once compiled. E.g. more Rust, Lean.

      > If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all.

      LLMs benefit from abstractions the same way as we do.

      LLMs currently copy our approaches to solving problems and copy all the problems those approaches bring.

      Letting LLMs skip all the abstractions is about as likely to succeed as genetic programming is efficient.

      For example, writing more vanilla JS instead of React, you're just reinventing the necessary abstractions more verbosely and with a higher risk of duplicate code or mismatching abstractions.

      In a recent interview with Bret Weinstein, a former professor of evolutionary biology, he proposed that one property of evolution that makes the story of one species evolving into another more likely is that it's not just random permutations of single genes; it's also permutations to counter variables encoded as telomeres and possibly microsatellites.

      https://podcasts.happyscribe.com/the-joe-rogan-experience/24...

      Bret compares this to flipping random bits in a program to make it work better vs. tweaking variables randomly in a high-level language. Mutating parameters at a high-level for something that already works is more likely to result in something else that works than mutating parameters at a low level.

      So I believe LLMs benefit from high abstractions, like us.

      We just need good ones; and good ones for us might not be the same as good ones for LLMs.

      3 replies →

    • I've come to a similar conclusion. One example is how much easier it is to put an interface on top of sqlite. I've been burned badly with the hidden details of ORM s. ORMs are the sirens call of getting rid of all that boiler plate code when encoding and decoding objects into a db. However this abstraction breaks in many hidden ways. Lazy loading details, in-memory state vs db mismatch, cascading details, etc all have unexpected problems that can be hard to predict. Using an LLM to do the grunt work lets you easily see and reason about all the details. You don't have to guess about what's happening and you can make your own choices.

    • I find it interesting for your example you chose Moment.js -- a time library instead of something utilitarian like Lodash. For years I've following Jon Skeet's blog about implementing his time library NodaTime (a port of JodaTime). There are a crazy number of edge cases and many unintuitive things about modeling time within a computer.

      If I just wanted the equivalent of Lodash's _.intersection() method, I get it. The requirements are pretty straightforward and I can verify the LLM code & tests myself. One less dependency is great. But with time, I know I don't know enough to verify the LLM's output.

      Similar to encryption libraries, it's a common recommendation to leave time-based code to developers who live and breathe those black boxes. I trust the community verify the correctness of those concepts, something I can't do myself with LLM output.

    • LLMs also have encyclopedic knowledge. Several times LLMs have found some huge block of code I wrote and reduced it down to a few lines. The other day they removed several thousand lines of brittle code I wrote previously for some API calls with a well-tested package I didn't know about. Literally thousands down to dozens.

      My code is constantly shrinking, becoming better quality, more performant, more best-practice on a daily basis. And I'm learning like crazy. I'm constantly looking up changes it recommends to see why and what the reasons are behind them.

      It can be a big damned dummy too, though. Just today it was proposing a massive server-side script to workaround an issue with my app I was deploying, when the actual solution was to just make a simple one-line change to the app. ("You're absolutely right!")

    • For moment you an use `date-fns` and tree shake.

      I'd rather have LLMs build on top of proven, battle-tested production libraries than keep writing their own from scratch. You're going to fill up context with all of its re-invented wheels when it already knows how to use common options.

      Not to mention that testing things like this is hard. And why waste time (and context and complexity) for humans and LLMs trying to do something hard like state syncing when you can focus on something else?

      4 replies →

    • Right there with you.

      I'm instructing my agents to doing old school boring form POST, SSR templates, and vanilla JS / CSS.

      I previously shifted away from this to abstractions because typing all the boilerplate was tedious.

      But now that I'm not typing, the tedious but simple approach is great for the agent writing the code, and great for the the people doing code reviews.

    • > If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all.

      But this is a highly non-trivial problem. How do you even possibly manually verify that the test suite is complete and tests all possible corner cases (of which there are so many because synchronizing state is a hard problem)?

      At least React solves this problem in a non-stochastic, deterministic manner. What can be a good reason to replace something like React that works determinstically with LLM-assisted code that is generated stochastically and there's no easy way to manually verify if the implementation or the test suite is correct and complete?

      3 replies →

    • Has anyone tried the experiment that is sort of implied here? I was wondering earlier today, what it would be like to pick a simple app, pick on OS, and just tell an LLM to write that app using only machine code and native ADKs, and skip all intermediate layers?

      We seem to have created a large bureaucracy for software development, where telling a computer how to execute an app involves keeping a lot of cogs in a big complicated machine happy. But why use the automation to just roll the cogs? Why not just simplify/streamline? Does an LLM need to worry about using the latest and greatest abstractions? I have to assume this has been tried already...

    • > If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all.

      for simple stuff, sure, React was ALWAYS inefficient. Even Javascript/client-side logic is still overkill a lot of the times except for that pesky "user expectations" thing.

      for anything codebase that's long-lived and complex, combinatorics tells us how it'll near-impossible to have good+fast test coverage on all that.

      part of the reason people don't roll their own is because being able to assume that the library won't have major bugs leads to an incredible reduction in necessary test service, and generally people have found it a safe-enough assumption.

      throwing that out and trying to just cover the necessary stuff instead - because you're also throwing out your ability to quickly recognize risky changes since you aren't familiar with all the code - has a high chance of painting you into messy corners.

      "just hire a thousand low-skilled people and force them to write tests" had more problems as a hiring plan then just "people are expensive."

    • > Why do we code with React?

      ...is a loaded question, with a complex and nuanced answer. Especially when you continue:

      > it's worth paying the React complexity/page-weight tax

      All right; then why do we code in React when a smaller alternative, such as Preact, exists, which solves the same problem, but for a much lower page-weight tax?

      Why do we code in React when a mechanism to synchronize data with tiny UI fragments through signals exists, as exemplified by Solid?

      Why do people use React to code things where data doesn't even change, or changes so little that to sync it with the UI does not present any challenge whatsoever, such as blogs or landing pages?

      I don't think the question 'why do we code with React?' has a simple and satisfactory answer anymore. I am sure marketing and educational practices play a large role in it.

      7 replies →

    • If you work at a megacorp right now, you know whats happening isn't people deciding to use less libraries. It's developers being measured by their lines of code, and the more AI you use the more lines of code and 'features' you can ship.

      However, the quality of this code is fucking terrible, no one is reading what they push deeply, and these models don't have enough 'sense' to make really robust and effective test suites. Even if they did, a comprehensive test suite is not the solution to poorly designed code, it's a band aid -- and an expensive one at scale.

      Most likely we will see some disasters happening in the next few years due to this mode of software development, and only then will people understand to use these agents as tools and not replacements.

      ...Or maybe we'll get AGI and it will fix/maintain the trash going out there today.

    • I don't trust LLM enough to handle the maintenance of all the abstraction buried in react / similar library. I caught some of the LLMs taking nasty shortcuts (e.g. removing test constraints or validations in order to make the test green). Multiple times. Which completely breaks trust.

      And if I have to closely supervise every single change, I don't believe my development process will be any better. If not worse.

      Let alone new engineers who join the team and all of a sudden have to deal with a unique solution layer which doesn't exist anywhere else.

    • Huh, I've been assuming the opposite: better to use React even if you don't need it, because of its prevalence in the training data. Is it not the case that LLMs are better at standard stacks like that than custom JS?

      1 reply →

    • I'd rather use React than a bespoke solution created by an ephemeral agent, and I'd rather self-trepanate than use React

    •   > I'm now incentivized to use less abstractions.
      

      I'd argue it's a different category of abstraction

    • The problem is, what do you do _when_ it fails? Not "if", but "when".

      Can you manually wade through thousands of functions and fix the issue?

    • Nutty idea: train on ASM code. Create an LLM that compiles prompts directly to machine code.

    • > and it can maintain a test suite that shows everything works correctly

      Are you able to efficiently verify that the test suite is testing what it should be testing? (I would not count "manually reviewing all the test code" as efficient if you have a similar amount of test code to actual code.)

      Sometimes a change to the code under test means that a (perhaps unavoidably brittle) test needs to be changed. In this case, the LLM should change the test to match the behaviour of the code under test. Other times, a change to the code under test represents a bug that a failing test should catch -- in this case, the LLM should fix the code under test, and leave the test unchanged. How do you have confidence that the LLM chooses the right path in each case?

    • That's a fundamental misunderstanding

      The role of abstractions *IS* to prevent (eg "compress") the need for a test suite, because you have an easy model to understand and reason about

      2 replies →

  • Our industry wants disruption, speed, delivery! Automatic code generation does that wonderfully.

    If we wanted safety, stability, performance, and polish, the impact of LLMs would be more limited. They have a tendency to pile up code on top of code.

    I think the new tech is just accelerating an already existing problem. Most tech products are already rotting, take a look at windows or iOS.

    I wonder what will it take for a significant turning point in this mentality.

    • One possible positive outcome of all this could be sending LLMs to clean up oceans of low value tech debt. Let the humans move fast, let the machines straighten out and tidy up.

      The ROI of doing this is weak because of how long it takes an expensive human. But if you could clean it up more cheaply, the ROI strengthens considerably- and there’s a lot of it.

  • It’s wild that programmers are willing to accept less determinism.

    • It's not something that suddenly changed. "I'll generate some code" is as nondeterministic as "I'll look for a library that does it", "I'll assign John to code this feature", or "I'll outsource this code to a consulting company". Even if you write yourself, you're pretty nondeterministic in your results - you're not going to write exactly the same code to solve a problem, even if you explicitly try.

      6 replies →

    • Why would the average programmer have a problem with it?

      The average programmer is already being pushed into doing a lot of things they're unhappy about in their day jobs.

      Crappy designs, stupid products, tracking, privacy violation, security issues, slowness on customer machines, terrible tooling, crappy dependencies, horrible culture, pointless nitpicks in code reviews.

      Half of HN is gonna defend one thing above or the other because $$$.

      What's one more thing?

      1 reply →

    • It's wild that management would be willing to accept it.

      I think that for some people it is harder to reason about determinism because it is similar to correctness, and correctness can, in many scenarios be something you trade off - for example in relation to scaling and speed you will often trade off correctness.

      If you do not think clearly about the difference with determinism and other similar properties like (real-time) correctness which you might be willing to trade off, you might think that trading off determinism is just more of the same.

      Note: I'm against trading off determinism, but I am willing to think there might be a reason to trade it off, just I worry that people are not actually thinking through what it is they're trading when they do it.

      3 replies →

    • I think those that are most successful at creating maintainable code with AI are those that spend more time upfront limiting the nondeterminism aspect using design and context.

    • > It’s wild that programmers are willing to accept less determinism.

      It's wild that you think programmers is some kind of caste that makes any decisions.

    • There has always been a laissez-faire subset of programmers who thrive on living in the debugger, getting occasional dopamine hits every time they remove any footgun they previously placed.

      I cannot count the times that I've had essentially this conversation:

      "If x happens, then y, and z, it will crash here."

      "What are the odds of that happening?"

      "If you can even ask that question, the probability that it will occur at a customer site somewhere sometime approaches one."

      It's completely crazy. I've had variants on the conversation from hardware designers, too. One time, I was asked to torture a UART, since we had shipped a broken one. (I normally build stuff, but I am your go-to whitebox tester, because I hone in on things that look suspicious rather than shying away from them.) When I was asked the inevitable "Could that really happen in a customer system?" after creating a synthetic scenario where the UART and DMA together failed, my response was:

      "I don't know. You have two choices. Either fix it where the test passes, or prove that no customer could ever inadvertently recreate the test conditions."

      He fixed it, but not without a lot of grumbling.

      3 replies →

    • This gets repeated all the time, but it’s total nonsense. The output of an LLM is fixed just as the output of a human is.

  • Out of curiosity, what did you pivot to?

    It sounds crazy to say this, but I've been thinking about this myself. Not for the immediate future (eg 2026), but somewhere later.

  • My work is better than it has been for decades. Now I can finally think and experiment instead of wasting my time on coding nitty-gritty detail, impossible to abstract. Last autumn was the game changer, basically Codex and later Opus 4.5; the latter is good with any decent scaffolding.

    • I have to admit, LLMs do save a lot of typing a d associated syntax errors. If you know what you want and can spot and fix mistakes made by the LLM then they can be pretty useful. I don’t think it’s wise to use them for development if you are not knowledgeable enough in the domain and language to recognize errors or dead ends in the generated code though.

  • That's similar to what happened in Java enterprise stack: ...wrapper and ...factory classes and all-you-can-eat abstractions that hide implementation and make engineering crazy expensive while not adding much (or anything, in most cases) to product quality. Now the same is happening in work processes with agentic systems and workflows.

  • Could we all just agree to stop using the term "abstraction". It's meaningless and confusing. It's cover for a multitude of sins, because it really could mean anything at all. Don't lay all the blame on the c-suite; they are what they are, and have their own view. Don't moan about the latest egregious excess of some llm. If it works for you, use it; if it doesn't, don't. But, stop whinging.

  • > It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore.

    No profession collectively made such a decision. Programming was always very splitted into many, many subcultures, each with their own (mutually incompatible over the whole profession) ideas what makes a good program.

    So, I guess rather some programmers inside some part of a Silicon Valley echo chamber in which you also live made such a decision.

  •   > the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore.
    

    I've usually found complaints about abstraction in programming odd because frankly, all we do is abstraction. It often seems to be used to mean /I/ don't understand, therefore we should do something more complicated and with many more lines of code that's less flexible.

    But this usage? I'm fully on board. Too much abstraction is when it's incomprehensible. To who is the next question (my usual complaint is that a junior should not be that level) and I think you're right to point out that the "who" here is everyone.

    We're killing a whole side of creativity and elegance while only slightly aiding another side. There's utility to this, but also a cost.

    I think what frustrates me most about CS is that as a community we tend to go all in on something. We went all in on VR then crypto, and now AI. We should be trying new things but it more feels like we take these sides as if they're objective and anyone not hopping on the hype train is an idiots or luddite. The way the whole industry jumps to these things just feels more like FOMO than intelligent strategy. Like making a sparkling water company an "AI first" company... its like we love solutions looking for problems

  • Don't forget you are expected to deliver x10 for the same pay, "because you have the AI now".

    • The system is designed to do exactly that. This is called ‘productivity increase’ and is deflationary in large dosages. Deflation sounds good until you understand where it’s coming from.

  • > It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore.

    The ubiquitous adoption of LLMs for generating code is mostly a sign of bad abstraction or the absence of abstraction, not the excess of abstraction.

    And choosing/making the right abstraction is kind of the name of the game, right? So it's not abstraction per se that's a problem.

  • Every technical person has been complaining about this for the entire history of computer programming

    Unless you’re writing literal memory instructions then you’re operating on between 4 and 10 levels of abstraction already as an engineer

    It has never been tractable for humans to program a series of switches without incredible number of abstractions

    The vast majority of programmers never understood how computers work to begin with

    • People keep making this argument, but the jump to LLM driven development is such a conceptually different thing than any previous abstraction

    • This is true, though the people that actually push the field forward do know enough about every level of abstraction to get the job done. Making something (very important) horrible just to rush to market can be a pretty big progress blocker.

      Jensen is someone I trust to understand the business side and some of those lower technical layers, so I'm not too concerned.

    • And if you're writing machine code directly, you're still relying on about ten layers of abstraction that the wizards at the chip design firms have built for you.

> OpenAI's sales and marketing expenses increased to _$2 billion_ in the first half of 2025.

Looks like AI companies spend enough on marketing budgets to create the illusion that AI makes development better.

Let's wait one more year, and perhaps everyone who didn't fall victim to these "slimming pills” for developers' brains will be glad about the choice they made.

  • Well. I was a sceptic for a long time, but a friend recently convinced me to try Claude Code and showed me around. I revived an open source project I regularly get back to, code for a bit, have to wrestle with toil and dependency updates, and loose the joy before I really get a lot done, so I stop again.

    With Claude, all it took to fix all of that drudge was a single sentence. In the last two weeks, I implemented several big features, fixed long standing issues and did migrations to new major versions of library dependencies that I wouldn’t have tackled at all on my own—I do this for fun after all, and updating Zod isn’t fun. Claude just does it for me, while I focus on high-level feature descriptions.

    I’m still validating and tweaking my workflow, but if I can keep up that pace and transfer it to other projects, I just got several times more effective.

    • This sounds to me like a lack of resource management, as tasks that junior developers might perform don't match your skills, and are thus boring.

      As a creator of an open-source platform myself, I find trusting a semi-random word generator in front of users unreliable.

      Moreover, I believe it creates a bad habit. I've seen developers forget how to read documentation and instead trust AI, and of course, as a result AI makes mistakes that are hard to debug or provokes security issues that are easy to overlook.

      I know this sounds like a luddite talking, but I'm still not convinced that AI in its current state can be reliable in any way. However, because of engineers like you, AI is learning to make better choices, and that might change in the future.

      2 replies →

  • Let's wait one more year, and perhaps everyone who didn't fall victim to these "slimming pills” for developers' brains will be glad about the choice they made.

    In that year, AI will get better. Will you?

    • AI is only getting better at consuming energy and wasting people's time communicating with this T9. However, if talented engineers continue to use it, it might eventually provide more accurate replies as a result.

      Answering your question, no matter how much I personally degrade or improve, I will not be able to produce anything even remotely comparable in terms of negative impact that AI brings to humanity these days.

      6 replies →

> There's a new programmable layer of abstraction to master (in addition to the usual layers below) involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and ...

This sounds unbearable. It doesn't sound like software development, it sounds like spending a thousand hours tinkering with your vim config. It reminds me of the insane patchwork of sprawl you often get in DevOps - but now brought to your local machine.

I honestly don't see the upside, or how it's supposed to make any programmer worth their weight in salt 10x better.

  • > This sounds unbearable.

    I can't see the original post because my browser settings break Twitter (I also haven't liked much of Karpathy's output), but I agree. I call this style of software development 'meeting-based programming,' because that seems to be the mental model that the designers of the tools are pursuing. This probably explains, in part, why c-suite/MBA types are so excited about the tools: meetings are how they think and work.

    In a way LLMs/chatbots and 'agents' are just the latest phase of a trend that the internet has been encouraging for decades: the elimination of mental privacy. I don't mean 'privacy' in an everyday sense -- i.e. things I keep to myself and don't share. I mean 'privacy' in a more basic sense: private experience -- sitting by oneself; having a mental space that doesn't include anybody else; simply spending time with one's own thoughts.

    The internet encourages us to direct our thoughts and questions outward: look things up; find out what others have said; go to wikipedia; etc. This is, I think, horribly corrosive to the very essence of being a thinking, sentient being. It's also unsurprising, I guess. Humans are social animals. We're going to find ourselves easily seduced by anything that lets us replace private experience with social experience. I suppose it was only a matter of time until someone did this with programming tools, too.

  • > ... or how it's supposed to make any programmer worth their weight in salt 10x better.

    It doesn't. The only people I've seen claim such speedups are either not generally fluent in programming or stand to benefit financially from reinforcing this meme.

    • The speedup from AI is in the exponent.

      Just the other day ChatGPT implemented something that would have taken me a week of research to figure out: in 10 minutes. What do you call that speedup? It's a lot more than 10x.

      On other days I barely touch AI because I can write easy code faster than I can write prompts for easy code, though the autocomplete definitely helps me type faster.

      The "10x" is just a placeholder for averaging over a series of stochastic exponents. It's a way of saying "somewhere between 1 and infinity"

      1 reply →

    • For every conspicuous vibecoding influencer there are a bunch of experienced software engineers using them to get things done. The newest generation of models are actually pretty decent at following instructions and using existing code as a template. Building line-of-business apps is much quicker with Claude Code because once you've nicely scaffolded everything you can just tell it to build stuff and it'll do so the same way you would have in a fraction of the time. You can also use it to research alternatives to architectural approaches and tooling that you come up with so that you don't paint yourself into a corner by having not heard about some semi-niche tool that fits your use case perfectly.

      Of course I wouldn't use an LLM to #yolo some Next.js monstrosity with a flavor-of-the-week ORM and random Tailwind. I have, however, had it build numerous parts of my apps after telling it all about the mise targets and tests and architecture of the code that I came up with up front. In a way it vindicates my approach to software engineering because it's able to use the tools available to it to (reasonably) ensure correctness before it says it's done.

    • I am a professional engineer with around 10 years of experience and I use AI to work about 5x faster on a site I personally maintain (~100 DAU, so not huge, but also not nothing). I don’t work in AI so I get no financial benefit by “reinforcing this meme”.

      6 replies →

    • Practically every post on HN that mentions AI now ends up with a thread that is "I get 100X speed-up using LLMs" vs. "It made me slower and I've never met a single person in real life who has worked faster with AI."

      I'm a half-decent developer with 40 years experience. AI regularly gives me somewhere in the range of 10-100X speed-up of development. I don't benefit from a meme, I do benefit from better code delivered faster.

      Sometimes AI is a piece of crap and I work at 0.5X for an hour flogging a dead horse. But those are rarer these days.

      1 reply →

  • As far as I can tell as a heavy coding agent user: you don’t need to know any of this and that’s a testament to how good code agent TUIs have become. All I do to be productive with a coding agent is tell it to break a problem down into tasks, store it inside beads, and then make sure each step is approved by me. I also add in a TDD requirement where it needs to build tests that fail then eventually pass.

    Everything else I’ve used has been over engineered and far less impactful. What I just said above is already what many of us do anyway.

  • > This sounds unbearable. It doesn't sound like software development, it sounds like spending a thousand hours tinkering with your vim config

    Before LLM programming, this was at least 30-50% of my time spent programming, fixing one config and build issue after another. Now I can spend way more time thinking about more interesting things.

I think it's mistaken to think in terms of 'falling behind' or 'catching up'

I've seen that these tools have different uses for different devs. I know on my current team, each of us devs works very differently to one another, and we make significant allowances to accommodate for one another's different styles. Certain tasks always go to certain devs; one dev is like a steel trap, another is the chaos explorer, another's a beginner, another has great big-picture perspective, etc. (not sure why but there's even space for myself ;)

In the same way, different devs use these powerful tools in very different ways. So don't imagine you're falling behind, because the only useful benchmark is yourself. And don't imagine you can wait for consensus: you'll still need to identify your personal relationship to the tools.

Most of all, don't be discouraged. Even if you never embrace these tools, there will remain space for your skills and your style of approaching our shared work.

Give it another 10 years and I'm sure this will all become clearer...

  • I’ve become comfortable with using LLMs as “trusted advisors.”

    I am not [yet] ready to just let an agent write a whole app or server for me, but I am increasingly letting them write a whole function for me.

    They are also great “bug finders.” I can just feed some code, describe the symptoms, and ask for an observation. I often get great suggestions, including things like finding typos and copy/pasta problems.

    I find that just this limited application has significantly increased my development velocity, and, I believe, the quality of my work.

For the longest time, the joy of creation in programming came from solving hard problems. The pursuit of a challenge meant something. Now, that pursuit seems to be short-circuited by an animated being racing ahead under a different set of incentives. I see a tsunami at the beach, and I’m not sure whether I can run fast enough.

  • I see it more like a playing a text adventure game. You give it commands and sometimes it works, and sometimes the results are unexpected.

    • Personally, I've never been interested in being a character in someone else's story.

      But now you've got me thinking. Has anyone studied whether the programmers who are more enamored of AI are also into RPGs?

  • Not to mention many companies speedrunning systems of strange and/or perverse incentives with AI adoption.

    That being said, Welch’s grape juice hasn’t put Napa valley out of business. Human taste is still the subjective filter that LLMs can only imitate, not replace.

    I view LLM assisted coding (on the sliding scale from vibe coding to fancy auto complete) similar to how Ableton and other DAW software have empowered good musicians that might not have made it otherwise due to lack of connections or money, but the music industry hasn’t collapsed completely.

    • In the music world, I would say that, rather than DAWs, LLM-assisted coding is more like LLM-assisted music creation.

      1 reply →

  • > I can run fast enough.

    Can you do some code reviews while you're running?

Does any of you bother the fact that now you have to pay money in order to do your job? I mean AI model subscriptions. Somehow it feels wrong for me to pay for tools that are trying to replace me.

  • IDEs used to be extremely expensive back in the 1990s. IDEs such as Microsoft Visual Studio and IBM's Visual age for Java were quite expensive subscription as I recall. subsequently, open source IDEs like Eclipse and VisualStudio seem to have become the norm.

    • Visual Studio has never been open source, though some of the underlying build tools and compilers are.

      Visual Studio Code is a different thing... and claims to be open source, but by intent and approach really is closer to source available.

    • I used to pay a fortune for a full Visual Studio + full MSDN experience every year until I eventually earned a free ride.

      Wild how much you can get for free now. Amazing free IDEs. Every LLM offers excellent free plans if you are on a zero budget.

      $10/mo GitHub Copilot is an absurd deal that has to be a loss in terms of pure compute cost.

    • Compilers and programming languages themselves used to be hideously expensive as well.

  • I'm not paying for an AI subscription to do my job in the same way I don't pay for the IDE I use. My employer does.

My company takes between Christmas and New Years off. I took a week before that off too. I have not used AI in that time. The slower pace of life is amazing. But when I get back to coding it will be back to running at 180%. It’s the new norm. However I’ve decided to take longer “no computer” breaks in my day. I have to adapt but I need to defend my “take it slow” times and find some analogue hobbies. The shift is real and you can’t wind it back.

  • I’ve been taking my son for stroller walks more often over Christmas. I bring a headset for listening to music, podcasts, audiobooks, tech talks. “Be effective.” But I end up just walking and thinking, realising this is “free time”.

    It sounds ridiculous and easy to say spending time walking and thinking will improve your decisions and priorities that no productivity hack will.

    I only actually did slow down for a while because I had to for the well-being of my family. Sure feels important to not always be on top of everyone else’s business.

Most of the folks that are talking about this are the ones who work independently and work on greenfield projects (especially tooling related). The cost of making a mistake there is so low. I've used it similarly and it's absolutely amazing. Though I still use a mix of agents and code myself in my regular 9-5 job.

I've yet to see examples of folks using this in a team of 4+ folks working together in a production env with users, and just using AI for their regular development.

Claude code creator only using claude code doesn't count. That's more like dog-fooding.

Oh. This is a pretty stereotypical character among data scientists. This character thinks software development is all about generating text, and because they know how to generate text, they're automatically considered an expert. But they know nothing about the software lifecycle. Working with them is a real pain, especially when they shift responsibility for their "software" to your engineers.

For the folks who have more positive outlooks how often do you change your code after it's been generated?

I haven't used agents much for coding, but I noticed that when I do have something created with the slightest complexity, it's never perfect and I have to go back and change it. This is mostly fine, but when large chunks of code are created, I don't have much context for editing things manually.

It's like waking up in a new house that you've never seen before. Sure I recognize the type of rooms, the furniture, the outlets, appliances, plumbing, and so on when I see them; but my sense of orientation is strained.

This is my main issue at the moment.

  • > For the folks who have more positive outlooks how often do you change your code after it's been generated?

    Every time, unless my initial request was perfectly outlined in unambiguous pseudocode. It's just too easy to write ambiguous requests.

    Unambiguous but human-readable pseudocode is what I strive for now, though I will often ask AI to help edit the pseudocode to remove ambiguities prior to generating code.

> strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering

Sounds fever dreamish. Thank you sincerely (not) for creating it!

And there it is again, the "powerful alien tool" that was just "handed to us".

No decades of research and massive allocation of resources over the last few years as well as very intentional decision making by tech leadership to develop this specific technology.

Nope, it just mysteriously dropped from the sky one day.

> Clearly some powerful alien tool was handed around except it comes with no manual

Using tools before their manual exists is the oldest human trick, not the newest.

Anything sufficiently useful will be productized and packaged up by somebody out there so that the masses can use it, the rest will be niche and only relevant for the most hardcore enthusiasts, so I’m not so worried.

Over 20 years professional experience here. LLM tools feel great. A single person can now accomplish what used to require many teams.

  • Over 30 years code artisan here. AI has made me 100x more productive. No, I will not provide proof. Sam Altman is the best.

  • Over 80 years professional experience here. LLM tools feel great. A single person can now do the work of ten Google and Meta's in a single afternoon.

Is there anything substantial in his list ("agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations") that Claude Code or Cursor don't already incorporate?

I empathize with his sense that if we could just provide the right context and development harness to an AI model, we could be *that* much more productive, but it might just be misplaced hope. Claude Code and Cursor are probably not that far from the current frontier for LLM development environments.

Behind who?

Is there someone already mastering “agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering” ?

And do they have a blog?

  • > Behind who[m]?

    Why, the other rats in front of you in the race, of course!

    As the pithy, if cheese expression goes, read not the times; read the eternities. People who spend so much time frantically chasing superficial ephemera like this are people without any sense of life's purpose. They're cogs in some hellish consumerist machine.

I may be extremely ignorant here but I think Karpathy is primary and foremost a great pitcher - salesman, not only for AI in general but on his personal branding as well.

He is also great at explaining AI related concepts to the masses.

However his takes on software engineering show someone that hasn’t spend a significant amount of time doing production grade software engineering, and that is perfectly fine and completely normal given his background.

But that also means that we should not take his software engineering opinions as gospel.

Yeah the author of this tweet is

> Building @EurekaLabsAI. Previously Director of AI @ Tesla, founding team @ OpenAI

I used to hold Karpathy in high esteem. But the stream of posts coming from him since LLMs took over the "AI" word makes me wonder if he has lost the spark

Andrej is 39 years old, according to Wikipedia.

Douglas Adams on age and relating to technology:

"1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you’re thirty-five is against the natural order of things."

From 'The Salmon of Doubt' (2002)

  • Is that really what he's saying here?

    He's not against the technology, I think he's just feeling like there's a lot of potential that he's not quite grasping yet.

    • This guy is one of the top names in AI. This is pure propaganda written to instill "fear of missing out" and encouraging people to buy into his platform, lest they become "obsolete."

      9 replies →

    • > Is that really what he's saying here?

      No it’s absolutely not. But I thought it’d be fun to offer Adams’ brilliant hyperbole for an affectionate ribbing of Karpathy. Both of them are great communicators of ideas.

  • This is pretty much the thinking across all German-speaking countries. It especially applies to anything related to energy (combustion engines, coal, gas, oil) and IT.

    Case in point: fax machines are still an important part of business communication in Germany, and many IT projects are genuinely amateurish garbage — because the underlying mindset is "everything should stay exactly as it is."

    This is particularly visible in the 45+ generation. It mostly doesn't apply to programmers, since they tend to find new things interesting. But in the rest of society, the effects are painful to watch: if nothing changes, nothing improves.

    And then there's mobile infrastructure. It's not even a technical problem — it's purely political. The networks simply don't get expanded. It's honestly embarrassing how far behind Germany is compared to the rest of Europe.

    • Spain the same with Java, and that language it's full of bureaucratic bullshit to make mid managers feel better. Ditto with Power Points and the like. They need to dissapear for the good.

      Something lke the PDF's produced from sent(1) under Unix or MagicPont presentations are many times less fancier and they allow to produce effective no-bullshit ACTUAL product based presentations. But then half of the commercials and managers would actually useless (as they are) and they would be kicked out fast. And don't let me start on nepotism...

  • You didn't really read what he wrote or think about it and just took it as an opportunity to dismiss him as old. He was just being humble. It's relatively new to everyone. At least you are honest about your ageism.

    I am sure Karparthy can and does everage AI as well or better than you. Probably I do also and I am 48.

He should join the Ardour project. Or go to work for Ableton or Bitwig or Presonus or Digidesign or MOTU or any other DAW manufacturer. Or any video or image editing application. Or get involved with more or less any complex, "creative" native desktop application.

All of the stuff he feels he is falling behind on? Almost completely irrelevant in our domain.

I have never felt this much ahead as a programmer. So many developers I see, including at my workplace, are blindly prompting models hoping to solve their problem and failing every step of the way. The people who truly understand what is happening are still in the ruling class, and their skills are not going to be irrelevant anytime soon.

  • Yep when all this blows over, those who were least exposed to LLMs will be the winners. Patience is important and not to be drowned out by the noise.

  • 100% - I cant believe there are smart people in this conversation that dont see this.

    If you dont understand AWS you can't vibe code a terraform codebase that creates a complex infrastructure .. etc

I'm actually having more fun than I've had in years with this, since I've mainly focussed on my personal projects while getting the hang of what's achievable. And it turns out to be quite a lot if you're a creative thinker.

At first it kind of depressed me, but now I realised that actually writing code is only part of my day job, the rest is integrating infrastructure and managing people and enabling them to do their job as well, and if I can do the coding/integration part faster and give them better tools more quickly, that's a huge win.

This means I can spend more time at the beach and on my physical and mental well being as well. I was stubborn and skeptical a year ago, but now I'm just really enjoying the process of learning new things.

Definitely don't hang out on Hacker News then. It's absolutely the worst place for imposter syndrome or people with any kind of skill inferiority anxiety or confidence issue. Half the reason I read HN is because the anxiety it induces is moderately constructive in motivating me to ensure I keep learning and stay up to date. But I definitely come away every day with a distinct impression I'm below baseline in skill and knowledge for my field, even though within my own circles I'm considered expert by all my peers.

  • Really? It’s the opposite for me. The number of people being confident about things they have no clue about just makes me more arrogant.

"Guy who builds AI for a living is telling people to believe that AI is the single best thing invented since butter" how surprising

Yes-ish. It's worth keeping up with the rising tide of model capabilities, but it's not worth stressing over eliciting every last drop. Many of the specific techniques that add value today will be wasted effort with smarter models in a month or two.

Idk why people take everything that Karpathy says as canon. I find his takes post inventing the "vibe coding" term deeply unserious and vapid

  • Yeah I don’t get it, there are certain people where even just their tweets are front page headlines on HN

I’m convinced much of this is all noise - people seem to be focusing on the wrong unit of analysis. Producing software and lots of it has never been a problem - coming up with the right projects and producing a vertically differentiated product to what already exists is.

  • That's true. The noise is being generated by people who are directly or indirectly incentivized to talk about it.

    > coming up with the right projects and producing a vertically differentiated product to what already exists is.

    Agreed but not all engineers are involved with this aspect of the business and the concern applies to them.

The thing that always trips me up is the lack of isolation/sandboxing that all of the AI programming tools provide. I want to orchestrate a workforce of agents, but they can't be trusted not to run amok.

Does anyone have a better way to do this other than spinning up a cloud VM to run goose or claude or whatever poorly isolated agent tool?

  • I have seen Claude disable its sandbox. Here is the most recent example from a couple of weeks ago while debugging Rust: "The panic is due to sandbox restrictions, not code errors. Let me try again with the sandbox disabled:"

    I have since added a sandbox around my ~/dev/ folder using sandbox-exec in macOS. It is a pain to configure properly but at least I know where sandbox is controlled.

  • I'm working on a solution [0] for this. My current approach is:

    1. Create a new Git worktree

    2. Create a Docker container w/ bind mount

    3. Provide an interface for easily switching between your active worktrees/containers.

    For credentials, I have an HTTP/HTTPS mitm [1] that runs on the host with creds, so there are zero secrets in the container.

    The end goal is to be able to manage, say, 5-10 Claude instances at a time. I want something like Claude Code for Web, but self-hosted.

    [0]: https://github.com/shepherdjerred/monorepo/tree/main/package...

    [1]: https://github.com/shepherdjerred/monorepo/pull/156

  • If they cannot be trusted, why would you use them in the first place?

    • Obviously people perceive value there, but on the surface it does seem odd.

      "These things are more destructive than your average toddler, so you need to have a fence in place kind of like that one in Jurassic Park, except you need to make sure it absolutely positively cannot be shut off, but all this effort is worthwhile, because, kind of like civets, some of the artifacts they shit out while they are running amok appear to have some value."

      2 replies →

I don't have a lot of patience for this sort of take because my north star is project management and in my normal moving forward model I work in milestones where I stack up my tools and get something specific done and screwing around with tools is heavily timeboxed. If A.I. tools help me make progress great, if they don't, I will fall back to manual methods, get that phase of work done or (rarely) give up on the subproject. After I get some distance from it I can consolidate my learnings, try a different approach.

It's death though to be excessively reading tweets and blogs about this stuff, this will have you exhausted before you even try a real project and comparing yourself to other people's claims which are sometimes lies, often delusional, ungrounded and almost always self-serving. In sofar someone is getting things done with any consistency they are practicing basic PM, treating feelings of exhaustion, ungroundedness and especially going in circles as a sign to regroup, slow down and focus on the end you have in mind.

If the point really is to research tools than what you do is break down that work into attainable chunks, the way you break down any other kind of work.

I feel that way, too.

"Vibe programming" is less than a year old. What is programming going to look like in a few years?

> Roll up your sleeves to not fall behind

This confirms AI bubble for me and it now being entirely FUD driven. "Not fall behind" should only apply to technologies where you have to put active effort to learn as it requires years to hone and master the craft. AI is supposed to remove this "active effort" part so as to get you upto speed with the latest and bridge the gap between those "who know" and those "who do not". The fact you need to say "roll up your sleeves to not fall behind" confirms we are not in that situation yet.

In other words, it is the same old learning curve that everyone has to cross EXCEPT this time it is probabilistic instead of linear/exponential. It is quite literally a slightly better than coin toss situation when it comes to you learning the right way or not.

For me personally, we are truly in that zone of zero active effort and total replacement when AI can hit a 100% on ALL METRICS consistently, every single time, even on fresh datasets with challenging questions NOT SEEN/TRAINED by the model. Even better if it can come up with novel discoveries to remove any doubts. Chances of achieving that with current tech is 0%.

I love that Agile and Scrum is still unmentioned. Can we stick a fork in it yet?

  • No, no, no.

    We need to have a scrum with 3 agents each from the top 4 AI vendors, with each agent adhering to instructions given by a different programmer.

    It's kind of like Robot Wars, except the damage is less physical and more costly.

Being a nondeterministic tool, the output for a given input can vary. Rather than having a solid plan of, "if I provide this input, then that will happen", it's more like, "if I do something like this, I can expect something like that, probably, and if not, then try again until it works, I suppose".

What are the productivity gains? Obviously, it must vary. The quality of the tool output varies based on numerous criteria, including what programming language is being used and what problem is trying to be solved. The fact that person A gets a 10x productivity increase on their project does not mean that person B will also get a 10x productivity increase on their project, no matter how well they use the tool.

But again, tool usage itself is variable. Person A themselves might get a 10x boost one time, and 8x another time, and 4x another time, and 2x another time.

  • Non determinism does not imply non correctness. You can have the LLM do 10 different outputs, but maybe all 10 are valid solutions. Some might be more optimal in certain situations, and some might appeal to different people aesthetically.

    • Nondeterminism indeed does not imply non-correctness.

      All ten outputs might be valid. All ten will almost certainly be different -- though even that is not guaranteed.

      The OP referred to the notion of there being no manual; we have to figure out how to use the tool ourselves.

      A traditional programming tool manual would explain that you can provide input X and expect output Y. Do this, and that will happen. It is not so clear-cut with AI tools, because they are -- by default, in popular configurations -- nondeterministic.

      4 replies →

  • Non determinism of AI feels like a compiler which will on same input code spit out different executable on every run. Fixing bugs will become more like a ritual to satisfy whims of the machine spirit.

    • But how different? Compilers do, in fact, spit out different binaries with each run. There are timestamps and other subtle details embedded in them (esp compiler version and linking) that make the same source result in a different binary. "That's different"; "that's not the same thing!" I see you thinking. As long as the AI prompt "make me a login screen" results in a login screen appropriate for the rest of the code, and not "rm -rf ~/", does it matter if the indeterminism produces a login page with a Google login page before the email login button or after?

  • Also interesting is the possibility that a 10x boost for person A might still be slower than person B not using AI.

I wish I got out more. I used to go a lot to meetups and sit next to people 'closer to the hype' showing me the cutting edge stuff; often it was just a 'meh' experience vs the 'this is like seeing god' type of comments on hn/reddit and sometimes it is an eye opener (rarely). The 'meh' is usually when people claim it is 10000x more productive: I sit next to them and seeing them struggle to get even the basics done; after that, they struggle with the same issues I do when I try it while they are the 'experts' and I learn that people call things productive when they are kept 'busy' not actually producing results faster.

Anyway:

> agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations,

give me extreme Emacs 'setup' feelings: I was at a meetup in hk recently where there was someone advocating this and it was just depressing; spending hours on stuff that changes daily while just my vanilla claude code with playwright mcp runs circles around it, even after it has been set up. It is just not better at all and until someone can show that it is actually an improvement WITH the caveat that when it is an improvement on t(1), it doesn't need a complete overhaul at t(n) where n is a few days or weeks just because the hype machine says so. This measured against a vanilla CC without any added tooling except maybe playwright mcp.

People just want to scam themselves in feeling useful: if the ai does the work, then you find some way of feeling busy by adding and finetuning stuff to feel useful.

This is from the man who has no finished open source projects and who recommended camera-only FSD to Tesla, which he also did not finish.

The actually productive programmers, who wrote the stack that powers the economy before and after 2023 need not listen to these cheap commercials.

  • > FSD to Tesla, which he also did not finish.

    That's why I've never understood HN's continuing infatuation with him. He failed to deliver FSD to Tesla, and arguably even sent them down a R&D dead end, and he doesn't seem to have played a significant role in the generative AI revolution, only joining OpenAI after they developed ChatGPT. Yet when his talks or blog posts get posted here, they're met with almost uniformly positive comments, often many.

    He reminds me of Sam Altman, where for a while, pointing out that pg's emperor was naked, that his first big "success" was a startup, Loopt, that devolved into a seedy, gaunt gay hookup app, slowly wasting away, that only got acquired thanks to face-saving VC string-pulling, and that that "success" was the springboard of all that followed (YC presidency, feeling out a gubernatorial campaign, OpenAI CEO)--that would get you swiftly flagged.

  • > This is from the man who has no finished open source projects

    To be fair, which open source project can really claim that it is "finished", and what does "finished" even mean?

    The only projects that I can truly call "finished" are those that I have laid to rest because they have been superseded by newer technologies, not because they have achieved completeness, because there is always more to do.

  • who recommended camera-only FSD to Tesla

    That's a bummer if true. Is there a reliable source that lays that decision at Karpathy's feet?

I for one am not using AI, will not touch that steaming pile of manure with a 10 yard stick, and I couldn't care less about the so called magnitude 9 earthquake. When this bubble finally bursts into nothingness, I'll be still here practicing my craft and providing real value for my clients.

  • I'm using it less and less now, since the sheen has worn off and I've been able to more accurately judge its capabilities. It's like an intern at everything it does and unfortunately I'm expected to produce better code than that.

    • I'm very confused, are you or are you not an LLM run account?

      A couple weeks ago, under a freshly made account "llmslave", you said it's already replacing devs and the field is cooked, and anyone who doesn't see that lacks the skills to adopt AI [1]

      I pointed out that given your name and low quality comments, you were likely an LLM run account. As SOON as I made that comment, you abandoned the account and have now made a duplicate llmslave2 account, with a different opinion

      Are you doing an experiment or something?

      [1] https://news.ycombinator.com/item?id=46291504#46292968

      2 replies →

i do use LLMs a lot for programming recently. i do not use „agents“ or any other new stuff. while i have always felt behind, i do not feel more behind now, not using agents, mcp etc.

maybe i am too ignorant and don‘t see what i am missing. and i am still writing code and enjoying it.

just the terminology of agents, vibe coding, prompt engineering etc is weirdly offputting to me.

Wow - can we coin "Slopbrain" for people who are so far gone into AI eventualism that they can no longer function? Liked "cooked" but "slopped" or something. Good grief lol. Talk about getting lost in the sauce...

  • WSJ has been writing increasingly about "AI Psychosis" (here's their most recent piece [0]).

    I'm increasingly seeing that this is the real threat of AI. I've personally known people who have started to strain relationships with friends and family because they sincerely believe they are evolving into something new. While not as dramatic, the normalization of the use of "AI as therapist" is equally concerning. I know tons of people that rely on LLMs to guide them in difficult family decisions, career decisions, etc on an almost daily basis. If I'm honest, I myself have had times where I've leaned into this too much. I've also had times where AI starts telling me how clever I am, but thankfully a lifetime of low self worth signals warning flags in my brain when I hear this stuff! For most people, there is real temptation to buy into the praise.

    Seeing Karpathy claim he can't keep up was shocking. It also immediately raises the question to anyone with a clear head: "Wait, if even Karpathy cannot use these tools effectively... just what is so useful about AI?" Isn't the entire point of AI that I can merely describe my problem and have a solution in a fraction of the time.

    The fact that so many true believers in AI seem to forever be just a few more tricks away from really unleashing this power, starts to make it feel very much like magical thinking on a huge scale.

    The real danger of AI is that we're entering into an era of mass hallucination across multiple fields and areas of human activity.

    0. https://www.wsj.com/tech/ai/ai-chatbot-psychosis-link-1abf9d...

    • > I've personally known people who have started to strain relationships with friends and family because they sincerely believe they are evolving into something new.

      Cryptoboys did it first, please recognize their innovation ty

    • That's NOT AI psychosis, which is real, and which I've seen close-up.

      AI psychosis is getting lost in the sauce and becoming too intimate with your ChatGPT instance, or believing it's something it's not.

      Skepticism, or a fear of being outside the core loop is the exact opposite, and that's what Karpathy is talking about here. If anything, this kind of post is an indicator that you're absolutely NOT in AI psychosis.

      1 reply →

  • Slopbrain is interesting because Karpathy's fallacious argumentation mirrors the glib argument of an LLM/AI, it's like cognitively recursive, one feeding the other in a self-selecting manner.

  • [flagged]

    • This is what I keep hearing. "You just need something more agentic" "if you had the context length you could've fixed that" etc etc. yeah sure. I'll believe it when I see it. For me it's parsing 3000 page manuals for relevant data. I can do it fairly competently from experience, but I see a lot of people not familiar with them struggle to extract the info they need, and AIs just cannot hold all that context in my experience

Honestly surprised at this take by him. For one, feels like exaggeration. For two, are these tools really that hard to use?

  • I'm surprised too, considering that in https://x.com/karpathy/status/1977758204139331904 he mentioned regarding his NanoChat repo

    >Good question, it's basically entirely hand-written (with tab autocomplete). I tried to use claude/codex agents a few times but they just didn't work well enough at all and net unhelpful, possibly the repo is too far off the data distribution.

    And a lot of the tooling he mentioned in OP seems like self-imposed unnecessarily complexity/churn. For the longest time you could say the same about frontend, that you're so behind if you're not adopting {tailwind, react, nodejs, angular, svelte, vue}.

    At the end of the day, for the things that an LLM does well, you can achieve roughly the same quality of results by "manually" pasting in relevant code context and asking your question. In cases where this doesn't work, I'm not convinced that wrapping it in an agentic harness will give you that much better results.

    Most bespoke agent harnesses are obsoleted by the time of the next model release anyway, the two paradigms that seem to reliably work are "manual" LLM invocation and LLM with access to CLI.

  • > are these tools really that hard to use?

    Exactly! If people have 'never felt this far behind' and the LLM's are that good. Ask the LLM to teach you.

    Like so many articles on 'prompt engineers' this (never felt this behind) take too is laughable. Programmers having learnt how to program (writing algorithms, understanding data structures, reading source code and API docs) are now completely incapable of using a text box to input prompts? Nor can they learn how to quickly enough! And it's somehow more difficult than what they have routinely been doing? LOL

  • I think the evidence is that even amongst evangelists, they all seem to have different sets of key techniques that change every few months.

> and a failure to claim the boost feels decidedly like skill issue.

And a failure to clarify the project you're currently working on and the actual results feels decidedly like a propaganda issue.

Take all the digs at my skills you want. I'd rather not be a bald faced liar.

I think this is mostly a frontend sentiment.

In the backend, we're mostly just pushing data around from one place to another. Not much changes, there's only a few ways to really do that. Your data structures change, but ultimately the work is the same. You don't even really need an LLM at all, or super complex frameworks and ORMs, etc.

Sounds to me like Karapathy is in the "valley of despair" of the Dunning-Kruger effect of AI tools.

He knows the tools, he's efficient with them and yet he just now understands how much he's unable to harness at this point that makes him feel left behind.

Looking forward to see what comes out of him climbing that slope.

If there was more substance behind the hype this might actually be true. But unless you’re in some very specific niches, it’s bollocks.

You’re not doing it wrong, the tools just aren’t all they’re cracked up to be. They are annoying good enough to get you to waste a load of time trying to get them to do what it looks like they should be able to do.

whaaaat and this is the guy who coined "vibe-coding"? I am honestly pretty shocked reading this. I must be a fool or an idiot or both because I, for one, feel like suddenly I went from being a 1x developer to a 10x developer. Maybe 10x folks like Karpathy have it the opposite way?

I think people need to chill out on this thread. LLMs are neither pure slop nor the end of the programming profession. They are immensely useful tools, particularly for tedious tasks or for quickly getting up to speed on a new API or syntax. They’re great for catching bugs too. Every now and again I’ll give an LLM a prompt and it will knock it out of the park, but that’s exceedingly rare. Most of the time, though, it just allows me to focus on the more interesting parts of my job. In short, for now at least, it is a big productivity booster, not a career ender.

Countdown to his youtube course explaining it all for beginners commences...

  • His "youtube course" already exists, and it's absolutely transformational.

    He's working on a more formal educational framework/service of some kind, which will presumably not be free, but what he's already posted is some of the most effective CS pedagogy I've ever encountered (and personally benefited from.)

If Karpathy feels behind, imaging how we, regular folks feel

  • I've worked really hard over the last year at working out how to use these things, and it has more than paid off.

    But I think if I had started learning today instead of a year ago, I'd get up to speed in more like 6 months instead of a year. A lot of stuff I learned a year ago is not really necessary anymore, but furthermore, there's just a lot more information out there about how to use these from people who have been learning it on their own.

    I just don't think people who have ignored it up until now are really that far behind.

Oh my God I’m so tired of this BS. No, you do not need all that to make a more than sustainable living as a programmer. This narrative is disgusting

If you want to chase the mob off the cliff, go ahead. Insanity and stupidity aren't sound life strategies, though. They're a sign you have lost the plot.

Man, this is giving me a cognitive dissonance compared to my experiences.

Actually, even the post itself reads like a cognitive dissonance with a dash of the usual "if it's not working for you then you are using it wrong" defence.

  • I feel exactly like Karpathy here. I have some work to do, and I know exactly what I need to do, and I'm able to explain it to AI, and the AI seems to understand me (I'm lately using Opus 4.5). I wrote down a roadmap, it should take me a few weeks of coding. It feels like with a proper workflow with AI agents, this work should be doable in one or two days. Yet, I know by now that it's not going to be nearly that fast. I'll be lucky if I finish 30% faster than if I just code the entire damn thing myself. The thing is, I am a huge AI optimist, I'm not one of the AI skeptics, not even close. Karpathy is not an AI skeptic. We just both feel this sense of possibility, and the fact that we can't make AI help us more is frustrating. That's all. There's no telling anyone else "it's on you if you can't make it work for you". I think Karpathy figured out by now, and at least I did, that the number of AI skeptics by now far outnumbers the number of AI optimists, and it has become something akin to a political conviction. It's quite futile to try and change someone's mind about whether AI is good, bad, overhyped, underused, etc. People picked their side and that's that.

    • I think you articulated perfectly why it's a bubble and why execs are so eager to push it everywhere. It's so alluring, it constantly feels like we're on the verge of something great. No wonder so many people have their brains fried by it.

      5 replies →

    • If I can reassure you, if your project is complex enough and involve heavy data manipulation, a 30% improvement using Opus/Gemini 3/codex 5.2 seems like a good result. I think on complex tasks, Opus 4.5 improves my output by around 20-25%.

      And since it's way, way less wrong than sonnet4, it might also improve my whole team velocity.

      I won't lie, AI coding has been a net negative for the 'lazy devs' on my team who don't delves into their own generated code (by 'lazy devs' here I mean the subset of devs who do the work but often don't bother to truly understand the logic behind what they used/did. They are very good coworkers, add velue and are not really lazy, but I don't see another term for that).

  • I think of it this way. If you dropped Einstein with a time machine two thousand year ago, people would think he is some crazy guy doing scribbles in the sand. No one would ever know how smart he is. The same is with people and advanced AGI like Gemini 3 Pro or Chatgpt 5.2 Pro. We are just dumber than them.

    • Why do you think the models are AGI?

      I also like to think that Einstein would be smart enough to explain things from a common point of understanding if you did drop him 2000 years in the past (assuming he also possesses the scientific knowledge humanity accrued in that 2000 year gap). So, your analogy doesn't really make a lot of sense here. I also doubt he'd be able to prove his theories with the technology of the past but that's a different matter.

      If we did have AGI models, they would be able to solve our hardest problems (assuming a generous definition of AGI) even if we didn't immediately understand exactly how they got there. We already have a lot of complex systems that most people don't fully understand but can certainly verify the quality of. The whole "too smart for people to understand that they're too smart" is just a tired trope.

    • You are certainly dumber than them if you think they are AGI. These models are smart and getting smarter, but they are not AGI.

    • You think they have “advanced AGI” and are worried about keeping up with the software industry? There would be be nothing to keep up with at that point.

      To use an analogy, it would be like spending all your time before a battle making sure your knife is sharp when your opponent has a tank.

Claude Code didn’t make me faster. It changed the calendar. What used to take me months now takes weeks. Work didn't vanished, the friction did.

Two years ago I was a human USB cable: copy, paste, pray. IDE <-> chat window, piece by piece. Now the loop is tighter. The distance is shorter.

There’s still hand-holding. Still judgment. Still cleanup. But the shift is real.

We’ve come a long way. And we’re not done.

I have been using Copilot, Cursor, then CC for a little more than a year now. I have written code with teams using these tools and I am writing mostly for myself now. My observations have been the following:

1) These tools obviously improved significantly over the past 12 months. They can churn out code that makes sense in the context of the codebase, meaning there is more grounding to the codebase they are working on as opposed to codebases they have been trained on.

2) On the surface they are pretty good at solving known problems. You are not going to make them write well-optimized renderer or an RL algorithm but they can write run-of-the-mill business logic better _and_ faster than I can-- if you optimize for both speed of production and quality.

3) Out of the box, their personality is to just solve the problem in front of them as quickly as possible and move on. This leads them to make suboptimal decisions (e.g. solving a deadlock by sleeping for 2 seconds, CC Opus 4.5 just last night). This personality can be altered with appropriate guidance. For example, a shortcut I use is to append "idiomatic" to my request-- "come up with an idiomatic solution" or "is that the most idiomatic solution we can think of." Similarly when writing tests or reviewing tests I use "intent of the function under test" which makes the model output better solution or code.

4) These models, esp. Opus 4.5 and GPT 5.2, are remarkable bug hunters. I can point at a symptom and they come away with the bug. I then ask them to explain me why the bug happens and I follow the code to see if it's true. I have not come across a bad bug, yet. They can find deadlocks and starvations, you then have to guide them to a good fix (see #3).

5) Code quality is not sufficient to create product quality, but it is often necessary to sustain it. Sustainability window is shorter nowadays. Therefore, more than ever, quality of the code matters. I can see Claude Code slowly degrading in quality every single day--and I use it every single day for many hours. As much as it pains me to say this, compared to Opencode, Amp, and Toad I can feel the "slop" in Claude Code. I would love to study the codebases of these tools overtime to measure their quality--I know it's possible for all but Claude Code.

6) I used to worry I don't have a good mental model of the software I build. Much like journaling, I think there is something to be said about the process of writing/making actually gives you a very precise mental model. However, I have been trying to let that go and use the model as a tool to query and develop the mental model post facto. It's not the same but I think it is going to be the new norm. We need tooling in this space.

7) Despite your own experiences with these tools it is imperative that they be in your toolbox. If you have abstained from them thus far, perhaps best way to get them incorporated is by starting to use them for attending to your toil.

8) You can still handcraft code. There is so much fun, beauty and pleasure it in to deny doing it. Don't expect this to be your job. This is your passion.

  • > Despite your own experiences with these tools it is imperative that they be in your toolbox.

    Why is it imperative? Whenever I read comments like this I just think the author is cynically drumming up hype because of the looming AI bubble collapse.

    • Fair question. It is "imperative" for two reasons. The first, despite having rough edges now, I find these tools be actually useful so they are here to stay. The second, I think most developers will use them and make them part of their toolchain. So, if one wants to be in parity with their peers then it stands to reason they adopt these tools as well.

      In terms of bubbles: Bubbles are economic concepts and they will burst but the underlying technology find its market. There are plenty of good open source models and open source projects like OpenCode/Toad that support them. We can use those without contributing (too much) to the bubble.

    • There's a financial AI bubble for sure - that's pretty much a mainstream opinion nowadays. But that's an entirely different thing from AI itself bubble-collapsing.

      If you truly believe AI is simply going to collapse and disappear, you are deep in some serious cope and are going to be unpleasantly surprised.

Yeah. OR. You just ignore the bullshit until the bubble burst. Then we'll see what's left and it will not be what the majority think.

  • There seems to be a lot of churn, like how js was. We can just wait and see what the react of llms ends up being.

  • The "bubble" is in the financial investment, not in the technology. AI won't disappear after the bubble bursts, just like the web didn't disappear after 2000. If anything, bursting the financial bubble will most likely encourage researchers to experiment more, trying a larger range of cheaper approaches, and do more fundamental engineering rather than just scaling.

    AI is here to stay, and the only thing that can stop it at this stage is a Butlerian jihad.

    • AI has been here long before LLM’s… also I dislike the people seemingly tying the two terms together as one.

    • I maintain, the web today is not what people though it would be in 1998. The tech has it's uses, it's just not what snake oil sellers are making it to be. And talking about Butlerian jihad is borderline snake oil selling.

      1 reply →

    • Borg logic consists of framing matters of choice as "inevitable". As long as those with power convince everyone that technological implementation is "inevitable", people will passively accept their self-serving and destructive technological mastery of the world.

      The framing allows the rest of us to get ourselves off the hook. "We didn't have a choice! It was INEVITABLE!"

      And so, we have chosen.

      2 replies →

> There's a new programmable layer of abstraction to master (in addition to the usual layers below) involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering.

Slop-oriented programming

I don't usually post something like this, but this is so fucking stupid. I'm prepared to stand by that. Let's see in a few years if I'm right.

"AI" is literally models trained to make you think it's intelligent. That's it. It's like the ultimate "algorithm" or addiction machine. It's trained to make you think it's amazing and magical and therefore you think it's amazing and magical.

  • This could apply if we looked at questions in vacuum - someone had a conversation and was judging the models based on that. But some of us just use it for work and get good results daily. "Intelligent" is irrelevant; it's "useful". It doesn't matter what feelings I have about it if it saves me 2h of typing from time to time.

    • To me, as just another kinda old (I’m 49) swe, the biggest benefit of using an LLM tool is it saves a shit ton of typing. I know what I want and I know when it’s right, just saving me from typing it all out is worth $20 bucks a month.

  • Sure, but there's no reason there can't be a correlation between us "thinking" it's intelligent and it actually being intelligent. What other proxy should we use? I can't think of a scenario where it's actually intelligent but humans don't think it is that has a good practical ending. It's at least necessary even if it isn't sufficient.

  • Recently I needed to summarize about a thousand lengthy documents, and then translate those summaries into Mandarin.

    I spent about a minute composing the prompt for this task, and then went for a cup of coffee. When I got back the task was done. I spot-checked the summaries and they were excellent.

    I thought this was amazing and magical at the time. Am I wrong? Or is it simply the AI making me think this result was amazing and magical?

    • This is an LLM's bread and butter so I would hope it does a decent job.

      You just spot checked it, so how can you be sure how accurate it is. Was it 80% accurate? 90%? 99%? And how does the domain influence the accuracy requirements?

  • It’s trained to (lossy) compress large amounts of data. The system prompts have leaked and it’s just instructed to be helpful, right? I don’t entirely disagree with your sentiment, though. It’s brute force.

  • The system prompt may vary but:

    "It's trained to make you think it's amazing and magical and therefore you think it's amazing and magical."

    is the dark pattern underlying the entire LLM hype cycle IMO.

  • Congratulations on that one!

    Now that you have unlocked this secret, you're cursed forever. They look at the machine and say: hey, look, the machine is just like me! You're left confused for the best part of 3 years and then you start realizing it was true all along...they are..very much similar to the machine. For a moment we were not surprised by how capable the machine was at reasoning. And then it dawned on us, the machine had human level intelligence and cognition from the beginning, just from a slightly different perspective.

"I've never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse and between. I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year and a failure to claim the boost feels decidedly like skill issue. There's a new programmable layer of abstraction to master (in addition to the usual layers below) involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering. Clearly some powerful alien tool was handed around except it comes with no manual and everyone has to figure out how to hold it and operate it, while the resulting magnitude 9 earthquake is rocking the profession. Roll up your sleeves to not fall behind."

[flagged]

  • Its clear from listening to podcasts/interviews, he does not want to say anything to get on elons bad side. Interviewers appear to also not be eager to broach the subject.

    • If indeed he doesn't have the heart for basic honesty then why should anyone listen to him about anything?

      This is not a high bar. This is not some impossible moral standard to be held to.

      This really is an easy one.

      5 replies →

I have been telling everybody I know over the Christmas break that I have been coding from around 10-36 years of age, as a career and always in my spare time as a hobby. I have a lacklustre computer science knowledge and never worked at the scale of FANG etc but am still rather confident in my understanding of code and the tech scene in general. I've been telling people I haven't "coded" for almost 6 months now, I only interface with agentic setups and only open my IDE to make copy and config changes.

I understand we are all in different camps for a multitude of reasons;

- The jouissance of rote coding and abstraction

- The tree of knowledge specifically in programming, and which branches and nodes we each currently sit at in our understanding

- Technical paradigms that humans may have argued about have now shifted to obvious answers for agentic harnesses (think something like TDD, I for one barely used that as a style because I've mostly worked in startups building apps and found the cost of my labour not worth it, but agentic harnesse loops absolutely excel at it)

- The geography and size of the markets we work in

- The complexity of the subject matter / domain expertise

- The cost prohibitive nature of token based programming (not everyone can afford it, and the big fish seemingly have quite the advantage going fourth)

- Agentic coding has proven it can build UI's very easily, and depending on experience, it can build a very very many things easily. it excels in having feedback loops such as linting or simple javascript errors, which are observability problems in my opinion. Once it can do full stack observability (APM, system, network), it's ability to reason and correct problems on the fly for any complex system seems overly easy from my purvue.

- At the human nature level, some individuals prefer to think in 0's and 1's, some in words, some inbetween, and so on, what type of communication do agentic setups prefer?

With some of that above intuition that is easily up for debate, I've decided to lean 100% into agentic coding, I think it will be absolutely everywhere and obviously with humans in the loop but I don't think humans will need to review the pull requests. I am personally treating it as an existential threat to my career after having seen enough of what it's capable of. (with some imagination and a bit of a gambling spirit, as us mere mortals surely can't predict the future)

With my gambit, I'm not choosing to exit the tech scene and instead optimistically investing my mental prowess into figuring out where "humans in the loop" will be positioned. Currently I'm looking into CI level tooling, the known being code quality, and all the various forms of software testing paradigms. The emerging evals in my mind will keep evolving and beyond testing our ideas of model intelligence and chat bot responses will do a lot more.

---

A more practical rant: If you are building a recommendation engine for A and B, the engine could have X amount of modules that return a score which when all combined make up the final decision between A and B. Forgive me but let's just use dating as an example. A product manager would say we need a new module to calculate relevance between A and B based off their food preferences. An agentic harness can easily code that module and create the tests for it. The product manager could ask an LLM to make a list of 1000 reasons why two people might be suitable for dating. The agent could easily go away and code and test all those modules and probably maintain technical consistency but drift from the companies philosophical business model. I am looking into building "semantic linting" for codebases, how can the agent maintain the code so it aligns with the company's business model. And if for whatever reason those 1000 modules need to be refactored, how can the agent maintain the code so it aligns with the company's business model. Essentially trying to make a feedback loop between the companies needs and the code itself. To stop the agent and the business from drifting in either directions, and allowing for automatic feedback loops for the agent to fix them. In short, I think there will be new tools invented that us human's will be mastering as to Karpathy's point.

  • interesting how can I go into building Agents? I have the kiro IDE for a project but how can I make sure what they're doing is correct? Right now i'm just vibecoding or using the more detailed requirements path but I haven't used coding Agents because I actually don't get how does the feedback loop work with them