Live data from Hacker News

Andrej Karpathy: Software in the era of AI [video]

youtube.com

281–290 of 827 posts

Re: Andrej Karpathy: Software in the era of AI [video]

#281
post #193

when I started coding at the age of 11 in machine code and assembly on the C64, the dream was to create software that creates software. Nowadays it's almost reality, almost because the devil is always in the details. When you're used to write code, writing code is relatively fast. You need this knowledge to debug issues with generated code. However you're now telling AI to fix the bugs in the generated code. I see it…

This is most definitely not toys for rich people. Now perhaps depending on your country it may be considered rich but I would comfortably say that for most of the developed world, the costs for these tools are absolutely attainable, there is a reason ChatGPT has such a large subscriber base.

Also the disconnect for me here is I think back on the cost of electronics, prices for the level of compute have generally gone down significantly over time. The c64 launched around the $5-600 price level, not adjusted for inflation. You can go and buy a Mac mini for that price today.

Re: Andrej Karpathy: Software in the era of AI [video]

#283
post #264

Earlier quoted context omitted.

> This is a toy for rich people GitHub copilot has a free tier. Google gives you thousands of free LLM API calls per day. There are other free providers too.

1st dose is free

LLM APIs are pretty darn cheap for most of the developed worlds income levels.

Re: Andrej Karpathy: Software in the era of AI [video]

#284
post #92

Earlier quoted context omitted.

I could see it being the case that driving is a fairly general problem, and this models intentionally designed to be general end up doing better than models designed with the misconception that you need a very particular set of driving-specific capabilities.

Driving is not a general problem, though. Its a contextual landscape of fast-based reactions and predictions. Both are required, and done regularly by the human element. The exact nature of every reaction, and every prediction, change vastly within the context window. You need image processing just as much as you need scenario management, and they're orthoganol to each other, as one example. If you want a general tra…

It partially is. You have the specialized part of maneuvering a fast moving vehicle in physical world, trying to keep it under control at all times and never colliding with anything. Then you have the general part, which is navigating the human environment. That's lanes and traffic signs and road works and schoolbuses, that's kids on the road and badly parked trailers.

Current breed of autonomous driving systems have problems with exceptional situations - but based on all I've read about so far, those are exactly of the kind that would benefit from a general system able to understand the situation it's in.

Re: Andrej Karpathy: Software in the era of AI [video]

#285

Tight feedback loops are the key in working productively with software. I see that in codebases up to 700k lines of code (legacy 30yo 4GL ERP systems). The best part is that AI-driven systems are fine with running even more tight loops than what a sane human would tolerate. Eg. running full linting, testing and E2E/simulation suite after any minor change. Or generating 4 versions of PR for the same task so that the h…

Here’s a few problems I foresee:

1. People get lazy when presented with four choices they had no hand in creating, and they don’t look over the four and just click one, ignoring the others. Why? Because they have ten more of these on the go at once, diminishing their overall focus.

2. Automated tests, end-to-end sim., linting, etc—tools already exist and work at scale. They should be robust and THOROUGHLY reviewed by both AI and humans ideally.

3. AI is good for code reviews and “another set of eyes” but man it makes serious mistakes sometimes.

An anecdote for (1), when ChatGPT tries to A/B test me with two answers, it’s incredibly burdensome for me to read twice virtually the same thing with minimal differences.

Code reviewing four things that do almost the same thing is more of a burden than writing the same thing once myself.

Re: Andrej Karpathy: Software in the era of AI [video]

#286

Earlier quoted context omitted.

Very advanced machine learning models are used in current self driving cars. It all depends what the model is trying to accomplish. I have a hard time seeing a generalist prompt-based generative model ever beating a model specifically designed to drive cars. The models are just designed for different, specific purposes

I could see it being the case that driving is a fairly general problem, and this models intentionally designed to be general end up doing better than models designed with the misconception that you need a very particular set of driving-specific capabilities.

Speed and Moore's law. You don't need to just make a decision without hallucinations, you need to do it fast enough for it to propagate to the power electronics and hit the gas/brake/turn the wheel/whatever. Over and over and over again on thousands of different tests.

A big problem I am noticing is that the IT culture over the last 70 years has existed in a state of "hardware gun get faster soon". And over the last ten years we had a "hardware cant get faster bc physics sorry" problem.

The way we've been making software in the 90s and 00s just isn't gonna be happening anymore. We are used to throwing more abstraction layers (C->C++->Java->vibe coding etc) at the problem and waiting for the guys in the fab to hurry up and get their hardware faster so our new abstraction layers can work.

Well, you can fire the guys in the fab all you want but no matter how much they try to yell at the nature it doesn't seem to care. They told us the embedded c++-monkeys to spread the message. Sorry, the moore's law is over, boys and girls. I think we all need to take a second to take that in and realize the significance of that.

[1] The "guys in the fab" are a fictional character and any similarity to the real world is a coincidence.

[2] No c++-monkeys were harmed in the process of making this comment.

Re: Andrej Karpathy: Software in the era of AI [video]

#288

Earlier quoted context omitted.

> That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality This is the right way to work with generative AI, and it already is an extremely common and established practice when working with image generation.

I can recognize images in one look. How about that 400 Line change that touches 7 files?

In my prompt I ask the LLM to write a short summary of how it solved the problem, run multiple instances of LLM concurrently, compare their summaries, and use the output of whichever LLM seems to have interpreted instructions the best, or arrived at the best solution.

Re: Andrej Karpathy: Software in the era of AI [video]

#290
post #254

Earlier quoted context omitted.

> Or generating 4 versions of PR for the same task so that the human could just pick the best one. That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality. Why are we doing this to ourselves and embracing it? A few years ago, it would have been seen as a joke to say “the future of software development will be to have a million monkey interns banging on one million keyboar…

> That sounds awful. A truly terrible and demotivating way to work and produce anything of real quality This is the right way to work with generative AI, and it already is an extremely common and established practice when working with image generation.

It is not. The right way to work with generative AI is to get the right answer in the first shot. But it's the AI that is not living up to this promise.

Reviewing 4 different versions of AI code is grossly unproductive. A human co-worker can submit one version of code and usually have it accepted with a single review, no other "versions" to verify. 4 versions means you're reading 75% more code than is necessary. Multiply this across every change ever made to a code base, and you're wasting a shitload of time.

Post reply on HN