待翻譯：Getting Freaky in the Age of AI

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

Pop culture has spent decades (probably actually centuries?) exploring the art of wish-making, and the modern AI has commoditized wishing machines. At the relatively benign end of the spectrum, you have Aladdin. Aladdin gets cosmic power, but he uses the Genie strategically— to handle the mundane, to test small ideas, and to eliminate friction— while reserving his own human agency for the actual problem-solving. He gets more or less what he asks for, without malice. In the middle, you have the classic Monkey’s Paw. You get what you asked for, but not what you intended. You wish for a million dollars, your relative dies in a horrible accident, and you get the life insurance payout. The wish is literal, but the intent is lost. And then, at the darkest end of the spectrum, you have deals with devils, or movies like Curry Barker’s 2025 horror film Obsession. In the film, a guy buys a supernatural novelty toy and wishes that the girl he likes would love him more than anyone in the world. The toy grants the wish, but it does so in a way that feels seemingly, intentionally malicious. He gets his wish, but she becomes a psychotic, homicidal stalker who feeds him his dead cat. The wish fulfills the letter of the law in the most punishing, horrifying way possible. Walk into any tech startup today, and you’ll see developers treating AI like the Obsession toy. They tap into unlimited cosmic power via Cursor or Copilot, prompting AI to spit out massive conglomerations of code. But without deep engineering intuition to constrain that power, they don’t become gods— they become slaves to unvalidated causality. They ask the AI for a feature, and the AI maliciously grants it. The resulting 10,000 lines of perfectly formatted, completely unmaintainable boilerplate doesn’t feel like an accident; it feels like the AI took the prompt and actively conspired to maximize their future suffering. They are trapped in a cursed situation of their own making, often not yet realizing the extent of the consequences they will soon face. To win in the era of, you have to act like Aladdin. You have to use the AI to eliminate the mundane, reserve your brain for formulating your most sick and twisted tech opinions, and then use the AI to actualize them. You have to get weird. The Illusion of AI Productivity To understand why weird tech is your moat, we have to talk about what “productivity” actually means. We usually measure it by how much stuff we ship. But in software development, we aren’t shipping value when we write code— we are shipping questions to reality. And when our code eventually comes into contact with reality, we have the opportunity to learn. The speed at which you learn is dictated not by your typing speed, but by your feedback latency. Every time you get a change in front of your users, you have the opportunity to learn something about the problem you are solving and course correct if necessary. If you are shipping huge quantities of concurrent changes, you don’t necessarily get to learn as much as you would if you were shipping fewer changes more slowly, because you can’t readily attribute beneficial outcomes to individual changes. Herein lies the danger of the standard AI stack: LLMs allow us to generate massive batches of code instantly. You can prompt an AI to spit out 10,000 lines of standard React boilerplate in an minutes at this point. But you haven’t reduced uncertainty of the problem you are solving by 10,000x. You’ve just created a massive batch of unvalidated causality. You output a lot, but you learn nothing. That isn’t to say there’s no benefit here– you certainly can potentially land changes in front of you users faster than you could before, but you begin to verge into the realm of the Mythical Man Month. The “Glorified Code Reviewer” Trap If you’ve used AI to generate a massive standard-stack feature, you know exactly how this feels. You hit ‘Generate’, the screen fills with 800 lines of perfectly formatted TypeScript, and your heart sinks. You aren’t an architect anymore; you are a glorified code reviewer trapped in a Kafkaesque loop. You stare at the code, realizing you have no mental model of why it’s structured this way. You deploy it with crossed fingers and a vague sense of impending doom. That dread? That’s the physical sensation of high feedback latency. You aren’t building software; you’re just babysitting an alien artifact that occasionally demands more RAM. To escape this trap, you have to change not just how you write code, but how you think about systems. The Danger of Inbreeding and the Power of Cross-Pollination If your mental diet consists entirely of Hacker News, React release notes, and Medium articles about scaling Node.js, you are engaging in intellectual inbreeding. The gene pool is shallow, and the offspring are inevitably mediocre. If you only consume standard inputs, you will only generate standard outputs. And in the age of AI, standard outputs are worthless. To formulate the kind of sick and twisted tech opinions that create competitive moats, you have to aggressively cross-pollinate your mental models. You have to go to the absolute edges of computer science and drag obscure concepts back into the present. Read ancient ACM papers from the 1970s on database transactions. Dive deep into modern academic research on formal verification. Study the architecture of 1980s telephone switches. Read the whitepapers on experimental programming languages that never caught on. When you drag a concept from a completely foreign domain—say, applying a memory management technique from an old operating system kernel to a modern web concurrency problem—you create a structural mismatch. You see a solution that the LLM will never hallucinate on its own because the training data rarely, if ever, connects those two dots. The AI has, of course, read all the same papers you have, but it lacks the human intuition to smash them together in the context of your specific business constraints. Cross-pollination is how you manufacture the “intent” that the AI cannot. The Sandbox for Sick and Twisted Ideas Once you’ve cross-pollinated your brain and come up with a truly bizarre, high-leverage architectural solution, you use the AI for what it’s actually good for: an incredibly fast sandbox. Because AI has lowered the friction of implementation to near-zero, you can now explore architectural spaces that were previously the exclusive domain of mad scientists and PhDs. For example, consider these outlandish ideas (which I am not actually advocating for, but you get the idea): The “Databaseless” Database (Persistent Memory): Standard architecture says: Application -> ORM -> Serialization -> Database -> Disk. What if you skipped all of it? Using NVDIMMs (Non-Volatile Dual In-line Memory Modules), you can map a data structure directly to RAM that survives a power loss. No serialization, no query language, no network latency. Just raw pointers to memory. An LLM would never architect this on its own, but if you’ve read the CS research on byte-addressable storage and have the sick idea, you can prompt it to: “Write unsafe Rust to mmap a B-Tree struct directly to /dev/pmem0 with proper cache-line flushing.” It handles the grueling bit-twiddling; you get a billion reads per second and a fantastic party trick. The Network Is The Database: Instead of a standard client-server fetch model, what if state didn’t live in a database at all, but purely in the network fabric? You could design a custom multicast routing protocol inside your data center where state updates are just UDP packets blasted across a subnet. Nodes subscribe to IP addresses to “read” state. There is no central broker to bottleneck, and your network engineer will have a mild aneurysm, but the LLM won’t invent the protocol without you nudging it in the right direction. It will, however, happily write the C socket code to join the multicast group and parse the packets while you design the overlay tree. The Truman Show Debugging Model (Total Determinism): Standard debugging is chasing heisenbugs across distributed systems. The sick and twisted alternative: strip all randomness out of your production environment. Use a custom shim or a tool like Antithesis to intercept every system call— gettimeofday(), random number generation, thread scheduling— and replace it with a deterministic pseudo-random number generator driven by a single seed. If a bug happens in prod, you just grab the seed, replay it locally, and the exact same failure spotted in prod is reproduced locally. It’s no longer a heisenbug; it’s a Truman Show reality where even the weather is scripted. You ask reality a question, and reality gives you a perfectly reproducible, zero-noise answer. What I think is good about this mindset when it comes to AI usage is that it forces you to think about the problem you are solving from first principles, rather than just blindly following the latest trends. Moreover, it allows you to explore things that you simply wouldn’t have previously, because the pre-AI cost of exploring these ideas was too high if the idea didn’t pan out. Committing Infrastructure Heresy Beyond the algorithmic level, AI allows us to commit absolute heresy at the infrastructure and tooling layer. But I need to be crystal clear about the price of admission here: You cannot walk into this wild west unarmed. You can invent your own network protocol. You can write your own hypervisor. You can move away from hyperscalers to self-hosting on bare metal. You can throw away standard load balancers and write your own Kubernetes schedulers. You can rewrite an “okay” third-party tool into exactly what you need, build your own migration systems, and implement internal libraries that perfectly match your tastes rather than settling for public equivalents. You can do all of this, but only if you have incredible validation suites and rigor in place first. If you build a custom K8s scheduler without a rigorous property-based testing harness, or tools like TLA+ or Alloy backing you up, you are just building a highly optimized, AI-accelerated way to take down your entire cluster on a Tuesday. But if you get your guardrails and harnesses in place first, something magical happens: they self-reinforce over time. You use AI to generate the exhaustive test cases for your custom network protocol. You use those tests to lock down the behavior. Then, you use AI to generate the implementation. Every time you find an edge case, you add it to the harness. The AI doesn’t make your system fragile; your rigor makes the AI’s output safe, and the AI makes your rigor scalable. Once that flywheel spins up, the advantages are staggering: Rewriting the “Okay”: That open-source tool you rely on has a bug, and the maintainers won’t fix it for six months. Instead of forking and fighting merge conflicts, you have the rigor to rewrite the 500 lines that actually matter into an internal library that perfectly fits your domain. AI writes it in an hour. Bespoke Migrations: Standard ORMs choke on complex, multi-tenant schema migrations. You write a custom migration engine in a strictly typed language that understands your exact domain constraints, turning a weekend of white-knuckle database changes into a boring, automated button press. Hyperscaler Independence: By writing your own hypervisor or custom schedulers, you strip away the bloated abstraction layers of AWS or GCP. You tune the hardware exactly to your traffic patterns, cutting costs by orders of magnitude while your competitors noodle along, assuming that everyone runs standard EKS. Now, I’m not saying you should go and rewrite all of your infrastructure from scratch. But I am saying that AI is rapidly becoming capable enough that your competitors can clone technical aspects of your product with frightening speed, so you better be willing to start looking under rocks for your own [truncated for AI cost control]