Software 3.0 is where Engineers only create the kernel or seed of an idea. Then all users are developers creating their own branch using the feedback loop of their own behavior.
Andrej Karpathy: Software in the era of AI [video]
351–360 of 827 posts
Re: Andrej Karpathy: Software in the era of AI [video]
#352It's going to be very interesting to see how things evolve in enterprise IT, especially but not exclusively in regulated industries. As more SaaS services are at least partly vibe coded, how are CIOs going to understand and mitigate risk? As more internal developers are using LLM-powered coding interfaces and become less clear on exactly how their resulting code works, how will that codebase be maintained and increme…
> how many IT leaders would accept the output code of something like a menugen app as production-viable.
probably all of the ones at microsoft
Re: Andrej Karpathy: Software in the era of AI [video]
#353He's talking about "LLM Utility companies going down and the world becoming dumber" as a sign of humanity's progress.
This if anything should be a huge red flag
Re: Andrej Karpathy: Software in the era of AI [video]
#354Tight 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…
> Tight feedback loops are the key in working productively with software. […] even more tight loops than what a sane human would tolerate.
Why would a sane human be averse to things happening instantaneously?
Re: Andrej Karpathy: Software in the era of AI [video]
#355Earlier quoted context omitted.
I can recognize images in one look. How about that 400 Line change that touches 7 files?
Exactly! This is why there has to be "write me a detailed implementation plan" step in between. Which files is it going to change, how, what are the gotchas, which tests will be affected or added etc. It is easier to review one document and point out missing bits, than chase the loose ends. Once the plan is done and good, it is usually a smooth path to the PR.
So you can create a more buggy code remixed from scraped bits from the internet which you don't understand, but somehow works rather than creating a higher quality, tighter code which takes the same amount of time to type? All the while offloading all the work to something else so your skills can atrophy at the same time?
Sounds like progress to me.
Re: Andrej Karpathy: Software in the era of AI [video]
#356Earlier quoted context omitted.
It is kind of a human problem too, although that the full testing suite takes X hours to run is also not fun, but it makes the human problem larger. Say you're Human A, working on a feature. Running the full testing suite takes 2 hours from start to finish. Every change you do to existing code needs to be confirmed to not break existing stuff with the full testing suite, so some changes it takes 2 hours before you ha…
Worked in such a codebase for about 5 years. No one really cares about improving test times. Everyone either suffers in private or gets convinced it's all normal and look at you weird when you suggest something needs to be done.
There a few of us around, but it's not a lot, agree. It really is an uphill battle trying to get development teams to design and implement test suites the same way they do with other "more important" code.
Re: Andrej Karpathy: Software in the era of AI [video]
#357Earlier 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?
> I can recognize images in one look.
> How about that 400 Line change that touches 7 files?
Karpathy discusses this discrepancy. In his estimation LLMs currently do not have a UI comparable to 1970s CLI. Today, LLMs output text and text does not leverage the human brain’s ability to ingest visually coded information, literally, at a glance.
Karpathy surmises UIs for LLMs are coming and I suspect he’s correct.
Re: Andrej Karpathy: Software in the era of AI [video]
#358Re: Andrej Karpathy: Software in the era of AI [video]
#359Earlier quoted context omitted.
I'm not sure this makes sense as a question. Registers are 'controlled' by running code for a given state. An AI can write code that changes registers, as all code does in operation. An AI can't directly 'control registers' in any other way, just as you or I can't.
I would like to make an AI agent that directly interfaces with a processor by setting bits in a processor register, thus eliminating the need for even assembly code or any kind of code. The only software you would ever need would be the AI.
This makes no sense at all. You can't set registers without assembly code. If you could set registers without assembly code then it would be pointless as the registers wouldn't be 'running' against anything.
Re: Andrej Karpathy: Software in the era of AI [video]
#360Earlier quoted context omitted.
I would like to make an AI agent that directly interfaces with a processor by setting bits in a processor register, thus eliminating the need for even assembly code or any kind of code. The only software you would ever need would be the AI.
That's called a JIT compiler. And ignoring how bad an idea blending those two... It wouldn't be that difficult a task. The hardest parts of a jit is the safety aspect. And AI already violates most of that.
It's not a JIT. A JIT produces assembly. You can't "set registers" or do anything useful without assembly code running on the processor.