Same. I only just started using agents a few months ago.

Earlier this year the ecosystem was still a mess I didn't have time to untangle. Now things are relatively streamlined and simple. Arguably stable, even.

I feel behind, sure, but I also don't think people on the bleeding edge are getting that much more utility that it's worth sinking dozens or hundreds of my very limited hours into understanding.

Besides, I'm a C programmer. I'll always be several decades behind the trend. I'm fine with that.

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 Karpathy is engaged here in more hype creation. Software engineers pretending they just smashed some particles together and there is a whole lot of new data to math out.

It's high dose copium. Please keep the good times rolling! Buy my books! Sub to my stack!

Meanwhile, with local models, local RAG, and shell scripts, I am wandering 3D immersive worlds via a GPU accelerated presentation layer I vibe coded with a single 24GB GPU. Natural language driven Unreal engines are viable outputs today given local only code gen.

Karpathy and the SV VC world thought this would be the next big thing to pump for a decade plus; like web pages and SaaS. But the world is smarter, more adept at catching up that it is just state management in a typical machine. The semantics are well known and do not need re-invention.

The hilarity at an entire industry unintentionally training their replacements.

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.

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

???

It's pretty nice that C has garnered such hate because there's apparently very little focus on getting LLMs to write good C. It's all Rust and Python and whatever this month's fad language is. LLM fans mostly leave us alone apart from the "C bad rewrite the world in rust" crew.

I'm very happy being decades behind the curve here. C's slowness is perfect for me.

You’re the real unicorn!

You'll make more money than ever cleaning up AI generated messes.

What I like to say is that writing software is getting so easy that I don't know how to do it anymore.

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

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.

Having created 100 of nano-sized projects does not add up to having developed and maintained one large code base.

Coding agents are eating up programming from the lowest end, starting from pressing button on the keyboard to type the code in: completion was literally their first application. I don't think it will go all the way to the top, though, the essential part of the profession will remain until true AGI.

Metaphorically, think how integrated chips didn't replace electrical engineering, just changed which production tools and components engineers deal with and how.

Obviously we all are adapting to changes, but if he or someone are panicking about being behind, that can only be because they've never been in too deep.

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

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

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.

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.

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.

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.

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

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?

Cursor is an IDE.

At a guess an Enterprise API account. Pay per token but no limits.

It’s very easy to spend $100s per dev per day.

Question: How many LoC do you let the AI write for each iteration? And do you review that? It sounds like you are letting it run off leash.

Just once. Just for a night.

If you have never experienced becoming once, try DMT or a large amount of acid on a quiet day.

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.

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.

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.

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

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?

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

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

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.

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?

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

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.

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!")

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

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

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

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

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'd rather use React than a bespoke solution created by an ephemeral agent, and I'd rather self-trepanate than use React

Why would I want to maintain in perpetuity random snippets when a library exists? How is that an improvement?

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

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

If LLMs are that capable, then why are AI companies selling access to them instead of using them to conquer markets?

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?

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

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

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?

  > I'm now incentivized to use less abstractions.

disruption is a code word for deregulation, and deregulation is bad for everyone except execs and investors

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

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.

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?

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.

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.

Mortgages don't pay for themselves.

You can have the best of both worlds if you use structured/constrained generation.

It's not that wild. I like building things. I like programming too, but less than building things.

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

The good ones don't accept. Sadly there's just many more idiots out there trying to make a quick buck

I mean we've had to cope with users for ages, this is not that different.

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.

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.

I'm also interested in hearing this.

For me, I'm planning to ride out this industry for another couple years building cash until I can't stand it, then pivot to driving a city bus.

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.

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.

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.

Not for me.

https://xcancel.com/karpathy/status/2004607146781278521

(FYI: you can easily bypass the awful logged out view by replacing x.com with xcancel.com, I use a URL Autoredirector rule to do it automatically in Chromium browsers)

Use a Nitter mirror [1]. I find xcancel.com the easiest to get to:

https://xcancel.com/karpathy/status/2004607146781278521

[1] https://github.com/zedeus/nitter/wiki/Instances

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.

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"

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

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.

Our ops guy has thrown together several buggy dashboards using AI tools. They're passable but impossible to maintain.

This sounds like my complete and utter nightmare. No art or finesse in building the thing - only an exercise in torturing language to someone who at a fundamental level doesn't understand a thing.

I predict by the end of next year we will have our AIs write TPS reports.

Beads?

IMO LLMs make for a great rubber duck https://en.wikipedia.org/wiki/Rubber_duck_debugging

He was "AI" director at Tesla from 2017:

https://www.teslarati.com/tesla-ai-director-hiring-autopilot...

He gave a glowing recommendation for camera-only FSD in 2021:

https://thenextweb.com/news/tesla-ai-chief-explains-self-dri...

Then he left Tesla in 2022. So yes, you could argue that it was all Elon's fault and he just followed for 5 years. We won't know with 100% certainty, I'd find it odd to stay 5 years if you think it doesn't work.

Then replace "finished" with "production software".

> not because they have achieved completeness, because there is always more to do.

this is because SWEs love bloat and any good idea eventually needs to balloon into some ever-growing monstrosity :)

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

https://github.com/left-pad

I'll bet the next 8 years of my career on it.

It’s written in the title of the post “Andrew Karpathy” he’s fairly well known in AI circles, he was head of autopilot at Tesla, and co-founded OpenAI. If you’re curious to learn more about him, the Wikipedia page has a short summary: https://en.wikipedia.org/wiki/Andrej_Karpathy

It is even worse coming from him.

Yes, and I'm disappointed he seems to have joined the AI mysticism crowd.

That refers to the sandbox "escape hatch" [1], running a command without a sandbox is a separate approval so you get another prompt even if that command has been pre-approved. Their system prompt [2] is too vague about what kinds of failures the sandbox can cause, in my experience the agent always jumps straight to disabling the sandbox if a command fails. Probably best to disable the escape hatch and deal with failures manually.

[1] https://code.claude.com/docs/en/sandboxing#configure-sandbox...

[2] https://github.com/Piebald-AI/claude-code-system-prompts/blo...

This is also what I did. Actually, Claude did it.

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

For the same reason you'd build a fire.

I guess I get both effects. Every now and then there is a post about something I'm actually expert in and the standard of the comments sometimes shocks me. It's hard to connect the two experiences.

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

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

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

I’m older than both of you.

Why pay for LLM when you can just do it easily for free?

The end goal is to get rid of all frontends anyway, just have apps that you interact with through LLM prompts. A more advanced command line.

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.

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?

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

When was the last time you used it?

Frontier AI isnt trained on frontier AI. I wish HN would collectively stop and actually think before they post.

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

Cyberpunk was right!

I would really like to hear more about these acquaintances who think they are evolving.

WSJ is Fox News Platinum, I wouldn't overthink it

A mix of "too clever by half" and "never meet your heroes".

Why do you feel that way?

You think we should appeal to authority rather than address the ideas on their own merits?

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

“We just both feel this sense of possibility, and the fact that we can't make AI help us more is frustrating”

The mirage is alluring.

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

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.

> We are just dumber than them.

you are, for sure.

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.

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?

Weird self roast but okay.

It's satire, the models are more subtle in their mannerisms.

Huh? Good eyes!! I forgot an /s at the end.

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.

If he publishes something in this space he can just TAKE MY MONEY!

how has it paid off for you?

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

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.

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.

Not even Butlerian Jihad will stop the current progress at this point.

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.