Getting Freaky in the Age of 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 competitive advantage.

Standard vs. Weird

To see why this matters, let’s look at a miniature example: building a collaborative document editor.

Team Standard uses the default AI stack. They prompt Cursor to build a React frontend with a Node.js backend and PostgreSQL. The AI generates it perfectly. But as users start collaborating, they hit race conditions. Team Standard responds by throwing money at the problem— adding Redis pub/sub, writing complex conflict resolution logic in JavaScript, and spending weeks debugging edge cases where a user’s cursor inexplicably deletes an entire paragraph. Their feedback latency is massive because the architecture fights the inherent reality of distributed users.

Team Weird decides to use a Local-First architecture with CRDTs. The learning curve is brutal. They have to deeply understand distributed state. But once they cross that threshold, they use AI to generate the boilerplate for their CRDT data structures. The result? Every user edits locally with zero latency. Syncing happens silently in the background. If the server goes down, nobody notices.

Team Standard shipped faster. Team Weird shipped a fundamentally superior product that Team Standard cannot easily copy without rewriting their entire architecture from scratch.

Scaling the Wrong Variable

When faced with the complexity that Team Standard encountered, the traditional executive response is has fallen into a familiar trap: “If the standard stack is getting hard to manage, we just need to hire more people. Let’s hire ten more devs, give them all Copilot, and throw bodies at the problem.”

Alternatively, many companies are aggressively laying off developers under the illusion that they are trivially replaceable. This is a dangerous and short-sighted strategy in the opposite direction. After all, if AI is so powerful but still requires a degree of human oversight, couldn’t you drastically outpace your competitors who are slow-walking their way to the same destination using just their measly human brains?

This is what I perceive to be one of the largest traps of the AI era. Either way, you are scaling the wrong variable.

AI is incredibly good at making individual humans type faster. But AI does absolutely nothing to reduce the coordination tax between humans. In fact, it accelerates it. If you have ten mid-level developers using AI to generate standard boilerplate, you don’t get 10x the velocity. You get 10x the merge conflicts, 10x the inconsistent patterns, and 10x the code that nobody deeply understands. You are just buying more shovels to dig the same hole faster, but now the shovels are very expensive enterprise subscriptions.

Brooks’ Law— that adding manpower to a late software project makes it later— has not been magically repealed by AI. If anything, it has been supercharged. Because now, instead of waiting three weeks for a developer to write a convoluted microservice that creates a bottleneck, the AI can generate it in three hours. You hit the architectural wall faster. Hooray.

When you hire a large team, you don’t compound learnings; you fraction them. Knowledge is siloed. You end up with an aristocracy of a few senior engineers who actually understand the system, acting as bottlenecks for a sea of glorified code reviewers.

What I’m coming to believe is that three weird-tech artisans with rigorous guardrails and AI will run circles around twenty standard-stack developers. The artisans don’t have to coordinate with each other because their guardrails (the type system, the compiler, the deterministic tests) are doing the coordination. Rather than aggressively scaling headcount, they are scaling insight.

The Secret Sauce Isn’t on GitHub

There is another, hidden reason why I believe weird tech creates an unassailable moat: the limitations of LLM training data.

LLMs are fundamentally parasites on public code. But sifting through massive amounts of public GitHub repos to find genuinely “good code” is an incredibly challenging task, and currently, LLM training cares far more about quantity than quality, or insofar as quality is concerned, it is for the purpose of benchmaxxing. The result is that the true secret sauce of the world’s most dominant tech companies is completely invisible to AI.

Look at Bloomberg. They didn’t conquer Wall Street by spinning up standard microservices. They built a monolithic, hyper-optimized custom C++ engine and proprietary networking stack designed to push market data to terminals with microsecond precision. Their entire architecture is an exercise in ruthlessly minimizing feedback latency for traders. You can’t prompt an LLM to “build a Bloomberg competitor” and get anything close without loads of human effort, because the exact algorithms and proprietary protocols they use to achieve that speed are locked inside their vaults.

Or look at Standard Chartered. They’ve made massive, strategic bets on functional programming languages like Haskell for their complex derivative pricing and risk engines. Why? Because in high finance, a bug isn’t a broken UI— it’s a catastrophic multi-million dollar loss. By using advanced type systems to make “illegal states unrepresentable,” they turned the compiler into a rigorous learning tool, catching errors before the code ever ran. An LLM might be able to write a Haskell tutorial, but it has absolutely zero training data on Standard Chartered’s proprietary, heavily constrained internal domain models.

When you build a bespoke system like this, your competitors can prompt ChatGPT all day to “build a system like ours,” but the AI will just give them the standard, median approximation. It cannot give them your secret sauce, because your secret sauce was never uploaded to GitHub in the first place.

