Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

291–300 of 827 posts

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

#291

Post by abdullin »

bandoti wrote: post #285
abdullin wrote: post #102

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…

A simple rule applies: "No matter what tool created the code, you are still responsible for what you merge into main".

As such, task of verification, still falls on hands of engineers.

Given that and proper processes, modern tooling works nicely with codebases ranging from 10k LOC (mixed embedded device code with golang backends and python DS/ML) to 700k LOC (legacy enterprise applications from the mainframe era)

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

#292

Post by koakuma-chan »

deadbabe wrote: post #290
koakuma-chan wrote: post #278

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.

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

> Reviewing 4 different versions of AI code is grossly unproductive.

You can have another AI do that for you. I review manually for now though (summaries, not the code, as I said in another message).

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

#293

Post by abdullin »

yahoozoo wrote: post #211
abdullin wrote: post #102

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…

The problem is that every time you run your full automation with linting and tests, you’re filling up the context window more and more. I don’t know how people using Claude do it with its <300k context window. I get the “your message will exceed the length of this chat” message so many times.

Claude's approach is currently a bit dated.

Cursor.sh agents or especially OpenAI Codex illustrate that a tool doesn't need to keep on stuffing context window with irrelevant information in order to make progress on a task.

And if really needed, engineers report that Gemini Pro 2.5 keeps on working fine within 200k-500k token context. Above that - it is better to reset the context.

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

#294

Post by abdullin »

HappMacDonald wrote: post #274
tlb wrote: post #181

Earlier quoted context omitted.

Yes, and (some near-future) AI is also more patient and better at multitasking than a reasonable human. It can make a change, submit for full fuzzing, and if there's a problem it can continue with the saved context it had when making the change. It can work on 100s of such changes in parallel, while a human trying to do this would mix up the reasons for the change with all the other changes they'd done by the time th…

You can't run N bots in parallel with testing between each attempt unless you're also running N tests in parallel. If you could run N tests in parallel, then you could probably also run the components of one test in parallel and keep it from taking 2 hours in the first place. To me this all sounds like snake oil to convince people to do something they were already doing, but by also spinning up N times as many comput…

Running tests is already an engineering problem.

In one of the systems (supply chain SaaS) we invested so much effort in having good tests in a simulated environment, that we could run full-stack tests at kHz. Roughly ~5k tests per second or so on a laptop.

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

#295

Post by tele_ski »

londons_explore wrote: post #175
OvbiousError wrote: post #160

Earlier quoted context omitted.

I don't think the human is the problem here, but the time it takes to run the full testing suite.

The full test suite is probably tens of thousands of tests. But AI will do a pretty decent job of telling you which tests are most likely to fail on a given PR. Just run those ones, then commit. Cuts your test time from hours down to seconds. Then run the full test suite only periodically and automatically bisect to find out the cause of any regressions. Dramatically cuts the compute costs of tests too, which in big…

It's an interesting idea, but reactive, and could cause big delays due to bisecting and testing on those regressions. There's the 'old' saying that the sooner the bug is found the cheaper it is to fix, seems weird to intentionally push finding side effect bugs later in the process because faster CI runs. Maybe AI will get there but it seems too aggressive right now to me. But yeah, put the automation slider where you're comfortable.

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

#296

Post by osigurdson »

latexr wrote: post #254
abdullin wrote: post #102

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…

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

I'm not sure that AI code has to be sloppy. I've had some success with hand coding some examples and then asking codex to rigorously adhere to prior conventions. This can end up with very self consistent code.

Agree though on the "pick the best PR" workflow. This is pure model training work and you should be compensated for it.

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

#297

Post by bandoti »

abdullin wrote: post #291
bandoti wrote: post #285

Earlier quoted context omitted.

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…

A simple rule applies: "No matter what tool created the code, you are still responsible for what you merge into main". As such, task of verification, still falls on hands of engineers. Given that and proper processes, modern tooling works nicely with codebases ranging from 10k LOC (mixed embedded device code with golang backends and python DS/ML) to 700k LOC (legacy enterprise applications from the mainframe era)

Agreed. I think engineers though following simple Test-Driven Development procedures can write the code, unit tests, integration tests, debug, etc for a small enough unit by default forces tight feedback loops. AI may assist in the particulars, not run the show.

I’m willing to bet, short of droid-speak or some AI output we can’t even understand, that when considering “the system as a whole”, that even with short-term gains in speed, the longevity of any product will be better with real people following current best-practices, and perhaps a modest sprinkle of AI.

Why? Because AI is trained on the results of human endeavors and can only work within that framework.

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

#298

Post by kubb »

diggan wrote: post #221
kubb wrote: post #214

Earlier quoted context omitted.

I also think they might never become reliable.

But what does that mean ? If you tell the LLM "Say just 'hi' without any extra words or explanations", do you not get "hi" back from it?

Sometimes I get "Hi!", sometimes "Hey!".

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

#299

Post by abdullin »

diggan wrote: post #224
abdullin wrote: post #206

Earlier quoted context omitted.

This is the workflow that ChatGPT Codex demonstrates nicely. Launch any number of «robotic» tasks in parallel, then go on your own. Come back later to review the results and pick good ones.

Well, they're demonstrating it somewhat , it's more of a prototype today. First tell is the low limit, I think the longest task for me been 15 minutes before it gives up. Second tell is still using a chat UI which is simple to implement, easy to implement and familiar, but also kind of lazy. There should be a better UX, especially with the new variations they just added. From the top of my head, some graph-like UX mi…

I guess, it depends on the case and the approach.

It works really nice with the following approach (distilled from experiences reported by multiple companies)

(1) Augment codebase with explanatory texts that describe individual modules, interfaces and interactions (something that is needed for the humans anyway)

(2) Provide Agent.MD that describes the approach/style/process that the AI agent must take. It should also describe how to run all tests.

(3) Break down the task into smaller features. For each feature - ask first to write a detailed implementation plan (because it is easier to review the plan than 1000 lines of changes. spread across a dozen files)

(4) Review the plan and ask to improve it, if needed. When ready - ask to draft an actual pull request

(5) The system will automatically use all available tests/linting/rules before writing the final PR. Verify and provide feedback, if some polish is needed.

(6) Launch multiple instances of "write me an implementation plan" and "Implement this plan" task, to pick the one that looks the best.

This is very similar to git-driven development of large codebases by distributed teams.

Edit: added newlines

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

#300

Post by hollowturtle »

teekert wrote: post #159
fergie wrote: post #133

There were some cool ideas- I particularly liked "psychology of AI" Overall though I really feel like he is selling the idea that we are going to have to pay large corporations to be able to write code. Which is... terrifying. Also, as a lazy developer who is always trying to make AI do my job for me, it still kind of sucks, and its not clear that it will make my life easier any time soon.

He says that now we are in the mainframe phase. We will hit the personal computing phase hopefully soon. He says llama (and DeepSeek?) are like Linux in a way, OpenAI and Claude are like Windows and MacOS. So, No, he’s actually saying it may be everywhere for cheap soon. I find the talk to be refreshingly intellectually honest and unbiased. Like the opposite of a cringey LinkedIn post on AI.

Being Linux is not a good thing imo, it took decades for tech like proton to run Windows games reliably, if not better as now, than Windows does. Software is still mostly develop for Windows and macOS. Not to mention the Linux Desktop that never took off, I mean one could mention Android but there is a large corporation behind it. Sure Linux is successfull in many ways, it's embedded everywhere but nowhere near being the OS of the everyday people, "traditional linux desktop" never took off
Post reply on HN