Kernel level anti cheat is really the maximum effort of locking down a client from doing something suspicious. But today we still see cheaters in those games running these system. Which proofs that a game server just cannot trust a random client out there. I know it's about costs, what to compute on client and what to compute in server side. But as long as a game trusts computation and 'inputs' of clients we will see those cheating issues.
It’s not about costs, it’s about tradeoffs. In an online shooter game (for example) there is latency, and both clients are going to have slightly different viewpoints of the world when they take an action.
No amount of netcode can solve the fact that if I see you on my screen and you didn’t see me, it’s going to feel unfair.
That does not make any sense to me. A human can produce software that is at least as bad. Vice versa, a good developer can also create good software with AI. They should focus on actual quality - the outcome - and evaluate it neutrally rather than making such stupid blanket statements.
Trying to figure out if this observation was intended to frame it so that it's less|same|more scary. The effect is more, but it sounds like the intention was less.
> Or is the performance of those models also worse there?
The context and output limit is heavily shrunk down on github copilot[0].
That's the reason why for example Sonnet 4.5 performs noticeably worse under copilot than in claude code.
> You do mentoring because the pay off is a junior that develops into a senior; writes better code more efficiently. But what's the pay off with going through this process with AI?
This point is so underrated, when discussing about replacing junior devs with AI.
What a coincidence, today is the annual LAN party with my school friends. We've been doing this once a year between christmas and new year for many years, and I enjoy every second of it.
