There's no practical point to this. System calls and hardware interactions are deterministic. We don't need a probabilistic model to efficiently handle interrupts or write blocks to disk. Ai is great for the user interface layer, but at the kernel level, hardcoded C or Rust will always be faster and more reliable
The only viable scenario for that kind of ji approach would be a profiler that analyzes load patterns and recompiles kernel modules with optimal compiler flags for a specific use case. Dynamically generating kernel code from scratch would kill the system with compilation and ast verification overhead
Rather than “the book explains how bread is made” say “the sheets of paper which make up the book have ink in the shape of letterforms which correlate with information about how bread is made”.
I’m going to give this URL to Claude, ask it to propose uses of state charts in my codebase. Yes, it already has this in its training data, but I find giving it a URL brings it to top of mind.
There's certainly a risk that an individual will rely too much on AI, to the detriment of their ability to understand things. However, I think there are obvious counter-measures. For example, requiring that the student can explain every single intermediate step and every single figure in detail.
A two-hour thesis defense isn't enough to uncover this, but a 40-hour deep probing examination by an AI might be. And the thesis committee gets a "highlight reel" of all the places the student fell short.
The general pattern is: "Suppose we change nothing but add extensive use of AI, look how everything falls apart." When in reality, science and education are complex adaptive systems that will change as much as needed to absorb the impact of AI.
This sounds good, but I wonder if AI has changed the calculus on conflict resolution. It can not only chase down the conflicting changes, but also read those commit messages and PRs to divine intent. It might be that git is "good enough," given we have AI.
I have mixed feelings about the "Do X in N lines of code" genre. I applaud people taking the time to boil something down to its very essence, and implement just that, but I feel like the tone is always, "and the full thing is lame because it's so big," which seems off to me.
I do prototyping for a living and ... I definitely do "X in 1/100th lines of code" regularly.
It's exciting, liberating... but it's a lie. What I do is to get the CORE of the idea so that I fully understand it. It's really nice because I get a LOT of millage very quickly... but it's also brittle, very brittle.
My experience is that most projects are 100x bigger than the idea they embody because the "real World" is damn messy. There are always radically more edge cases than the main idea enables. At some point you have to draw a line but the furthest away you draw the line, the more code you need to do it.
So... you are right to have mixed feeling, the tiny version is only valuable to get the point but it's not something one can actually use in production.
SO was built to disrupt the marriage of Google and Experts Exchange. EE was using dark patterns to sucker unsuspecting users into paying for access to a crappy Q&A service. SO wildly succeeded, but almost 20 years later the world is very different.
This is food for thought, but horses were a commodity; people are very much not interchangeable with each other. The BLS tracks ~1,000 different occupations. Each will fall to AI at a slightly different rate, and within each, there will be variations as well. But this doesn't mean it won't still subjectively happen "fast".
Whether people are interchangeable with each other isn't the point. The point is whether AI is interchangeable with jobs currently done by humans. Unless and until AI training requires 1000 different domain experts, the current projection is that at some point AI will be interchangeable with all kinds of humans...
reply