It depends on the type of task and the developer's level. For typical CRUD tasks, I'd say AI is often already faster and better than an average developer. But as soon as ambiguous requirements or architectural trade-offs appear, the situation changes
Speed itself also changes the equation. If I can try out five implementation approaches in the same time I used to spend writing just one, the overall quality of the project could very well improve.
If programming were just about typing text, the profession would have disappeared already. In practice most of the work involves understanding requirements, analyzing constraints, finding trade-offs, and fixing problems before they hit production. AI is still noticeably worse at all that than it is at generating code.
At the end of the day it's just a tool. If someone enjoys building things, AI expands their capabilities rather than taking them away. Right now one developer can put together what used to require a small team. To me that sounds like an argument for learning it, not against it
Agreed. Shorting requires timing the market perfectly, but buying assets after a crash just requires having liquidity and patience. Historically, that's often been the safer play
After the dot-com bust, infrastructure assets turned out to be one of the most undervalued asset classes. Maybe in a few years people will look back on GPU clusters the same way they looked at dark fiber back then
I think a lot of people are mixing two different ideas: AI is overhyped and AI company stocks are about to crash. The first might well be true, but the second might not be. The dot-com bubble burst too, but the internet didn't go away. The question is more about who will be left standing once the era of endless capex growth ends.
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
That's the whole point of an operating system - to manage local hardware. That's its reason for existing. The moment task switching starts depending on rtt to a cloud provider's servers, it's just a thin client with delusions of grandeur. Fifty milliseconds per system call, and no amount of tflops on the backend is going to save you from that feeling of working through a proxy in 2005
If you're on macOS, take a look at Orion from the team behind Kagi Search. It runs on WebKit, is really light on battery usage, doesn't come bundled with crypto stuff or AI agents, and still supports Chrome and Firefox extensions natively
I think a lot of people aren't actually against AI itself. Personally I just want to choose when I need a chatbot and when I want a normal list of links. Over the last few years, that line has started getting pretty blurry
Your second idea is pretty much the direction the classic solution takes: walk along the curve incrementally, avoid square roots, and use symmetry to fill in the other parts
Speed itself also changes the equation. If I can try out five implementation approaches in the same time I used to spend writing just one, the overall quality of the project could very well improve.
reply