Live data from Hacker News

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

twitter.com

381–390 of 630 posts

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

#381

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, anothe…

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 t…

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

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

#382
post #204

Earlier quoted context omitted.

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.

Gardening and plumbing. Driving buses will be solved.

Plumbing seems like a relatively popular AI-proof pivot. If AI really does start taking jobs en masse, then plumbers are going to be plentiful and cheap.

What we really need is a lot more housing. So construction work is a safer pivot. But, construction work is difficult and dangerous and not something everyone can do. Also, society will collapse (apparently) if we ever make housing affordable, so maybe the powers-that-be wont allow an increase in construction work, even if there are plenty of construction workers.

Who knows... interesting times.

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

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

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

#384
post #208

Earlier quoted context omitted.

I'm not arguing for using LLMs as an abstraction. I'm saying that a key component of the dependency calculation has changed. It used to be that one of the most influential facts affecting your decision to add a new library was the cost of writing the subset of code that you needed yourself. If writing that code and the accompanying tests represented more than an hour of work, a library was usually a better investment…

React is hundreds of thousands of lines of code (or millions - I haven’t looked in awhile). Sure, you can start by having the LLM create a simple way to sync state across components, but in a serious project you’re going to run into edge-cases that cause the complexity of your LLM-built library to keep growing. There may come a point at which the complexity grows to such a point that the LLM itself can’t maintain the…

Not all UIs converge to a React like requirement. For a lot of use cases React is over-engineering but the profession just lacks the balls to use something simpler, like htmx for example.

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

#385
post #293
post #208

Earlier quoted context omitted.

I'm not arguing for using LLMs as an abstraction. I'm saying that a key component of the dependency calculation has changed. It used to be that one of the most influential facts affecting your decision to add a new library was the cost of writing the subset of code that you needed yourself. If writing that code and the accompanying tests represented more than an hour of work, a library was usually a better investment…

A major difference is when we have to read and understand it because of a bug. Perhaps the LLM can help us find it! But abstraction provides a mental scaffold

I feel like "abstraction" is overloaded in many conversations.

Personally I love abstraction when it means "generalize these routines to a simple and elegant version". Even if it's harder to understand than a single instance it is worth the investment and gives far better understanding of the code and what it's doing.

But there's also abstraction meaning to make less understandable or more complex and I think LLMs operate this way. It takes a long time to understand code. Not because any single line of code is harder to understand but because they need to be understood in context.

I think part of this is in people misunderstanding elegance. It doesn't mean aesthetically pleasing, but to do something in a simple and efficient way. Yes, write it rough the first round but we should also strive for elegance. It more seems like we are just trying to get the first rough draft and move onto the next thing.

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

#386
post #317
post #100

Earlier quoted context omitted.

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…

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

The same question might be asked about ASML: if ASML EUV machines are so great, why does ASML sell them to TSMC instead of fabbing chips themselves? The reality is that firms specialize in certain areas, and may lose their comparative advantage when they move outside of their specialty.

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

#387

Earlier quoted context omitted.

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

Exactly. I think some of the commenters were unaware of some of the context, and got an entirely different read on the piece.

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

#388

Earlier quoted context omitted.

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.

It's not the same, LLM's are qualitatively different due to the stochastic and non-reproducible nature of their output. From the LLM's point of view, non-functional or incorrect code is exactly the same as correct code because it doesn't understand anything that it's generating. When a human does it, you can say they did a bad or good job, but there is a thought process and actual "intelligence" and reasoning that went into the decisions.

I think this insight was really the thing that made me understand the limitations of LLMs a lot better. Some people say when it produces things that are incorrect or fabricated it is "hallucinating", but the truth is that everything it produces is a hallucination, and the fact it's sometimes correct is incidental.

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

#389
post #177

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

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 e…

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