We’ve all felt it. You wake up, open an app you use every day, and suddenly the “Buy” button is gone, replaced by a “Shopping Bag” icon buried in a sub-menu. Or perhaps the checkout flow you could navigate in your sleep now requires three extra clicks.

In physics, the rate of change in acceleration is called Jerk.  In software development, Technological Jerk is that jarring, motion-sick feeling users experience when the product changes faster than their ability to adapt. When you ship a “Big Bang” update, too often you’re not delivering value; you are delivering a shock to the system.

For years, we’ve heard the goal of “moving fast.” But speed without control isn’t progress, it’s a hazard. As we enter the era of AI-augmented development, the throttle is wide open. The question is: do you have the suspension system to handle it?

The Shift to e13n

To solve for Jerk, we have to treat experimentation not as a buzzword, but as a core technical constraint. We need a shorthand for it that reflects its complexity and its necessity. Let’s call it e13n—the 13 letters between the ‘e’ and the ‘n’ representing the heavy lifting of building, measuring, and learning.

Just as i18n (internationalization) ensures your app works across cultures, e13n ensures your app works for human behavior. It is the architectural discipline of building the “suspension” that allows you to accelerate smoothly—without the Jerk.

The New Abundance: Beyond Compute and Storage

When we talk about the strategic framework of software delivery, we focus on the Four A’s: Abundance, Autonomy, Alignment, and Automation. For decades, “Abundance” referred to the falling cost of compute and storage. We had plenty of “stuff,” but we had a scarcity of time—specifically, the engineering time required to build multiple paths for a single feature.

Historically, e13n was expensive. Building three versions of a feature meant triple the unit tests and triple the UI work. Many teams substituted “gut feeling” for data because the toil of building variations was too high.

AI has fundamentally changed the Abundance pillar.

Today, AI-assisted coding has collapsed the cost of variation. The “toil” of writing boilerplate and scaffolding UI components has dropped toward zero. We no longer have a scarcity of dev-hours to build experiments; we have an abundance of opportunity.

Practical Example: The e13n Manifest in Action

Imagine a high-friction checkout. Analytics show a 40% drop-off at the shipping stage. The “old way” would be to have a meeting, pick a new design, and force it on 100% of your users. That is a recipe for Jerk.

Instead, we use a structured e13n Manifest to guide our AI agents in creating variations:

1. The Hypothesis: Reducing form fields will increase conversion by 15%.
2. AI Scaffolding: We prompt our AI assistant to generate two distinct variants: a “Stepper” (multi-step) and an “Express” (single-page). The AI handles the repetitive task of mapping these different UIs to our existing backend APIs.
3. Decoupling with Flags: We deploy both to production behind feature flags. They are “dark.” We’ve separated technical deployment from the user-facing release.
4. Progressive Rollout: we show the variants to only 1% of traffic. We aren’t just looking at conversion; we are monitoring the “Blast Radius”.
5. Third Loop: we monitor both quantitative and qualitative feedback on how the variations are performing. 
6. Clean-up (now with AI!): no experiment is complete until we clean-up our lab space. Make sure to remove variations that you are not going to move forward with, ideally documenting that the experiment was tried and the outcome. This is another great use of AI to reduce toil.

The Third Loop: The System Health Dashboard

As a developer, you aren’t just responsible for the “Buy” button; you’re responsible for the whole machine. E13n isn’t just about UX metrics, it’s about system physics. When we run an experiment, we monitor three specific dimensions:

Solving for the “Leftover” Code: Post-Experiment Toil

The biggest objection to e13n is often technical debt. “If we build three versions, our codebase becomes a graveyard of losing ideas.” This is where the AI-powered cleanup comes in. In a Progressive Delivery model, once a winner is declared, the same AI agent that built the variants can be tasked with generating the “Decommissioning Pull Request.” It identifies the losing flag branches and strips them out. The advantage of building with feature flags is that removal of code wrapped in a feature flag is as protected as inserting code with a feature flag. AI ensures that the abundance of ideas doesn’t lead to a scarcity of maintainability.

The Goal: A Culture of Learning and Safety

If you are only using AI to write code faster so you can ship more features, you are just increasing the Jerk. You are accelerating a car that has no suspension. Eventually, you will hit a bump in user sentiment and the whole thing will fall apart.

The real power of AI is that it gives us the psychological safety to be wrong. When the cost of an experiment is low and the blast radius is controlled, your team gains the Autonomy to innovate without fear.

We have to stop treating “The Release” as a finish line. The finish line doesn’t exist. There is only the continuous process of Alignment—ensuring that the software we build actually serves the humans who use it.

AI has given us speed. Progressive Delivery gives us the steering wheel. And e13n provides suspension. It’s time to stop jerking your users around and start delivering with intention.