The new bottleneck

We’ve been using AI tools to ship faster, but a weird side effect has appeared; our code review process is suddenly the part slowing us down. It isn’t that we’re lazy, it’s just that the code comes in so fast now. When you can generate a PR in minutes, you don’t always have that deep mental map of the logic you’d get from writing it line by line.

Intent vs. Output

I keep seeing PRs where the tests pass and everything looks clean, but I’m missing the story. AI is great at generating plausible code, but it doesn’t know our system’s history or those weird production edge cases we’ve spent years learning. Instead of reviewing intent, I’m often just staring at output and trying to reverse engineer why it was built this way.

Solving for velocity

1. Writing the why first: I’ve started asking my team to drop a quick paragraph on what they’re trying to achieve before they even touch the code. It saves me so much time when I’m reviewing.
2. Tiny PRs only: I’m pushing for 200 line limits. AI loves to dump 700 lines of code at once, but my brain usually taps out after 400.
3. Bot only style checks: Let the AI handle the linting and formatting, but never trust it to catch race conditions or architectural mess ups. That’s still on us.

Intel and AMD’s secure enclaves were marketed like magic vaults: mathematically perfect, safe even from whoever physically controlled the machine. Then researchers broke key parts of that trust model for under $1000 using secondhand equipment and improvised hardware. The result was uncomfortable but simple: these systems still stop many software threats, rogue admins, and casual cloud snooping, but the stronger promise people believed in was never real.

This was not a failure of cryptography, it was a failure of storytelling. TEEs remain useful tools, but they were sold as if silicon could eliminate the need for layered security. It cannot. Threat models matter, limitations matter, and “secure against some attackers” is not the same as “impossible to compromise.” The vault still stands. The legend around it does not.

I wrote this piece because too many security teams still defend against bugs while ignoring ownership. In the WordPress plugin attack, nobody needed a zero-day. The attacker reportedly bought trusted plugins, pushed malicious updates through legitimate channels, then quietly waited months before activating. That’s the shift: trust itself became the exploit. If someone can buy a dependency, acquire a maintainer account, or take over an update stream, they inherit the access your audits already approved.

Most ecosystems are solving yesterday’s problem. We obsess over CVEs, scanners, and static analysis while ignoring chain of custody. The real question is no longer “is this code safe?” but “who controls this code today, and who might control it tomorrow?” Until package registries and software platforms treat ownership transfers as security events, auto-update can become auto-compromise.

AI can now recreate frameworks, clone interfaces, and generate code that looks shockingly close to mature products. It’s led many people to claim software moats are dead, but I’d argue the opposite: weak moats died, and real ones survived. The hard part was never writing code; it was learning, through outages, bugs, and user chaos, what the code actually needs to do. Those lessons live in battle-tested test suites, infrastructure, and hard-earned trust.

Code is becoming cheap, but experience is becoming expensive. An AI can imitate architecture in days, but it cannot inherit ten years of production scars in a weekend. It can’t fake the regression test created after a midnight incident or the instincts of engineers who have already stepped on every landmine. The strongest software is no longer the cleverest codebase; it’s the one that remembers every mistake.

As traditional religion declines in many modern societies, the need for certainty has not disappeared, it has migrated. This piece argues that AI may become the next belief system, not through worship, but through dependence. When algorithms are opaque, highly capable, and increasingly responsible for decisions, they begin to resemble old forms of authority: mysterious, trusted, and rarely questioned. The black box becomes the shrine.

The danger is not conscious machines, but obedient humans. People have always built meaning systems when reality feels chaotic. In the past it was priests, astrologers, or fate. Now it may be recommendation engines, predictive models, and automated judgments. If we stop demanding explanation and start treating outputs as revelation, AI does not need to become divine, we will make it so ourselves.

AI agents can now generate functions, scaffolds, and even full services faster than humans can type. That has triggered a familiar panic: if machines write the code, what is left for engineers? This piece argues the confusion comes from mistaking typing for thinking. The real job was never production of code; it was judgment under uncertainty, with code as the interface.

Execution is becoming cheap; responsibility is not. AI compresses the gap between decision and outcome, which exposes engineers who were mostly executing known patterns rather than owning decisions. What matters now is clarity of intent, understanding tradeoffs, and anticipating consequences. The higher leverage sits in defining what should exist, not implementing it.

Engineering value shifts from output volume to decision quality. Systems get built faster, but mistakes propagate faster too. In that environment, taste, restraint, and systems thinking become more important than raw coding speed. The differentiator is no longer who can build, but who can decide correctly, and live with the result.

A production regression slipped through CI in a Go codebase that showed everything as green. Tests passed locally, CI was clean, deployments looked safe; yet real functionality was broken. The investigation eventually led to something deceptively simple: a TestMain function that never called m.Run(), meaning the entire test suite was silently skipped with no warnings or errors.

