Sounds like I'm not understanding what you're actually trying to do, because that all sounds like at most needing to hand in an external raw device handle (though I'd probably provide a patch to wgpu to do it automatically based on available extensions) and maybe a memcpy between staging buffers? (though that sounds like a pretty weird issue honestly, it has multiple discrete adapters without os mediated output redirection? Not really my area, but sounds like something is screwed up)
Maybe not the first thing you want to tackle without any render API knowledge, but a year for that still sounds absurd.
But as I said, this sort of throw away project is pretty much the ideal case for AI.
Looks like the DRM integration is already out-of-box supported by wgpu, the rest is hello world for the drm crate (maybe a bit uglier than it should be eyeballing it, but heck I dunno?)
CPU fallback is kinda painful looking, but I'd need to actually play with the hardware to figure out why it's even needed. Seems like it should be able to use HOST_COHERENT memory if it's really embedded, that sort of thing. wgpu might be getting in the way here. I also don't like the double-memory copy (out of GPU, then into DRM card) but it's probably nothing.
It's not just duplicating the shaders, by the way, it has two completely separate copies of a wgu application with their own separate render flow despite the fact that the whole point of abstracting the swapchain and image views is precisely so that display differences can be ignored by most rendering code. It's honestly the most embarrassing part of this code, and makes it look way more complicated than it actually is.
I wouldn't fire an intern for giving me this code, but I probably wouldn't hire them.
To repeat, just in case: AI is fine for this sort of thing, my problem is with the idea it would take anyone a year to learn this stuff.
See, the main issue with AI-written code (besides the fact that it's often very convoluted or just plain wrong, and that it sucks the fun out of development) is that it takes away code familiarity. If AI writes code for us, we will lose the person or group that know the code. Individuals writing code without AI have written the code to their personal style, and they know where to look for issues. Looking at a piece of vibe-code, trying to debug it, is like looking at someone else's work - foreign, unknown, and you don't know where to start. People who maintain applications will be no better at eliminating issues within it than someone who found the issue in the first place, as long as they know the language. Eventually, the only efficient option will be to ask AI to do your thinking for you again. We'll be trapped in a loop of slightly mediocre code. That's my main problem with vibe-coding.
It's a brand new code that already, from the day one looks like legacy-I-have-no-idea-hot-to-fix-it code.
I can understand why one may want to have that: to test some ideas, maybe, to do UX testing, etcā¦ but at some point you have to either throw it away and trace it carefully and rewrite it.
Could be fun to create something like that but hardly a good idea to push it on anyone and expect it to be supportedā¦ and that's exactly what will happen in 2026: these vibecoded codebases would be approaching the point where they would start falling apart and there would be mass pressure to find someone who would fix that messā¦ and, of course, the one who would be blamed wouldn't be someone who vibecoded that in the first place but the one who couldn't ājust add one more featureā to it.
That's dangerous time: people who are not using LLMs would be blamed for underperforming even if their problems would be caused by colleagues who are using LLMsā¦ only when companies would, finally, start firing āunderpeformersā only to find out themselves without anyone who may save them they wouldā¦ no, not rehire these guys they fired, they wouldn't have money for that, they would pretend everything is peachy and promise to deliver the moon or more in 2027.
Only after actual round of collapses the talk about whether that crazyness was even a good idea in the first place would first be started at the management level in companies that remain. And I wouldn't be surprised to hear that yes, it was the right thing to do and the whole thing collapses because of skyrocketing oil prices or some other such tangential reason, and not because someone tried to build not sandcastle, but multi-apartment house on a sand beach without thinking that it may need some foundation.
Not really. Modern models don't collapse as spectacularly as early ChatGPT models that would try to say something then go with āand then he will will will will willā¦ā, but they still wouldn't be able to fix any bugs in that mess without creating new bugs.
Then your only option is to throw out the whole thing, because fixing it is not economically defensible. I'm, honestly, impressed by LLMs tenacity and they ability to addā¦ kludgy solutions to the reported issues and contain the code in some kind of half-working stateā¦ most humans would cry out it's not possible to support that, but models add kludges on top of kludgesā¦ but at some point the whole thing collapses, anyway ā and by then it's too convoluted for anyone to fix.
I mean I had a colleague post a quote of Claude complaining that it would be way too painful to rebase a PR so it's going to squash first, and we recently had the infamous autonomous agent posting a Medium blog bitching about their PR getting rejected...
Seems like it might be a mistake to make them any smarter, honestly
Very hard to say. The most fascinating thing in that whole story is the fact that people were talking about āthinking machinesā for almost full century, about how they would look and act and yet, when we actually started approaching that threshold, āthinking machinesā are not just different from what books and movies taught us to expect, but, essentially, the total opposite.
Instead of emotionless yet logical Data (and bazillion other similar characters) we've got something that can emote (well mimicry it, but extremely convincingly), throw the temper tantrums, try to manipulate humans and so on ā yet absolutely incapable of doing any logical thinking, incapable of doing anything consistently and reliably. Something that was taken for granted for so many years.
And instead of replacing people who are doing complex engineering work, as expected, AI is easily replacing professions which were doing ācreative, hard to replicate for machineā work.
AI may already make some decent movies or songs (which was supposed to be hard) yet couldn't reliably fill the tax form (which may also not be too trivial, yet there are millions of people who can do that and their work is considered to be boring but not extra-complicated).
I feel quite a bit of the thread are about whether AI coding good in general, instead about whether Rust is better for AI than other languages. And for that, I do think Rust's quite better than other system languages (esp C or C++), mainly for better compiler error messages and stronger static guarantees.
While I believe the current approach to AI (transformer based LLM) is wrong, I also believe there will be highly capable AI in foreseeable future. And in that future, I think Rust is a good AI language.
i am learning AI and rust, for AI to do anything besides chat you need a tool box software, wrapped with a json descriptor. that wrapper allows the AI to invoke the tools in its tool box. rust and C are common for these tools. AI may never be written in rust, but the tool boxes certainly can be. you want an AI to manage a schedule, wrap its API in json and they can work together. rust is good target for that calendar
I feel quite a bit of the thread are about whether AI coding good in general, instead about whether Rust is better for AI than other languages. And for that, I do think Rust's quite better than other system languages (esp C or C++), mainly for better compiler error messages and stronger static guarantees.