Trapped in the Present

There is an even deeper blind spot than missing out on proprietary past code. LLMs are utterly trapped in the present.

There is a pseudo-myth that because LLMs have read the whole internet, and all the other repositories of human knowledge, they have perfect context. They don’t. As an engineer embedded in a business, you carry a massive, invisible load of organizational context about the future. You know about the massive enterprise contract closing in nine months that will require a radically different multi-tenancy model. You know the exact traffic patterns expected when the new customer segment onboards in Q3. You know the unwritten rules of what the CEO actually cares about versus what the Jira ticket says.

Yes, you can wire up Model Context Protocol (MCP) servers. You can give the AI tool usage to query your database, read a Linear ticket, or pull a Slack thread. But tool usage only gives the AI a narrow, reactive peek at the now. It can answer “what is the state of this bug today?” It cannot hold the complex, evolving, contradictory web of organizational strategy in its head.

Even if you tried to brute-force this knowledge into a prompt, you hit the hard wall of the context window. You are forced to summarize your company’s future, and in summarizing, you lose the very nuance that makes it actionable.

Most critically: The AI does not know what you value.

It doesn’t know that you are willing to sacrifice 10ms of latency for a 50% reduction in infrastructure cost because the CFO is breathing down your neck. It doesn’t know that a certain edge case is a career-ending risk for your team, even if it only affects 0.01% of users. It optimizes for token prediction; you optimize for business survival.

This is why much of what we’re seeing with AI-generated architectures is so aggressively mediocre. They are perfectly optimized for a snapshot of the present that doesn’t actually exist. You need weird tech because weird tech is the physical manifestation of your specific future constraints. You bend the technology to meet the future you see, and then you use the AI to draw the rest of the fucking owl.

The Death of the “Novelty Budget”

My former coworker, Mark Wotton, wrote beautifully about how engineering teams need a “novelty budget”—the idea that you only have so much runway to spend on experimental tech before it stalls your product.

That was true in the pre-AI era. Today, the novelty budget is effectively dead. Case in point: I recently asked an AI agent to compile the Glasgow Haskell Compiler (GHC) to WebAssembly and run it on a CDN. Ten years ago, that was a month-long, heroic effort. The agent managed it without breaking a sweat.

And it’s not just humans exploiting this. The AI companies themselves are already getting into deeply weird territory. Consider the recent launch of Kimi K3. As an early proof of concept, they had the model design a chip to serve a nano model built on its own architecture. In a single 48-hour autonomous run, K3 built, optimized, and verified the chip using open-source EDA tools on the Nangate 45nm library. Within 4 mm², the chip closes timing at 100 MHz and sustains over 8,700 tokens/s decode throughput in simulation, packing 1.46M standard cells, 0.277 MB of SRAM, and an INT4 MAC array with fused dequantization. That’s according to their press release. Frankly, I haven’t got a clue what that means, but sounds pretty neat. A chip built by a model, for a model. If that doesn’t reflect the kind of long-horizon, agentic weirdness we’re barreling toward, nothing does.

The bar for “heroic effort” has been obliterated. The real magic happens when you combine this lowered friction with deep domain knowledge. I’ve been noodling on trading algorithms for a long time. Recently, I used an LLM to generate a nice Domain Specific Language that compiles trading algorithms directly into Futhark code for backtesting. (Futhark is a somewhat obscure, purely functional GPU array programming language). The result is obscenely fast.

Would I have tried Futhark as a human? Probably not, just due to time constraints and the sheer terror of learning how to use GPUs and linear algebra effectively after giving that part of my college education 16 years to decay. But because the AI could bridge the gap between the trading ideas I had and the obscure syntax of a GPU language, I unlocked a massive performance asymmetry that I never would have touched otherwise.

The Future Belongs to the Artisans

Now, reading this, you might think “holy shit, Ian has gone full-on into AI psychosis”. Maybe? People under psychosis generally don’t recognize that is the situation that they’re in. I’d like to argue that I’m just trying to make a pragmatic case for how we should try to get value out of these new, freaky, obnoxious chatbots that have settled among us.

When anyone can generate a million lines of perfectly average, standard code, “average” and “standard” lose all value. The value shifts to the edges.

The AI is already designing its own silicon. If you’re just using it to generate boilerplate React components, you’re using a cosmic genie to butter your toast.

Don’t wish for unlimited cosmic power just to end up trapped in a lamp of your own making, or have your codebase feed you your own cat for dinner. Be Aladdin. Use the Genie to test your small hypotheses, generate your FPGA logic, and write your boilerplate. Reserve your own mind for the deep understanding of constraints. Embrace the rigid guardrails, champion the sick and twisted architectures, and build something the AI could never have dreamed up on its own.