Kyle LeMarbe

AI-linked stocks dropped sharply this week after the CEOs of some of the industry's most advanced labs, Anthropic's Dario Amodei among them, called for a slowdown in the pace of AI development. The reporting described it as a warning about outrunning the ability to build in adequate safety measures, and markets reacted about how you'd expect. Nasdaq futures dipped, AI-adjacent names across the US and Asia sold off, and headlines framed it as an industry finally admitting it might be moving too fast.

I don't think that's the right read. I don't think we should slow down the development of new technology. I think we're diagnosing the wrong variable.

Speed Was Never the Real Problem

Slowing down development sounds responsible on the surface. It isn't, because it treats velocity as the risk factor instead of treating the absence of guardrails as the risk factor. Those are not the same thing, and conflating them lets everyone off the hook a little too easily.

You can build fast and safe. You can also build slow and reckless. The pace of development was never the thing putting people at risk. What puts people at risk is treating safety, security, and robustness as a separate workstream from the product itself, something bolted on after the fact instead of engineered in from the start.

The Incentive Problem I Keep Seeing

I've watched this pattern repeat across the industry, not just in AI. There is a product ownership reward system that consistently pays out for the wrong thing. It rewards shipping something new. It rewards something sellable, something demoable, something that moves a roadmap slide forward. It does not reward the unglamorous work of making that thing secure, robust, and able to scale without breaking.

• New features get promotions. Hardening an existing system rarely does, even when it prevents the incident that would have cost far more.
• Sellable beats defensible. A flashy capability closes deals. A well-tested guardrail is invisible until it fails, and by then it's a postmortem instead of a headline.
• Guardrails get treated as a tax. Security review, red-teaming, and safety tuning show up as friction on the way to launch instead of as part of what's actually being built.

That's the fundamental flaw. Not that people are building too fast. That the reward system tells them, explicitly or not, that guardrails are optional overhead rather than a core deliverable.

Why "Slow Down" Doesn't Fix It

If a team's incentives reward shipping over safety, giving that same team more time doesn't automatically produce a safer product. It just produces the same product on a longer timeline, unless the incentive itself changes. You could slow the entire industry down by half and still end up with guardrails as an afterthought, because the underlying reward structure never moved.

Conversely, if guardrails are treated as part of the product from day one, meaning they're scoped, staffed, and reviewed alongside the feature and not after it, speed stops being the enemy. Fast and safe becomes achievable, because safety was never something separate from the build in the first place.

What a Common Goal Actually Looks Like

The framing I keep seeing is slowdown versus acceleration, safety camp versus progress camp. That's a false choice, and it's a distraction from the real fix. This can't be one side winning over the other. It has to be a common goal, where building capable technology and building secure, robust technology are the same job, evaluated by the same people, on the same timeline.

• Guardrails get designed alongside the feature, not requested after a review flags a gap.
• Product owners are measured on what they shipped and how it held up, not just on what they shipped.
• Security and safety work gets funded and staffed like a first-class part of the roadmap, not a shared service that gets deprioritized under deadline pressure.

None of that requires anyone to slow down. It requires the definition of "done" to include the guardrail, not just the capability.