Newsletter - How to prevent AI from breaking everything

[ivanagas]

Summary

AI coding is increasing velocity. It means more things are being shipped and more people are shipping things.

But AI coding has a bad reputation. Just like how a lot of content, videos, or images are seen as "slop", AI coding is often seen as poor quality. There's been a new wave of issues that AI coding creates, people even blame it for a lot of big recent incidents.

So how do you harness the power of AI coding without the downsides? Here's what we do to prevent AI coding from breaking everything and what you might want to consider too.

Headline options

How to prevent AI from breaking everything

What (if any) keywords are we targeting?

n/a

Outline (optional)

People are still ultimately responsible.

• Developers put their name behind the code they ship.
• We require reviews from other people still.
• It's our personal reputation on the line.
• AI is not the scapegoat for us. We do blameless post-mortems, but coding with AI is not an excuse.
• When there is a problem, we don't leave it up to an AI to solve. It's still ultimately people.
• https://posthog.slack.com/archives/C09G8Q32R6F/p1775046650100869

A lot of tests

• We have a lot tests, so much so, that a companies that build products for automated testing use us as a benchmark (depot)
• Product tests, storybook tests, formatting.
• Tests need to complete before we ship.
• AI helps us here writing unit and regression tests, test environments, chrome MCP to test end to end.

AI reviews

• Just like how AI can be used to ship code, it can be used to review code.
• We use multiple tools, swiss cheese approach.
• One stamps simple changes. Another helps fix flaky tests and improves the testing suite.
• We also use stacked reviews which makes it easier for teammates to review. AI helps with managing the stacked madness.
• AI should enforce standards.

Keeping changes isolated

• Our products are isolated, so one product going down doesn't effect other ones. We have worked to isolate our infrastructure too.
• New changes are also often isolated from existing code using feature flags which lets us roll out gradually and kill features if they are causing problems.
• We make small changes. Incremental. Stack changes. Trunk-based development.
• This limits blast radius.

Using the best tools

• We keep up to date on this stuff. We give people basically unlimited budget to use AI tools.
• Better tools make less mistakes.

Using AI before writing code

• When used right, AI can do a lot to help make sure you ship the right code.
• Using research and plan mode up front.
• Better planning beats faster typing.
• "Working with LLM tools makes it so much more feasible to discover the right code: the right architecture, the right abstraction, the right implementation. Instead of being fast, I spend more time being thorough, fully investigating a problem and shipping a thing that’s a few iterations better than what I started with" - Danilo

[raye-deng]

Great timing for this newsletter topic. The challenge with AI code quality is that the failure modes look nothing like traditional bugs:

• Hallucinated packages: AI generates imports for packages that don't exist on npm/PyPI. TypeScript compiles (mocked types), tests pass (mocked imports), production crashes.
• Silent deprecation breaks: Code works in dev with pinned versions, breaks when staging/production updates. Traditional linters don't catch this.
• Scope creep hidden in clean-looking diffs: AI "helpfully" refactors surrounding code when asked to fix a bug. Each change looks reasonable in isolation, but the cumulative complexity is invisible without cross-PR tracking.

The key insight we've found: SonarQube, ESLint, and unit tests are all designed for human-written bugs. AI-generated code has a completely different defect profile. You need a different detection strategy — deterministic registry validation, deprecation checks against live package metadata, and complexity baselines that flag when AI over-engineers a simple feature.

For anyone wanting to scan their codebase: npx @opencodereview/cli scan . --sla L1

Would be interesting to see PostHog's take on which of these failure modes shows up most in your telemetry.