The key issue is Go’s design: once TestMain exists, it fully takes over execution and the developer becomes responsible for invoking the test runner. If m.Run() is missing, Go does exactly what it was told: nothing. No tests run, but the process still exits successfully, producing a false sense of correctness.

The broader lesson is about how easily “green CI” can become meaningless when framework conventions are misunderstood. In Go, silence is not safety; it is often absence of execution. A single overlooked line can turn an entire test suite into a no-op, making test infrastructure feel reliable while silently doing nothing.

Apple never advertises RAM because that number isn’t part of their product philosophy. I’ve always found it fascinating how iOS is built around strict memory control; apps are suspended when not in use, states are frozen, and the system aggressively manages resources in the background. The result is a tightly controlled environment where performance comes from orchestration, not raw hardware visibility. Users don’t manage memory, the system does it for them.

Android takes the opposite approach. It exposes hardware specs because its model assumes openness and flexibility. Apps can run more freely in the background, memory is less aggressively reclaimed, and the system relies on pressure-based cleanup rather than strict suspension. This creates a lot of room for customization, but it also leads to variability in performance and battery life.

I see this as a deeper philosophical split: Apple optimizes for abstraction and consistency, hiding complexity to preserve the experience, while Android embraces transparency and control even if it costs some predictability. RAM becomes less about hardware and more about ideology; it’s about whether the system should manage everything silently, or expose enough for us to reason about the tradeoffs ourselves.

AWS Lambda’s ‘pay for what you use’ model has a dark side nobody puts in the pitch deck: an attacker can control what you use. Spend a small amount on a botnet hammering your public endpoint, and your compute bill eats far more in return. Scale that up and you’re looking at five figure invoices before you’ve even noticed anything’s wrong, all while AWS cheerfully auto-scales to absorb the traffic. It’s called a denial of wallet attack, and it’s a completely logical exploit of how serverless pricing works.

The fixes aren’t complicated; rate limiting on every public endpoint, billing alerts at multiple thresholds, strict timeouts, concurrency limits, and input validation before any real processing kicks off. None of it is glamorous, but skipping it because you’re moving fast is how you end up in an emergency meeting explaining why your AWS bill looks like a car payment. The bigger mindset shift is treating your billing dashboard as a security monitor, not just a finance report. Unusual cost spikes often surface problems before your actual monitoring does.

Microsoft porting the TypeScript compiler from JavaScript to Go, picking up a 10x speed boost, is about as close to a public confession as you get in tech. They built a massive, CPU-heavy tool in the wrong language, hit the wall hard enough, and quietly rewrote it. Node.js is great for juggling I/O and async API calls, but the moment you throw real computation at it, the single-threaded event loop taps out. No amount of V8 optimization changes the underlying physics.

This isn’t a dunk on JavaScript; it’s a reminder that what the team already knows is a terrible reason to pick a runtime for the wrong job. The industry spent a decade pretending server-side JS was a universal answer, and now even Microsoft is cleaning that up. The lesson isn’t to abandon JS. It’s to use the right tool, and maybe stop acting surprised when a compiled, natively concurrent language smokes an interpreted one at CPU-heavy work.

AI coding assistants are great at producing code that looks right: clean syntax, reasonable structure, and plausible logic. The problem is they have no idea what my app actually needs. They don’t know my edge cases, my security constraints, or the fact that someone might call a function with input that blows the stack. That’s the gap TDD fills. I write the tests first, let them fail, and then generate or write code that passes them. If the AI’s output doesn’t hold up, I know immediately instead of finding out in production.

The smarter move is what some call Test-Driven Generation; I write the tests, hand them to the AI, and make it generate code that satisfies them. Now the AI is working within constraints I defined, not just vibing its way through a prompt. It flips the dynamic from “hope this is right” to “prove it’s right.” In an era where everyone’s shipping AI-generated code at speed, TDD is the one thing keeping that speed from becoming a liability.

Most people who bounce off Rust do it because they try to learn it the same way they’d pick up any other language: skim the docs, start building, and figure it out as they go. That doesn’t work here. I’ve found that the best approach is simple; read the Rust Book cover to cover, do the Rustlings exercises, and the language stops feeling hostile. The upfront investment is real, but it’s a one-time cost that pays off every time I don’t have to chase down a data race at 2am.

The Go comparison is the most interesting part to me. Go has a reputation for being simple and beginner-friendly, and it is, until you’re doing concurrency and subtle synchronization bugs start appearing in places you didn’t expect. Rust eliminates that entire category of problem at the compiler level. It’s harder to get started, but easier to stay correct. For anyone who cares about reliability over velocity, that trade-off is a pretty easy sell.