Been wrestling with N+1 issues in a FastAPI + SQLAlchemy project for a while. Tried strawberry-graphql but it felt like overkill for what we needed. Dropped this in last week and the dataloader integration was surprisingly painless. The resolve_* convention is a bit magical at first but makes sense once it clicks. ERD-as-code is the part I didn't expect to actually like.
I work on low level Linux stuff nftables, raw sockets, kernel capabilities. AI helps me write boilerplate faster but it has no idea why PR_SET_KEEPCAPS needs to come before setuid or why my packet parser needs a specific bounds check. It just guesses and gets it wrong half the time. I think AI changes what we spend time on, not whether we're needed.
Doesn't this also depend on the expected question(prompt input) quality and how specific it is?
Which means, at the end, will there be a "new" programming language - AI based?, or will the existing programming languages, just expand their offered capabilities, though new libraries or even frameworks?
Realistically, existing languages will just grow better AI-assisted tooling around them. A clean break to some "AI-native" language would require the whole ecosystem to migrate — not happening anytime soon. Mojo is probably the closest attempt and even that's more evolutionary than revolutionary.
That is a nice point, but the question still remains unanswered, in regards, to who will "require" or decide and drive things towards this direction. Is it humans or ..AI? Will the new ecosystem collapse or simply redefined?
Humans, but mostly by accident tbh. Nobody's going to sit down and decide "ok AI drives the ecosystem now", it'll just happen because the tooling is useful and everyone keeps using it. Ecosystems don't really collapse cleanly anyway COBOL is literally still doing bank transactions in 2025. So probably same thing here, long tail of codebases nobody wants to touch, new stuff increasingly AI-generated. The "who owns it" part is where it gets weird though.
How does this compare to just using systemd's sandboxing? ProtectSystem=strict, PrivateDevices, RestrictNamespaces etc. give you a pretty solid sandbox for any long-running daemon without extra tooling. Genuine question — I've been relying on systemd hardening for my own projects and wondering what I'm missing.
