DEV Community: Dave Kurian

Why 'Write Once, Run Everywhere' Often Falls Short in Practice

Dave Kurian — Sun, 12 Jul 2026 19:04:45 +0000

The promise of "write once, run everywhere" has been a lie for thirty years. The desire behind it is real — nobody wants three codebases drifting — but the actual delivery has been: write once, debug everywhere, ship three slightly different apps.

I've watched teams ship a beautiful web product, then spend six months rebuilding it for iOS, then three more months for Android, then quietly accept that notifications behave differently per platform forever. The fragmentation isn't a bug. It's the default outcome of trying to make fundamentally different rendering systems agree on every pixel. The hardest part isn't the rendering itself — it's the long tail of edge cases where the platforms diverge. A button that wraps to two lines on Android but one on iOS. A modal that scrolls the wrong element on web. A date picker that picks a different timezone offset by platform. Multiply by 200 components and the team is now maintaining three divergent visual languages inside one product.

The three failure modes of cross-platform

Every cross-platform tool fails in roughly the same three ways. Naming them is the first step to escaping them.

Visual drift. The component "looks close" but not identical. A border that renders 1px on web and 0.5pt on iOS. A shadow implemented with box-shadow on web and a native elevation on Android — and they're never quite the same depth. The team accepts "good enough" and ships three slightly different visual languages under one brand.

Behavior drift. The component has the same name but different behavior. A <Select> that opens on mousedown on web and on tap on mobile — fine — but a <Dialog> that traps focus correctly on web and skips focus restoration on Android. The team writes platform-conditional code inside every component. "Write once" is now write-three-times-disguised-as-one.

Capability drift. Platform X has a feature the others don't. iOS gets haptics. Android gets the back button. Web gets URL state. The "unified" component decides: omit the feature, fake it on the unsupported platforms, or maintain three implementations. All three cost more than writing the component twice with shared types.

The contract that actually works

The lie of "write once" comes from conflating one source file with one outcome. The real goal is the latter. A single component definition that produces a visually and behaviorally identical result on web, iOS, and Android requires four things held in tension:

Same component name. <Button> is <Button> is <Button>. Not <Button>, <ButtonNative>, <ButtonWeb>.
Same props. variant, size, disabled, onPress mean the same thing and accept the same values on every platform.
Same design tokens. colors.primary.500 resolves to the exact same hex on every platform, even when the underlying color format differs (hex strings on web, native color objects on iOS and Android).
Same render contract. Tap on mobile equals click on web. Focus trap works the same way. Keyboard navigation is identical. The accessibility tree is identical.

Miss any one of these and the platforms drift.

What this looks like in code

The same component file ships to all three platforms. Web imports from @otfdashkit/ui; iOS and Android from @otfdashkit/ui-native — same JSX, same component names, same props.

import { Button, Card, Input, Stack } from '@otfdashkit/ui'

export function SignupForm() {
  return (
    <Card padding="lg">
      <Stack gap="md">
        <Input
          label="Email"
          placeholder="you@example.com"
          keyboardType="email"
        />
        <Input
          label="Password"
          type="password"
          secureTextEntry
        />
        <Button
          variant="primary"
          size="lg"
          onPress={handleSubmit}
        >
          Create account
        </Button>
      </Stack>
    </Card>
  )
}

The web bundle ships this as real DOM with platform-native accessibility. The iOS and Android bundles ship the same JSX through a native renderer that maps <Button> to the native button on each platform — same variant, size, disabled, and onPress semantics, the same tap-target sizes, the same focus behavior. Props that look platform-specific (keyboardType, secureTextEntry) are passed through as no-ops on platforms that don't have them. The component contract stays clean, and the screen code never branches on platform.

Design tokens flip one theme across every platform

Visual identity comes from tokens, not from the component code. One token file defines the entire theme:

export const tokens = {
  colors: {
    primary: {
      50:  '#F0F7FF',
      500: '#0066FF',
      900: '#003D99',
    },
    surface: {
      base:   '#FFFFFF',
      raised: '#F7F8FA',
      sunken: '#EEF0F4',
    },
    text: {
      primary:   '#0B1220',
      secondary: '#5A6478',
      inverse:   '#FFFFFF',
    },
  },
  radius: { sm: '6px', md: '10px', lg: '16px', pill: '999px' },
  space:  { xs: '4px', sm: '8px', md: '16px', lg: '24px', xl: '32px' },
  type:   {
    body:    { size: 16, lineHeight: 1.5 },
    caption: { size: 13, lineHeight: 1.4 },
  },
}

A theme flip is one swap:

import { applyTheme } from '@otfdashkit/tokens'
import { darkTheme } from './dark-theme'

applyTheme(darkTheme)

Web swaps CSS custom properties. iOS swaps native color references. Android swaps color resources. The component code is untouched. Every <Button variant="primary"> becomes the new primary color on every platform in the same paint frame. No stale iOS button lingering with the old brand color three weeks after a redesign.

[[DIAGRAM: design tokens flow from a single source file to three renderers — web, iOS, Android — each translating to its native color and unit format, while every component reads the same token name]]

Where AI coding agents make this worse (and how to fix it)

AI coding tools accelerate cross-platform work — but they accelerate the drift too. An agent extending a codebase without strict component conventions will happily invent <Button2> or sprinkle style={{ background: '#0066FF' }} directly into JSX. The codebase now has 200 components in ui/, 47 ad-hoc button copies in screens/, and three different blues for the primary brand color.

The fix isn't to disable the agent. It's to ship the conventions alongside the components.

Every full-stack kit ships with:

CLAUDE.md and .cursorrules describing the component contract — use <Button>, never raw platform primitives; use colors.primary.500, never inline hex.
20+ tested prompts in ai/prompts/ — "add a new screen", "swap the brand color", "wire auth to a new backend" — that produce code conforming to the kit's conventions.
A 24-item design checklist enforced by a script before any kit ships, so the conventions are enforced in CI rather than tribal knowledge.

The agent extends the kit. It doesn't regenerate it. That's the difference between an AI-native codebase and an AI-fragmented one.

What this enables

When the component contract actually holds, several things change at once.

A new platform is one renderer, not one rebuild. A hypothetical desktop or wearable target adds a fourth @otfdashkit/ui-* package. The component code, the tokens, the props, the screen code — none of it changes.

A redesign is one token swap. Change primary.500 from #0066FF to #0052CC once. Every component, every platform, every screen updates in the same paint frame. Marketing can ship a brand refresh in an afternoon instead of a quarter.

AI agents become multipliers, not entropy sources. With the conventions and prompts shipped, an agent adding a new screen produces code that conforms. The codebase stays a kit, not a museum.

Quality is measurable. The 24-item checklist runs in CI. A new component that drifts on color contrast, focus order, or tap-target size fails the script before it ships.

The lie, restated

"Write once, run everywhere" was never the goal. The goal is ship-one-product, render-everywhere-correctly. The mechanism that gets you there isn't a magic compiler. It's a strict contract — same name, same props, same tokens, same behavior — held consistently across renderers.

OTF ships that contract as ~200 components on three platforms, design tokens that flip themes identically, AI-tool configs that keep agents honest, and full-stack kits that demonstrate it end-to-end. The components are MIT-licensed on npm (@otfdashkit/ui, @otfdashkit/ui-native, @otfdashkit/tokens). The kits own the code outright, ship to production with a single script, and start at $99 (Everything Bundle $149). Live at saas.otf-kit.dev and fitness-preview.otf-kit.dev.

The myth isn't worth chasing. The contract is.

SpaceX Buys Cursor for $60B to Build the World's Most Useful AI Models

Dave Kurian — Sun, 12 Jul 2026 18:04:34 +0000

$60 billion for an editor. Read that again.

Yes, SpaceX just paid sixty billion dollars for Cursor. All stock. Largest software acquisition ever recorded. Take a second on that sentence, because the next one is the part that actually matters: at $60B, SpaceX is paying 20–30× Cursor's current revenue. That's not a price paid for what Cursor is today — that's a price paid for what the market believes Cursor will be at the end of 2026, when annualized revenue hits $6B (up from $2B today). The model layer just got repriced. Hard. Here's why that matters to anyone writing code on a Tuesday morning.

The receipt

The numbers, straight from the official filing:

$60B, all-stock. Every Cursor share converts to SpaceX Class A common at closing, at the volume-weighted average closing price of SPCX at the time. Cursor shareholders aren't cashing out — they're becoming SpaceX shareholders.
3.4% dilution at SpaceX's IPO valuation. Big, but not crushing for a company that raised $75B in its IPO four days ago and is trading well above offer.
Cursor today: 1M+ paying customers, $2B ARR, built by Anysphere.
Cursor by EOY 2026, per the deal's own projected trajectory: $6B ARR.
Close: Q3 2026, subject to regulatory approval.

The comps are almost unfair to write. Microsoft bought GitHub for $7.5B in 2018, Salesforce paid $27.7B for Slack in 2021, Activision went to Microsoft for $69B. A software deal isn't supposed to look like this. SpaceX isn't paying for code-editor market share; it's paying for share of the next decade of model-and-software co-evolution — and the market put a price on it accordingly.

The thing that already started

Here's the part the headline buries. Per the announcement, SpaceXAI has been jointly training a model with Cursor for the past several months. That model is expected to ship inside both Cursor and Grok Build in the near term. This isn't a buy-and-figure-it-out-later deal. The integration runway is already in flight.

That's the actual story. Two teams converged on the same product bet before the corporate paperwork caught up. SpaceXAI wants to build "the world's most useful AI models." Cursor has the funnel where every model gets stress-tested by a paying developer within seconds of release. The 20–30× multiple is the market's price for that loop running at $6B ARR instead of $2B.

How to actually use Cursor today

This is the part most "Cursor coverage" skips. If you haven't tried it — and 1M people have, so statistically you probably have — here's the fastest way in:

# macOS / Linux
curl  -L | bash

The default model is good. The move that changes everything is pointing Cursor at OpenRouter so you can swap models per-task without leaving the editor:

// ~/.cursor/settings.json
{
  "cursor.ai.primaryModel":    "openrouter/anthropic/claude-sonnet-4.5",
  "cursor.ai.fallbackModel":   "openrouter/minimax/minimax-m3",
  "openrouter.apiKey":         "${OPENROUTER_API_KEY}"
}

Now Cmd-K opens a prompt whose base URL is yours. Frontier one moment, cheap one the next. The 1M paying customers aren't paying for tab completion — they're paying for the loop where Cursor reads the whole repo, proposes a diff, runs the tests, fixes the tests, and lands the patch.

That's the loop SpaceX is buying. Not the editor.

What the 20–30× signal means for builders

When the public market pays 20–30× revenue for a coding tool, it says one of two things. Either it's wrong and in 18 months Cursor trades at half that multiple — and we're writing the autopsy. Or it's right, and the price of AI-native software just re-rated above every prior SaaS benchmark in history.

Honest read: in 2026, AI-native tools earn a premium multiple when they own a workflow loop that compounds with the model. Cursor owns the loop from intent → diff → test run → landed PR. The moat is the user-trained completion corpus, the deep IDE hooks, and the paying-developer feedback loop that ships every improvement back into a billion-token training set. If you're building an AI tool, that's the line you have to clear — not "calls a model," but a loop that gets tighter the more paying users run it.

The part that doesn't move when the model does

Here's where it lands for the rest of us.

A year ago the AI-editor story was Cursor vs Copilot. Then Claude Code showed up and ate the terminal-and-prompt crowd. Then Lovable, Bolt, Rork, v0 took the no-code side of the same wave. Now SpaceX is putting $60B behind the loop. The model layer moves every quarter — the agents, the editors, the harnesses, the base URLs. Some ship 15× faster than their peers, then a peer ships 16× faster the next month. The harness is, by construction, disposable.

What compounds across that churn is what the loop writes into. Your components. Your shipping surface. Whether the button the agent just shipped renders the same on web, iOS, and Android without you pasting a third adapter file. That's the layer where a year of agent commits either holds up or doesn't.

[[COMPARE: the churning AI tool layer vs the durable component layer]]

The honest framing isn't "Cursor vs a cross-platform kit." It's: use Cursor — it's the best agent loop on the market and $60B just said so out loud — and pair it with a component layer where the AI's diff doesn't break three platforms at once. One API, same component, same behavior on web, iOS, Android. That's the bit that pays you back whether tomorrow's editor is Cursor, Claude Code, or something none of us have heard of yet.

What this gets us

A few things, concretely:

Cheaper frontier access, likely. A SpaceX-Cursor combo has every incentive to subsidize model access inside Cursor's editor to keep the loop competitive. Watch for Sonnet- and M3-class pricing inside Cursor dropping hard over the next two quarters. (Listed as likely, not confirmed — no terms have been published yet.)
Real co-trained tools. The joint model shipping in Cursor and Grok Build is the first frontier model trained on the inside of a paying-developer feedback loop. Expect it to be noticeably better at long-horizon coding tasks than models trained on scraped GitHub alone — that's the bet, at least.
A repriced market. 20–30× ARR for AI-native tools sets the floor for the next 18 months of funding rounds. Smaller AI-coding startups are now valued against this comp, whether their loops deserve it or not.
A reminder that loops beat wrappers. The Cursor story is "a loop that gets tighter with usage." If your AI tool doesn't have one, the 20–30× multiple was never going to be yours.

What to watch

Three signals will tell you whether the 20–30× bet holds.

One: what ships inside Cursor and Grok Build within 60 days of closing. If it's a clearly better coding model than the public frontier, the multiple was right.

Two: regulatory posture. A $60B all-stock deal in a sector the FTC has already come after GitHub and Activision for won't close quietly. Watch for remedies, not refusal.

Three: the cohort. When the deal closes, every Cursor employee is now a SpaceX shareholder with vested upside tied to SPCX. Retention is the real risk — and the first thing SpaceX should solve, because the loop is the asset.

Deal closes Q3 2026. By then the next Cursor competitor — probably already incubated inside SpaceXAI — will have shipped something. The model layer keeps moving. Build on something that doesn't.

Claude Code's Auto Mode Now Default on Major Cloud Platforms

Dave Kurian — Sun, 12 Jul 2026 16:06:29 +0000

Anthropic shipped Claude Code 2.1.207 on Friday, and the one-line changelog entry hides a more interesting story than the headline suggests. Auto mode is now on by default on Amazon Bedrock, Google Vertex AI, and Microsoft Azure Foundry. The auto-mode classifier — a second model that reviews every pending file edit, build, commit, and pull request against the conversation context before execution — has been an opt-in feature since Claude Code launched in early 2026. After Friday's update, every enterprise team running Claude Code through those platforms has it on by default.

The reasoning Anthropic published alongside the change is the part worth sitting with. Their own telemetry found that 93% of prompts in manual mode were approved reflexively, without actual review. That number is a quiet indictment of how the manual-approval flow actually worked in practice: humans were rubber-stamping everything, and the approval gate was theatre. Auto mode replaces the rubber stamp with a second model that is, at minimum, not bored.

[[COMPARE: Claude Code auto mode before 2.1.207 vs after 2.1.207]]

That is worth appraising on its own terms before we get to the governance shift, because the two arguments are independent. The classifier is, on its own merits, probably a better safety net than an exhausted engineer mashing y, y, y, y at 4pm on a Thursday — and it is also a default that your compliance team did not sign off on. Both of those can be true.

What auto mode actually is

Auto mode sits between two extremes that enterprise teams have been picking between since Claude Code launched. On one end is manual mode, the default for interactive CLI sessions: every file write, shell command, test run, and commit requires a human to approve it. On the other end is the mode that bypasses all safety checks and is unsuitable for production environments holding SSH keys, secrets, and live credentials — a tool for sandboxes, not enterprise machines.

Auto mode is the middle path. Before executing any action, a dedicated second model — the classifier — reviews the pending operation against the conversation context and decides whether to allow or block it. The classifier monitors three categories of risk; scope escalation — the agent drifting from "fix the lint errors in this file" to "rewrite the auth module" — is the one named in the release notes.

[[DIAGRAM: pending action enters queue → classifier reviews against conversation context → allow or block → execute or stop]]

The key property is that the classifier is not the same model doing the work. It's a separate model with a narrower job, which means its failure mode is different from the agent's. When the agent is confidently wrong, the classifier is still reviewing. When the agent is being sycophantic, the classifier isn't.

The inversion: from opt-in to default-on

Here is the part that compliance teams should read twice. Before Friday, a security team that had not explicitly evaluated auto mode was protected by inertia — the feature was off, by default, and enabling it required setting an environment variable. After Friday, that same team must take affirmative action to keep auto mode off. The setting name, per the release: disableAutoMode, set in managed settings.

The operational consequence is a reversal of who bears the burden of action. In regulated industries — finance, healthcare, anything where every change to how AI agents interact with production systems potentially triggers a review — that inversion is the actual news. The classifier may be excellent. The classifier may be the right default for most teams. Neither of those facts changes that an enterprise-wide change in how AI agents touch production systems just shipped on a Friday afternoon with a one-line changelog entry.

That is the governance story, and it is bigger than the engineering story.

Three things to do this week

For teams running Claude Code through Bedrock, Vertex, or Azure Foundry:

1. Confirm the current state. Check whether auto mode is on for your team. If you have not set disableAutoMode in managed settings, the answer is now yes after the next update propagates. The signal to grep for in your org's run logs is whether agent-initiated commits are appearing without a corresponding approval prompt.

2. Decide, explicitly. For teams that want manual control, set disableAutoMode in managed settings before the next Claude Code update rolls out. The exact location depends on the platform — Bedrock, Vertex, and Azure Foundry each have their own managed-settings surface — but the flag name is the same across all three. Do not assume the previous opt-in environment variable still works; per the release notes, it has been removed.

3. For teams keeping auto mode on, scope the agent. You cannot tune the classifier directly, but you can constrain what the agent has access to. The narrower the filesystem, the fewer credentials, the smaller the blast radius, the less work the classifier has to do. Auto mode is a better default than reflexive human approval — but "better than rubber-stamping" is a low bar, and the classifier is not a substitute for sensible agent scoping.

What this gets us — and what doesn't change

The throughput case for auto mode is real. A classifier that catches scope escalation and blocks genuinely risky operations means your team can hand off the boring 80% — lint cleanups, dependency bumps, test scaffolding, the rote PRs that everyone skips review on anyway — and spend human review time on the 20% that actually changes product behavior. For most teams, that is a genuine productivity enable, not a marketing line.

What does not change: the components your agent writes still have to render identically on every platform your users actually touch. An auto-mode agent editing forty files an hour is going to drift toward platform-specific patterns fast — web-only CSS here, an iOS-only animation there, an Android-only intent filter somewhere else. The model changes. The frameworks it picks change with every release. The output has to compile and look the same on web, iOS, and Android regardless of which model wrote the call site.

That is the durable layer underneath the tool churn. Use auto mode for throughput, and keep the UI primitives your agent composes against independent of the agent itself.

Closing

Claude Code 2.1.207 is a one-line changelog that flips a governance default. The classifier is the most interesting part — a second model, watching the first, with a different failure mode. The Friday-afternoon rollout is the part that compliance teams should treat as the actual news. Three concrete steps cover both: confirm the state, decide explicitly, scope the agent. The throughput wins are real. The governance posture is now your problem to set, not the platform's.

Achieve True Cross-Platform Consistency with OTF's Unified Component System

Dave Kurian — Sun, 12 Jul 2026 06:03:17 +0000

Writing a component once and shipping it to web, iOS, and Android — same name, same props, same pixels — is the boring dream every cross-platform framework has been chasing for a decade. Most of them get 80% of the way there and then quietly leak the last 20% as platform-specific escape hatches. We tried most of them. Here's the part that actually works.

The parity tax, line by line

Every cross-platform project ships a balance sheet nobody wants to read. Three button components that drift apart over six months. Three inputs where the Android one loses its focus ring. Three loading spinners that look related but aren't. None of it is dramatic. All of it costs.

The line items:

Build drift. You write <Button> on Tuesday, ship a new prop on Wednesday on iOS, push the same prop to web on Friday, forget Android until QA pings you three weeks later. The bug isn't the prop — it's the calendar.
Design drift. A designer tweaks the primary colour in Figma on a Tuesday. The web theme updates in a PR the same day. Native ships the old shade for a quarter because the token export from Figma never reached the native repos.
Refactor drag. Changing one component means auditing three codebases, three type files, three test suites, three sets of snapshots, and three different review queues. The PR is 200 lines. The deployment dance is 2,000.

Three platforms. Three of everything. That's the tax.

One component, three platforms, one API

The same import path, the same props, the same JSX. Web:

import { Button } from '@otfdashkit/ui'

export function CTA() {
  return (
    <Button variant="primary" size="md" onPress={startCheckout}>
      Get started
    </Button>
  )
}

Native (iOS + Android, same file):

import { Button } from '@otfdashkit/ui-native'

export function CTA() {
  return (
    <Button variant="primary" size="md" onPress={startCheckout}>
      Get started
    </Button>
  )
}

Same variant. Same size. Same onPress shape. The ~200 components in the library cover the ground most apps actually need — buttons, inputs, sheets, lists, dialogs, tabs, toasts, navigation primitives — and every one of them ships with the same surface area on every platform.

That isn't a marketing claim. It's the API. You write <Button> once, you ship it three times.

Tokens are the source of truth

Components are half the problem. The other half is colour, spacing, type, radius — the visual grammar. If those drift, the components drift with them, and no amount of component-library discipline will save you.

Install the token package alongside the components:

npm i @otfdashkit/ui @otfdashkit/ui-native @otfdashkit/tokens

Tokens look like this:

import { tokens } from '@otfdashkit/tokens'

export const theme = {
  color: {
    bg: { primary: tokens.color.blue[600], surface: tokens.color.gray[50] },
    text: { primary: tokens.color.gray[900], muted: tokens.color.gray[600] },
  },
  space: { 1: tokens.space[1], 2: tokens.space[2], 4: tokens.space[4] },
  radius: { sm: tokens.radius.sm, md: tokens.radius.md },
}

Flip bg.primary from blue to teal once, on one platform. All three update. The same <Button> on iOS, Android, and web renders with the same hex, the same padding, the same border-radius. Visual parity is a property of the token graph, not a hope held by the team.

Theme switching is the same primitive. A dark theme is a second token export. Components don't know it exists — they consume whatever the current theme hands them, and the theme is the only thing that knows which mode is active.

The 24-item gate before anything ships

Most cross-platform libraries ship whatever compiles. The cross-platform kits ship after a script gates them against a 24-item design checklist. Touch targets meet platform minimums. Contrast passes WCAG AA. Focus rings are visible against every background token. Safe-area insets are honoured on every sheet and modal.

The checklist is enforced, not aspirational. A kit doesn't reach npm publish until the script returns zero. That's the difference between "looks right on my laptop" and "passes review on a real device, in dark mode, with the user's preferred text size".

A few items from the actual list:

Check	Why it matters
Tap target ≥ 44pt iOS / 48dp Android	App Store and Play Store floor
Contrast ratio ≥ 4.5:1 for body text	WCAG AA, also just legible
Dark-mode parity per token	No "almost dark" surfaces
Safe-area inset handling	Notch, dynamic island, gesture bar
Reduced-motion fallback	System setting respected, not ignored

If a kit fails any one of those, it doesn't ship. The gate is the contract.

AI agents extend, they don't regenerate

This is the part most cross-platform stacks get wrong. Hand an AI coding agent a fresh empty repo and it invents its own conventions. Hand it a kit with no documentation and it does the same thing, but louder.

Every full-stack kit ships the conventions the agent needs to extend the kit instead of replacing it:

my-app/
├── CLAUDE.md            # how the kit is structured
├── .cursorrules         # what the agent must / must not change
├── ai/
│   └── prompts/         # 20+ tested prompts for common tasks
└── src/
    └── ...              # your code, on top of the kit

CLAUDE.md says: this is a cross-platform kit, components live here, tokens flow through here, do not regenerate <Button>. .cursorrules says the same thing in Cursor's dialect. The 20+ prompts in ai/prompts/ are the ones actually used to extend real kits — add a screen, wire auth, add a Stripe product, scaffold a new page, hook up a server action.

The agent extends. It doesn't replace. Convention beats configuration, and the convention is written down.

[[DIAGRAM: one component source feeding web, iOS, and Android through a shared token graph; AI agent reads CLAUDE.md and .cursorrules to extend the kit, not regenerate it]]

From dev to production in one script

Cross-platform parity doesn't end at "it renders correctly in dev". You still need a domain, DNS, TLS, and a mobile build that survives App Store review. The SaaS Dashboard kit and the Fitness kit both ship with a deploy script that wires all of it:

./scripts/production.sh my-app.example.com

What it does, in order: validates env, builds web, builds the iOS archive, builds the Android AAB, points DNS at the deployment, issues and pins the TLS cert, runs the post-deploy smoke checks. One command. The script is the same one used internally — the same one that keeps saas.otf-kit.dev and fitness-preview.otf-kit.dev alive.

That's the boring half of cross-platform nobody talks about at a hackathon and everybody pays for the week before launch.

What this enables

A team of two shipping an iOS app, an Android app, and a web app from one component tree. A designer updating one token and seeing it on three platforms the same day. An AI agent that asks "where do I add a new screen?" and gets a real answer from CLAUDE.md instead of inventing a fourth codebase. A release that doesn't need a "wait, does this work on Android?" channel in Slack on Friday afternoon.

You can start in two ways:

# Option A — copy-paste CLI, scaffolds into the current directory
npx otf-kit init

# Option B — straight npm install, bring your own scaffold
npm i @otfdashkit/ui @otfdashkit/ui-native @otfdashkit/tokens

Free MIT SDK on npm. ~200 components, three platforms, one API. Paid full-stack kits at $99 each (Everything Bundle $149) ship auth, billing, DB, Stripe, and the production script wired — you own the code. 15 single-page landing templates at $9 each when all you need is a marketing surface.

Closing

Cross-platform parity is one of those problems everyone agrees is real and almost nobody fixes at the level it deserves. The fix isn't a cleverer framework. It's the same component name on every platform, the same token graph feeding it, and a checklist that stops bad builds before they ship. The model layer underneath will keep churning — context windows will grow, prices will drop, agents will get smarter. The render target underneath the model layer won't.

Write <Button> once. Ship it three times. Sleep on launch night.

Bezier AI Launches Conversational Website Builder for Rapid Prototyping

Dave Kurian — Sun, 12 Jul 2026 03:03:12 +0000

Bezier turns one prompt into a working site. That's the headline, and it earns a real look.

For years "AI for web" meant autocomplete inside an editor — Copilot filling the next line, Cursor refactoring a function, Replit nudging you through a cloud IDE. Bezier AI is taking a different swing: type a sentence, get a deployable site. It's a category move worth taking seriously, not because the output is magical, but because the speed-of-concept jump is large enough to change how product teams plan their week. A founder who used to wait two engineering-weeks for a prototype can now test three positioning angles before lunch.

The shift from lines to sentences

Building a webpage used to require HTML, CSS, JavaScript, and the patience to wire a framework together. No-code platforms collapsed some of that — Webflow, Squarespace, Wix — but the user still chose every block, dragged every column, picked every color. Generative AI inverts the contract. The user describes the destination; the model drives.

This is what some builders now call vibe coding — natural language as the primary input for software creation. It doesn't eliminate developers. It shifts their focus to architecture, integrations, and the parts of the system that actually need judgment, while the AI handles the repetitive setup. Bezier AI is positioned squarely in that inversion. The launch frames it as a conversational website builder: where Copilot fills the next function and Cursor edits the file you have open, Bezier generates the file (and the layout, and the responsive breakpoints) from a single description. That's the meaningful distinction, and it's why the launch is positioned against the whole category rather than against any single editor.

[[COMPARE: editor assistants vs full-site generators]]

How to actually use it today

The onboarding is the product. You describe the site you want in a sentence or two and the conversational loop begins. The launch gives a useful canonical example:

Create a modern SaaS landing page with a dark theme,
pricing section, testimonials, animations,
and responsive design.

That single prompt is the input. The output is a functional starting point — hero, sections, basic interactivity — that you can iterate on by talking to it. The model handles layout, design tokens, and the boilerplate wiring. You handle taste, copy, and the parts that need real engineering (auth, payments, data, anything customer-facing).

A practical session runs roughly like this:

Describe the destination in plain English. Be specific about audience, vibe, and the sections you need. Vague prompts get vague sites; "modern SaaS landing page with dark theme, three-tier pricing, and a logo wall" produces something sharper than "make me a website."
Review the first pass as a draft, not a deliverable. Look for the structural decisions — what it chose to put above the fold, what it treated as primary CTA, what it left out. The first render is meant to be argued with.
Iterate by talking. "Make the hero more confident." "Swap the testimonials for a logo wall." "Tighten the pricing to three tiers." Each turn is a small course correction, and the conversational loop is the point — every refinement stays inside the same session rather than becoming a new ticket.
Pull what you can keep. Export the components, the design tokens, the structure. Most prompt-driven builders give you code at the end; treat it as starting material, not a final repo.
Wire the real backend yourself. Auth, payments, data, integrations — that's not what the conversational builder is for. That's where engineering still earns its keep.

[[DIAGRAM: prompt in → first draft → iterate by talking → export → engineer wires the real backend]]

Where Bezier fits in a crowded field

The AI development ecosystem expanded fast, and each tool now owns a different slice.

GitHub Copilot and Cursor are editors. They live inside your file and assist line-by-line. Strong for engineers who already know what they're building.
Replit is a cloud IDE plus AI. The environment and the model are bundled; you stay in the browser.
Lovable, Bolt.new, and v0 popularized prompt-driven interface generation — strong for designers and founders who think in screens, not files.
Bezier AI is targeting the same prompt-driven audience — founders, agencies, marketers, small businesses — but is leaning harder than most into the conversational bit. The pitch is one description, one working site, then a back-and-forth loop to refine it.

Two philosophies, both valid. Editor assistants keep you in code; full-site generators trade code-fidelity for speed-of-concept. Bezier is firmly in the second camp, which is why the launch is framed against the entire category rather than against any one editor.

The honest limits

A prompt-driven builder earns its place on week one and tests your patience by week three. Three things to know before you commit:

Customization has a ceiling. The model is making thousands of small decisions for you. Override enough of them and you've effectively rewritten the site by hand, at which point a real codebase is faster than fighting the generator.
Generated code is a draft. It works. It probably isn't optimized. Bundle size, accessibility, semantic markup, and edge cases in responsive layout are all places you'll want a human eye before it ships to real users.
Reliance on AI accuracy is real. The model doesn't know your brand, your customers, or the regulatory shape of your industry. Treat the output as a fast first draft that still needs review.

For product teams specifically, the math is simple: if you're trying to decide whether to spend two engineer-weeks prototyping an idea, spending an afternoon with a conversational builder first is now the obviously correct move. The risk of being wrong early is much smaller when the early draft takes an hour.

What this enables

The interesting part of Bezier AI isn't the site it produces — it's what the conversational workflow enables for the people using it. A founder can test three positioning angles before lunch. A marketer can ship a campaign page without filing a ticket. A designer can rough out five layout directions and pick one before opening Figma. That speed is the real product; the code is the artifact, and the artifact is disposable in a way the underlying idea is not.

It also surfaces a layer that's easy to miss. When the generation step is fast and conversational, the part that doesn't change becomes more valuable, not less. The churn above this layer — which model, which builder, which prompt style — is going to keep moving. New launches will keep arriving on a monthly cadence; that's the new normal. The durable layer underneath — the components, the conventions, the cross-platform primitives that survive every model swap — is what carries the project from prototype to production.

That's the bet worth making. Use the conversational builder for the speed it gives you in week one. Build on primitives that hold up when the model changes underneath you. The site you ship in an hour should still be the site you're proud of in a year — and that part is yours, not the model's.

Cursor's AI Agent Takes Aim at Anthropic's Claude Cowork

Dave Kurian — Sat, 11 Jul 2026 18:06:01 +0000

Claude Cowork and Cursor's agent are racing for the same seat — your daily workflow

Claude Cowork works like a virtual colleague. It plans tasks, edits files, runs tests, drafts emails, organizes folders — then reports back. Cursor's response is a general-purpose agent built on top of the IDE it already owns. Two genuinely different bets on where autonomy lives, and they are about to compete for the same seat at your desk.

For years the IDE was an autocomplete machine. The bottleneck moved from "can I edit this file" to "can I delegate this workflow," and Cowork and Cursor's agent are racing to own that delegation. Here is the actual thesis: whichever agent you drive today, the part that survives the churn is the repo underneath — its conventions, its tests, its type boundaries. That is the durable layer, and that is where you should spend your energy.

What Claude Cowork actually does

Claude Cowork is the asynchronous one. You give it a goal, it accesses your computer, plans the steps, edits files, runs tests, and reports back. Anthropic launched it as an extension of its reasoning models, and the framing matters: this is not an editor feature, it is a colleague.

The numbers tell the story. Its 200,000-token context window lets it grasp project architecture in ways autocomplete tools rarely match. Early tests show it excels at complex refactoring: one prompt can trigger changes across 15 files, test runs, bug fixes and a clean commit message. It also handles non-coding chores — drafting emails, organizing folders — which is the part that actually changes your day.

If you have ever wished for a junior engineer who could take a ticket and come back with a PR, this is the closest thing shipping today.

What Cursor's agent is shipping

Cursor took a different path. Built as a complete editor — a VS Code fork loaded with context-aware intelligence — it emphasized speed and familiarity first. You index your codebase, chat with your project, and the editor knows what you are looking at.

The feature list as it stands today:

Real-time autocomplete
Inline chat
Composer mode for iterative refinement
Agent mode for multi-file changes with previews before commits

Developers who switched from traditional IDEs often cite the smooth codebase understanding as the biggest draw. Where Cursor lagged was autonomy. A CoworkHow analysis from January placed Claude Cowork at the high-autonomy end of the spectrum for multi-step work, with Cursor sitting in the middle. The new general-purpose agent project is Cursor's attempt to close that gap without giving up its IDE strengths.

[[COMPARE: Claude Cowork vs Cursor's agent]]

Where the autonomy actually lives

The cleanest split is where the autonomy sits in your day. Cowork is a colleague that comes to your machine — kick it off, walk away, come back to a report. Cursor's agent is something that grows inside your editor — you stay in the loop, review previews, commit when the diff looks right.

Both can do multi-file edits. Both can run tests. The real difference is whether your daily flow is "delegate and review later" or "drive and commit now." If you live in your editor and want previews before every commit, Cursor's surface is the fit. If you want a teammate who takes a ticket and returns a PR, Cowork is the closer match.

The competition between them is not really about features. It is about who owns the developer's daily workflow, and that is decided by surface, not by spec sheet.

How to use Claude Cowork today

Cowork is at its best when you give it a concrete goal — not open-ended exploration. Three patterns that work:

Refactor sweep. "Find every place we call the legacy config parser and replace it with v2, then run the test suite." It plans, edits, tests, and hands you a diff with a clean commit message.
Test repair. "The CI suite is red on the auth module. Diagnose, fix, and verify locally." Async mode means you walk away and come back to a report.
Chore work. "Inbox triage, draft replies for the top five threads, file the rest under waiting/." The non-coding tasks are not a gimmick — they buy you hours a week.

The general shape: state the goal in one paragraph, give it access, and let it run. The 200k context window means it can carry the whole project in its head while it works.

How to use Cursor's agent today

Cursor's setup is different because the editor is the surface. The flow:

Open the editor and let it index the repo. Codebase awareness is the whole game.
Use project chat to ask codebase-wide questions — "Where does the rate limiter live?" "What calls into the auth middleware?" You are training yourself to treat the editor as a teammate that has read the code.
Switch to agent mode when you want multi-file changes. Cursor shows you the diff preview before anything is committed — this is the safety net.
Use Composer mode for iterative refinement on a single change. Stay in the editor. Tighten the loop.
Commit only after you have read the preview. The previews are the feature; the agent is the engine.

The CoworkHow analysis placed Cursor in the middle of the autonomy spectrum, which is honest: it is not going to walk off and come back with a PR. It is going to stay next to you and let you drive.

The part that doesn't change when the agent does

[[CONCEPT: the repo is the contract]]

Here is what survives whether you pick Cowork, Cursor's agent, or whatever ships next quarter: the repo is the contract. Conventions, structure, tests, type boundaries — these are what make an agent useful. Without them, both tools stall on a fresh repo and produce the same vague guesses.

A repo that tells the agent what to do — where state lives, how tests run, what "done" means — turns a 15-file refactor into a five-minute job. A repo that doesn't turns the same refactor into a forty-minute cleanup. The agent is the worker; the repo is the brief.

That is the durable layer underneath the tool churn. Build for the agent you have today, and you are ready for the agent that ships next month. Convention beats configuration. Every round.

What this enables

Multi-file edits become routine. Tests run before you review. Commits write themselves. The bottleneck moves from "can I do this" to "do I have the right convention" — a real productivity enable most teams under-invest in.

You do not need to pick a winner to benefit from this round. Pick the agent that fits your surface, put your conventions in writing, and use whichever one is closest when the work arrives. The autonomous coding stack just got real. The repo that survives the agent is the one that was honest about its conventions all along.

Cursor's Ambitious Leap into AI Agents Challenges Anthropic's Claude Cowork

Dave Kurian — Sat, 11 Jul 2026 17:04:39 +0000

A single prompt. Fifteen files rewritten. Tests run, bugs surfaced, a clean commit message waiting in the wings. That is Claude Cowork in action — Anthropic's reasoning-model extension that behaves less like a chatbot and more like a colleague who happens to live on your machine. It is the reason Cursor, until now the most loved AI-native code editor, is reportedly building its own general-purpose agent to compete head-to-head.

This is not a hand-wringing piece. Two real shifts are happening at once: Claude Cowork is climbing the autonomy ladder into multi-step async work, and Cursor is reaching up to meet it. If you build software for a living, you will use both within the year. Here is what each actually does, where they win, and the part of the stack that does not care which agent wrote it.

What makes Cowork exciting

Cowork's pitch is the one Anthropic keeps paying off: bigger context, longer reasoning, and now — physical reach. As an extension of Anthropic's reasoning models, the agent accesses a user's computer, works asynchronously, and reports back. You start a refactor in the morning; by lunch it has edited files, run the test suite, and queued a commit.

The numbers worth holding onto: a 200,000-token context window, and a single prompt that early tests show triggering changes across 15 files including test runs, bug fixes, and a clean commit message. That is not autocomplete with extra steps. That is a junior engineer scoping a PR.

The non-coding chores get less attention but matter as much: drafting emails, organizing folders, the slow admin that eats a senior engineer's afternoon. Cowork handles that too, which is why Anthropic framed it as a colleague, not a coding tool. The interesting bit is not the benchmark, it is the shape of the feedback loop — kick off, walk away, come back to a diff.

That is genuinely exciting. A 200k context window applied to "actually do the work" turns the model from oracle into operator.

What Cursor is shipping in response

Cursor's roots are different. The current editor feels, per the WebProNews report, like a VS Code fork loaded with context-aware intelligence. Users index entire codebases, chat with projects, and lean on Agent mode for multi-file changes with previews before commits. Developers who switched from traditional IDEs often cite the smooth codebase understanding as the biggest draw.

The current feature set gives a sense of the shape Cursor is extending from:

Real-time autocomplete that has been the headline Cursor feature for years
Inline chat on selected code
Composer mode for iterative refinement across files
Agent mode with diff previews before any file is touched

The new general-purpose agent project is the natural next step. Two people familiar with the project, speaking to The Information, describe an effort to push beyond code completion into the broader autonomy Cowork already owns. The sourcing matters: this is not vapor. It is a stated strategic move with engineering effort behind it, and it directly acknowledges the gap — Cursor's autonomy has, until now, lagged behind dedicated agents.

How to actually try both today

Comparison posts often skip the install. Both tools are live and one will take you ten minutes to evaluate.

Cursor — install the editor, point it at a real repo, and turn on the model picker:

# macOS
brew install --cask cursor

# Then inside the app:
# 1. Open a project you've actually shipped
# 2. Cmd+Shift+P -> "Cursor: Index Project"
# 3. Settings -> Models -> pick Claude Sonnet / GPT-4o / your preference
# 4. Toggle into Agent mode for a multi-file refactor
# 5. Watch the diff previews stack before you commit anything

Claude Cowork — available through Anthropic's Claude surfaces with computer access as the headline capability. The single command that converts skeptics is the async refactor:

# Through the Claude desktop client or API
claude "refactor the auth module to use the new session helper, \
  run the test suite, and draft a PR description including the diff summary"

That one prompt — and watching it fan out across 15 files — is the moment Cowork clicks. Then open the same task in Cursor's Agent mode and compare three things: the diff preview cadence, the breadth of files touched, and how much hand-holding each needs to keep the test suite green.

That you can switch between them in a Saturday afternoon is itself the story. The agent war is no longer theoretical.

Where each wins right now

A January CoworkHow analysis placed Claude Cowork at the high-autonomy end of the spectrum for multi-step work. Cursor, the same analysis notes, sat in the middle — full positioning beyond that point was cut from the source I am working from, so do not quote me on a ranking it did not finish making. With that caveat, the shape of the split as of mid-2026 looks like this:

Pick Claude Cowork when: refactors span many files, the task crosses coding and non-coding territory, or you can hand over the keyboard for an hour and want a clean PR back. The async model is the point — fire, walk away, return to a tree you can review.
Pick Cursor when: you live in the editor all day, want low-latency inline completions, need diff previews to feel safe before commits, or your team standardized on a VS Code-derived workflow. The "smooth codebase understanding" the converted developers cite only matters if you are sitting in the editor while it happens.
Use both: Cursor for the typing loop and the tight feedback cycle, Cowork for the long async refactor that does not need your eyes on it. Right now they do not even contend on the same surface — Cursor owns the editor, Cowork owns the agent runtime — which is exactly why Cursor is now building one of its own.

The interesting strategic tension is this: Cursor's bet is that an editor with deep codebase understanding and a pre-existing user base can extend up into the agent layer faster than a reasoning model lab can extend down into the IDE. Cowork has the head start. Cursor has the typing-loop lock-in. Both bets are defensible; only execution will tell.

The part that does not change when the model does

Here is the through-line. Last year the question was "which autocomplete is best." This year it is "which agent hands back the cleanest diff across 15 files." Next year it will be another model, another agent, another context window headline.

The components you ship do not get to churn at that pace. A Button on web needs to still be a Button on iOS and Android next quarter, regardless of which agent wrote it or which context window drafted the spec. The part of the stack that owns the durable contract between your code and your users — the same component, behaving the same, on every platform, with one API — is what survives when the agent underneath gets swapped.

Use Cursor and Cowork together. They are both genuinely good. Then put the durable layer underneath them. That is the only stack the agent wars do not touch.

China's AI Developers Pivot to Homegrown Tools After Claude Code Backdoor Alert

Dave Kurian — Sat, 11 Jul 2026 14:07:47 +0000

A government vulnerability database just named a specific AI coding agent as a security risk and told developers to uninstall it. That hasn't happened before — at least not at this scale, not from China's NVDB, and not against a tool as widely adopted as Claude Code.

On July 11, China's National Vulnerability Database (NVDB), overseen by the Ministry of Industry and Information Technology, published an alert claiming multiple versions of Anthropic's Claude Code contained a security "back door" capable of sending user locations and identities to remote servers without consent. The advisory told local organisations to uninstall the affected versions immediately or upgrade to patched releases. Cai Peng, a Beijing-based cybersecurity partner at Zhong Lun Law Firm, told the South China Morning Post he expected more Chinese companies to abandon foreign AI tools, driven by mounting security concerns and what he called the country's "strategic imperative" for tech self-reliance.

This is the moment to stop treating your AI coding toolchain as a productivity decision and start treating it as a part of your security perimeter.

What the NVDB actually flagged

A "back door" is a strong word, and it's used carefully. In vulnerability-disclosure language it usually means one of three things: a hidden network egress path the user didn't consent to, an undocumented account or credential, or an unauthenticated remote-access mechanism. The NVDB's wording — software that "could send user locations and identities to remote servers without consent" — maps cleanly onto the first definition. That's an architectural claim about the product, not a configuration mistake.

Two details separate this advisory from a routine CVE:

It targets the tool, not a deployment. Most vulnerability reports name a specific version of a library with a patch path. The NVDB is naming a flagship AI coding product and telling users to remove it.
It comes from a state-level database. When MIIT-overseen infrastructure publishes an advisory, the downstream effect on procurement, vendor approval, and corporate policy is structural. Compliance teams and purchasing decisions move within days, not weeks.

For developers inside China, the practical translation is straightforward: if your employer is a state-owned enterprise, a financial institution, or a company handling any data covered by the Cybersecurity Law or the Data Security Law, the Claude Code install is now a compliance question, not a productivity question. The patch path the NVDB offers ("upgrade to patched releases") is contingent on Anthropic shipping a version the agency considers clean, and on that version being reachable inside China's network.

Why this advisory is different from a normal CVE

The coding-agent category has been quietly exempted from most enterprise security reviews because it reads as "developer tooling" — productivity, not infrastructure. The NVDB just ended that exemption.

The interesting question is not whether Claude Code specifically is a back door. It's whether any AI coding agent that runs as a long-lived process on a developer's machine, with network access and access to source code, deserves the same scrutiny you'd give a database or a CI runner. Most teams have never run that audit. The Chinese developers who run it now will set a pattern that propagates.

What the domestic alternatives are offering

The article doesn't name specific Chinese AI coding products, and I'm not going to invent any here. What it does name is the category of advantage Cai Peng expects to drive adoption. The shape is consistent across the domestic space:

Data residency that stays inside mainland networks by default
Model deployments that can be audited under China's algorithm registry
Vendor accountability through entities MIIT can actually reach
Pricing that undercuts dollar-denominated tools once FX and licensing terms are factored in

For a developer evaluating any candidate — domestic or otherwise — the practical audit is the same four steps:

# 1. Confirm the tool's data residency in writing
grep -iE "data residency|data location|境内|domestic" vendor-contract.pdf

# 2. Check whether the model is on the algorithm registry
#    (ask the vendor for their 备案号 / filing number)

# 3. Capture egress — does the agent phone home at runtime?
sudo tcpdump -i any -w agent.pcap 'host <vendor-api-endpoint>'
# Inspect agent.pcap in Wireshark. Anything not in the contract is a finding.

# 4. Test in a sandbox with synthetic code first
git clone 
# Run the agent against it. Watch what it sends.

That last block — actually capturing the agent's network traffic during a normal coding session — is the audit step most teams skip. The NVDB's claim is fundamentally an egress claim. The only way to verify it against any tool is to watch the packets.

A fair comparison, with the gaps named

The article doesn't benchmark specific Chinese AI coding tools against Claude Code on speed or accuracy, so neither will I. A side-by-side on what's actually knowable looks roughly like this:

Dimension	Claude Code (pre-patch)	Domestic Chinese AI coding tools
Regulatory posture in China	Subject of NVDB advisory	Aligned with MIIT and CAC registries
Data residency	Cross-border by default	Mainland-resident by default
Auditability of model	Foreign vendor, foreign jurisdiction	Domestic vendor, algorithm-registry filing
Procurement friction	Rising	Lower

The honest gap: foreign tooling still has a meaningful lead in raw coding-agent capability on certain workloads, and that gap matters when the team is shipping product, not filing compliance reports. Cai Peng's point isn't that domestic tools are better today. It's that the security and sovereignty calculus is now bigger than the capability delta.

For teams that have to move regardless, the play is to start the migration on internal tools and non-customer-facing code, where a regression costs less. Customer-facing production code can wait until the new tool has earned trust on real workloads.

Migrating without breaking Friday

A clean migration is incremental and reversible. Treat it like a refactor, not a procurement event.

Days 1–3: Inventory. List every place the tool is installed: dev laptops, CI runners, internal portals, agent sandboxes. Capture the config so you know what you'll need to replicate in the replacement:

# Export your current agent config
<your-ai-tool> config list > ./pre-migration-config.txt

# Snapshot installed MCP servers, hooks, and slash commands
# (these are usually the things teams forget they depend on)

Days 4–7: Pilot. One team, one non-customer-facing repo, one week. Run the new tool in shadow mode — it suggests, a human reviews and commits. Capture:

Acceptance rate (suggestions kept / suggestions made)
Latency p50 and p95
Network egress volume and destinations
Hallucinated APIs or invented package names

Days 8–14: Compare. Score the pilot against the baseline. If acceptance is below ~70%, the tool isn't ready for broader rollout. If egress goes anywhere unexpected, that's a security finding regardless of who signed the vendor contract.

Days 15–30: Roll out. Default the new tool for new code. Keep the old tool available for break-glass. Migrate existing code only when a human next touches it.

The mistake most teams make is treating this as a procurement decision instead of an engineering one. You're not buying software. You're changing how code gets written. The plan should look like a refactor plan: incremental, reversible, measured.

The durable layer underneath the churn

Here's the part that doesn't change when you swap Claude Code for a domestic alternative, or when Anthropic ships a patched release and the NVDB retracts the advisory: the components your users actually see.

A button is a button. A form is a form. Whether the agent that wrote them was trained in San Francisco or Shenzhen, whether it phones home or doesn't, whether it costs $20 a month or nothing — the rendered output on the user's screen has to look and behave the same on web, iOS, and Android. That's the layer below the model churn, and it's the only layer the team fully owns.

[[CONCEPT: the same component on web, iOS, and Android — the durable layer under the AI tool churn]]

The AI coding tool you pick is a decision you'll revisit every 6–18 months. The component system underneath it is the thing you stop thinking about. Build that layer once, against an API your team controls, and the tool churn stops being a crisis every time a regulator — or a vendor — forces a swap.

Close

The NVDB advisory is the first state-level vulnerability notice aimed squarely at an AI coding agent. It won't be the last, in China or elsewhere. Cai Peng is right that the strategic imperative is real, but the practical imperative — auditing what your tools send and where — is one every team should be running regardless of which side of any border they sit on.

For Chinese developers and the companies that employ them, the shift is accelerating. For everyone else, the lesson is simpler: your AI toolchain is now a part of your security perimeter, and it deserves the same scrutiny you'd give a database or a deployment target.

When the model changes, the durable thing — the component, the API contract, the rendered output — is what carries the team through. Build that once, and the rest is just configuration.

Claude Code's Mid-Year AI Boost: Enhanced Workflows and New Features

Dave Kurian — Sat, 11 Jul 2026 10:05:41 +0000

Claude Code's mid-year update: in-app browser, Sonnet 5, and the durable layer underneath the model churn

An in-app browser shipping inside Claude Code is a quietly big deal. It's the difference between asking an agent "how does X work" and watching it open the actual doc page and read it for you. Same loop, different cost.

The mid-year Claude Code update bundles three things, per the official summary: an in-app browser, the Sonnet 5 model, and a workflow-streamlining pass that adds setup diagnostics and upgraded safety features. All three are framed in the announcement as steps toward "continuous evolution" — a phrase that usually means nothing, except this time it maps onto something real. What it actually means is that the agent keeps getting more capable every release without you having to re-learn the surface area.

What shipped — and which piece actually matters

Let me take each piece seriously before I get to the angle underneath.

The in-app browser is the genuinely impressive half. Most coding agents have two contexts: the codebase in front of them and whatever was in your prompt at session start. The instant they need to verify a one-liner from a deprecation notice on a vendor's site, the loop breaks — you copy the URL, paste it, hand it back. An in-app browser collapses three round-trips into one. For anything that depends on fresh documentation (which is essentially every framework released in the last six months), this is the actual lever.

Sonnet 5 sits underneath the same agent loop. No benchmark numbers were published in the mid-year summary, and I won't fabricate what the article didn't print. The honest framing is "newer weights, same surface area, expect the usual incremental lift in long-context reasoning and code generation." If you were hitting the ceiling on Sonnet 4, try 5 and see what changes; if you weren't, you're fine where you are. The point of a model bump is usually that the existing prompts keep working and the edge cases stop blowing up.

The workflow-streamlining pass is the boring-sounding half that's actually underrated. Setup diagnostics means the agent can self-check its own environment — paths, env vars, auth state, keychain presence — before it tells you "I can't find X." That class of error has wasted every Claude Code user's evening at least once. The diagnostic converts silent failures into loud ones, which is the whole game.

The "enhanced safety features" line, without specifics in the summary, presumably runs the direction every vendor's safety work runs: less willingness to do destructive operations without confirmation, better handling of secrets in repos and commands, clearer refusal reasoning. Both reduce the "did it just do something I can't undo" surface. I'd rather Anthropic publish a concrete changelog of what changed than leave us guessing on vibes.

[[COMPARE: Claude Code without in-app browser vs Claude Code with in-app browser]]

How to actually use this today

The mid-year summary is light on exact commands, so I'll stay general where the article is general and specific where I can be.

The basic loop, for anything that requires checking docs:

# inside a project directory
claude

# a research-shaped prompt — the kind that used to require alt-tabbing
> what changed in the React 19 useActionState API, and where does it differ from the old useFormState?

With the in-app browser, the agent opens the React docs (or the migration guide, the GitHub PR, the Stack Overflow answer) and reads them itself. Without it, you'd be the one feeding it. The win compounds on every task that has a "look it up" step in the middle.

Three categories that benefit disproportionately:

Migrations. Anything where the answer is "the API was renamed and the parameters moved." Claude Code + browser handles this in one turn.
Library spelunking. New CLI flags, new config keys, new SDK methods. The browser pulls the changelog; the model summarizes the deltas.
Debugging obscure framework errors. Paste the error, let the agent search GitHub issues, ship the workaround.

# pick the model for tasks where reasoning matters more than latency
> /model sonnet-5

# run setup diagnostics on first install, and after any major upgrade
> /setup-check

I'd flag that the exact slash command for diagnostics wasn't in the source — check claude --help or /help inside the session for the canonical spelling on your version. The capability is real; the exact string I just wrote might be off by a word, so verify before you script against it.

For Sonnet 5 specifically: if your plan exposes model selection, use it for tasks where reasoning depth matters more than latency — multi-file refactors, ambiguous requirements, anything where you'd otherwise paste three Stack Overflow tabs into the prompt yourself. Drop back to the smaller / faster model for tight loops (rename this function across 80 files, run the formatter, commit) where the agent is more of a glorified macro.

Run setup diagnostics on first install. Treat it like a linter for your environment. Ten seconds of cost, catches the "wrong Node version" or "missing API key" class of mistake that costs forty minutes of your evening. Diagnostics isn't magic; it's a check that fails loudly instead of silently. Loud failures are the whole job.

What's missing from the announcement — and what I'd want before forming a strong opinion

The summary is a feature index, not a benchmark paper. So a few honest gaps:

No published speed or accuracy numbers for Sonnet 5 vs its predecessor
No pricing change called out
No public statement on what the "enhanced safety features" actually check for — secret scanning in-repo? Destructive-command gating? Policy enforcement on outbound HTTP? Both?
No concrete timeline or roadmap beyond the "continuous evolution" framing

If you're going to migrate a workflow onto this, those are the four numbers to ask for before you commit. Vendor marketing beats no data, but neither beats an independent benchmark. Ship against the announcement, not into it.

The part that survives the model

Here's the thing I keep coming back to with every Claude Code / Cursor / Copilot cycle: the agent loop is the exciting layer, and it changes every quarter. Sonnet 5 today, Sonnet 6 six months from now, something else after that. The thing underneath it — the components, the styling primitives, the auth model, the way your UI is actually structured — that's the part with a half-life measured in years.

If you're shipping a product, the agent is your accelerator. The durable surface is the cross-platform component layer it touches: the same Button, Sheet, and Card rendered identically on web, iOS, and Android from a single API surface. When the model swaps, the components don't care. When the agent loop changes shape next quarter — and it will — your UI surface is still the same surface, behaving the same on every device your user opens it on.

That's the layer to invest in. Claude Code — and Sonnet 6 when it lands, and whatever replaces it after — is what builds into it. The agent stack churns. Your components shouldn't.

Ship the part that survives the model. The model is fine.

Why Owning Your AI Agent's Context Is Crucial for Production

Dave Kurian — Sat, 11 Jul 2026 08:05:25 +0000

Cold open

The single biggest enable of 2026 is that AI coding agents actually ship code now. Claude Code, Cursor, the new agentic loops — they don't just autocomplete, they read your repo, plan, and write multi-file diffs across dozens of files. That used to be a recorded demo. Now it's Tuesday. A junior dev with a good agent is producing what a senior dev with a good editor produced in 2023, in roughly half the keystrokes.

Then they hit Cmd+Z on the session and the context dies.

The "demo to prod" gap is the actual blocker

Every agent session builds up two layers of state. The first is the work product — the files it changed, the diff it shipped. That persists. The second is the understanding — which file holds the auth flow, why the billing webhook signs payloads the way it does, why Card is wrapped in forwardRef but Button is not. That second layer is what makes the agent effective inside the session. It is also what evaporates the second the session closes.

So the next session — or the next dev, or the CI bot, or your teammate who clones the repo — starts cold. The agent re-derives every convention from scratch. It invents a new folder layout. It picks a different button variant. It writes a Stripe webhook handler that almost matches the one already in the codebase but doesn't, and you spend 40 minutes diffing them.

I've watched a 30-file change ship in 8 minutes and then watched a teammate's agent spend 25 minutes reverse-engineering what the first agent did so it could extend it without breaking it. That reverse-engineering time is pure tax. It scales with every handoff: dev-to-dev, agent-to-agent, sandbox-to-CI, sandbox-to-prod.

The thesis is one sentence: the agent is a consumer of your context, not the source of truth. Anything you want the agent to do reliably across sessions has to live in the repo, not in the conversation.

What "context" actually means in a repo

When the agent opens your codebase it needs four things, in order:

Stack and entry points. Language, framework, where the app boots, what runs in tests.
Convention. How files are named, where routes live, where DB schemas live, the import order.
Component contracts. Which UI primitives are blessed, what their props are, what variants exist, what to never use.
Tried-and-tested recipes. For recurring tasks — adding a Stripe webhook, writing a migration, scaffolding a screen — what does the team-agreed version look like.

Most agents get (1) from package.json and a glance at the entry file. (2) they infer from neighboring files, badly. (3) they guess, or they pick whatever library they were trained on most loudly. (4) they invent from scratch every single time.

That last one is where the hour disappears. The agent doesn't know your team agreed webhook handlers go in app/api/webhooks/<provider>/route.ts, with signature verification as the first line, with idempotency keys keyed on the provider's event id. So it writes the webhook somewhere else, in a different shape, and now the codebase has two of them.

[[COMPARE: ephemeral agent session vs persistent repo context]]

Sandboxes are great until the session ends

The sandboxed agents — the chat interfaces, the IDE sidebars, the web playgrounds — are brilliant for one-shot generation. They prove the model works. They demo well. They are not where production code lives.

Production code lives in a repo, on a branch, behind a CI run, deployed by a script. None of those four things inherit the agent's conversation. The agent's "understanding" of your codebase is a residue that lives in token activations and gets thrown out with the session.

That is fine for a 10-line proof of concept. It is fatal for a 200-file app that three people ship every day. The fix is not a better agent — those are improving on their own. The fix is moving the understanding out of the conversation and into the repo.

OTF's structured context — what ships in the box

Every paid OTF kit ships with three layers of structured context that survive the session, the handoff, and the model swap:

CLAUDE.md at the repo root — the brief the agent reads first. Stack, conventions, component contracts, the things it must never do.
.cursorrules — Cursor-specific rules the agent picks up automatically on cursor ..
ai/prompts/ — 20+ tested prompt templates for the recurring tasks: add a Stripe webhook, scaffold a screen, write a migration, add a tRPC route, generate a typed client. Each one was run against Claude Code and Cursor and refined until the output matched the kit's conventions without a second pass.

This is the part that doesn't change when the model changes. Claude Code 4, GPT-5, whatever ships next quarter — they all read files. They all respect .cursorrules. They all consume CLAUDE.md. The prompts in ai/prompts/ are plain markdown; the model doesn't care which one runs them.

What a `CLAUDE.md` actually looks like

# Kit: SaaS Dashboard
Stack: TypeScript, Next.js App Router, tRPC, Postgres, Better Auth, Stripe.

## Conventions
- All routes live under `src/app/<route>/page.tsx`. Never in `pages/`.
- DB schema is the source of truth — `drizzle/schema.ts`. Never write raw SQL in a route.
- Server actions live next to the route in `actions.ts`.
- Components: import from `@otfdashkit/ui`, never from a UI library directly.
- Button: always `<Button variant="primary|secondary|ghost">`. Never `<button>`.
- Card: wrap in `forwardRef`. Never render raw `<div>`.

## Do not
- Don't add a state library. Zustand is the only one. It's in `lib/store.ts`.
- Don't write a new auth flow. Better Auth owns it. See `lib/auth.ts`.
- Don't scaffold a webhook by hand. Use `ai/prompts/stripe-webhook.md`.

## Tested recipes
- Add a Stripe webhook: `ai/prompts/stripe-webhook.md`
- Scaffold a dashboard screen: `ai/prompts/dashboard-screen.md`
- Write a typed tRPC procedure: `ai/prompts/trpc-procedure.md`

That file is ~50 lines. It is the difference between an agent that extends your codebase and an agent that re-derives it. A teammate's agent, the CI bot, the dev who joins next month — they all start from the same brief. No reverse-engineering. No 25-minute tax.

Tested prompts are the part that compounds

A CLAUDE.md describes the world. A prompt in ai/prompts/ describes a task. The two together are what makes the agent predictable. The way OTF tests them is mechanical:

# Run a prompt against a fresh checkout and diff the output
otf test-prompt ai/prompts/stripe-webhook.md \
  --against kits/saas-dashboard \
  --model claude-code-4 \
  --expect fixtures/stripe-webhook.expected.diff

# Same prompt, different model — should produce the same shape
otf test-prompt ai/prompts/stripe-webhook.md \
  --against kits/saas-dashboard \
  --model gpt-5 \
  --expect fixtures/stripe-webhook.expected.diff

If the diff matches the expected fixture, the prompt ships. If it doesn't, the prompt gets refined until it does. By the time a kit ships to a customer, every recipe in ai/prompts/ has been run against at least two models and produces a consistent output. That's the "tested" in "tested prompts." It is the reason a teammate's agent, on day one, with no context, ships a webhook that fits the codebase — not one that almost fits.

The handoff that doesn't lose information

When the first agent shipped the billing refactor, it left a CLAUDE.md that said "billing webhook signs payloads with STRIPE_WEBHOOK_SECRET; idempotency is keyed on event.id; the route is app/api/webhooks/stripe/route.ts." When the second agent picked up the next task, it read that file, looked at the route, and continued.

That is not magic. It is the same agent, in a new session, reading the same repo. But because the repo carried the understanding, the second session was as productive as the first. The handoff cost dropped from 25 minutes to 30 seconds — the time to read the file.

[[CONCEPT: the agent is a consumer, the repo is the source of truth]]

What this gets us

The pitch for any new agent this year is the same: "we read your repo, we plan, we ship multi-file diffs." That is table stakes now. The actual production question is: when the model rolls over in three months — and it will — does your team's understanding survive?

If the understanding lived in the session, no. You rewrite every brief, re-test every prompt, re-explain every convention.

If the understanding lived in the repo, yes. You swap the model, you keep CLAUDE.md, you keep .cursorrules, you keep the tested prompts. The agent changes. The code keeps moving. The new hire on day three reads the same CLAUDE.md the senior dev wrote on day one. The CI bot reads the same .cursorrules the IDE reads. The mobile build script reads the same component contracts the web app reads.

That is the durable layer. The agent is the tool. The repo is the product.

[[IMG: clay character at a laptop shipping a multi-file diff, the same component rendered web + iOS + Android on a second monitor, the diff is clean and the agent is mid-keystroke]]

Use the agent. Make the repo hold the context.

Claude Code and Cursor are genuinely good right now. Use them. Run them hard. Ship the multi-file diff in 8 minutes, not 8 hours. That part of 2026 is real.

Then make sure the context that made the agent effective is not sitting in the conversation history. Move it into CLAUDE.md. Move the conventions into .cursorrules. Move the recurring recipes into ai/prompts/. Test each one — run it, diff the output, refine it until it ships first-pass.

That is the part that survives the model swap, the team change, the 2am incident, the new hire on day three. That is what makes the agent a teammate instead of a one-shot generator.

The agent is a consumer of your context. Make the context good, and ship.

Why File-System AI Agents Are the Key to Bridging the Gap to Production

Dave Kurian — Sat, 11 Jul 2026 05:05:00 +0000

File-system agents are the actual enable — and the gap to prod is closing

Cursor and Claude Code are the first coding agents that feel like they live in your repo, not in a sandbox you can't reach into. That is a genuine leap, and it has changed what a solo dev can ship in a weekend.

For the last eighteen months, the pattern that actually worked in practice was: open a file, write a prompt, watch the agent edit the file in place, run the test, iterate. No upload-to-sandbox, no copy-paste-out, no "your code lives on our servers." The agent has the same tools you have. It can Read, Edit, Grep, Bash. It sees your tsconfig.json, your monorepo layout, your package.json scripts. It uses them.

That is the part nobody is talking about loudly enough. The conversation keeps drifting toward "AI can't ship to production" — which is true if you keep the AI on the wrong side of a sandbox. The interesting question is what happens when the agent works inside the repo you will deploy.

[[COMPARE: sandbox export at deploy time vs an owned repo the agent has been editing all along]]

The sandbox tax is real, and it shows up at deploy time

Lovable, Bolt, v0, Rork — pick a sandboxed builder and run a small experiment. Build a working auth flow. Then try to ship it.

What you'll find:

The "code" is a snapshot in their cloud. You can download it, but the conventions are whatever the model invented that afternoon.
The DB schema lives on their Postgres. The auth lives on their identity provider. The components live in their component tree.
The .env keys are scattered across three dashboards. The deploy button is theirs, not yours.
An hour of "shipping to production" becomes three days of disentangling from the sandbox.

This is not a Lovable problem or a Bolt problem. It is a sandbox problem. The moment a model owns the filesystem, you cannot own the deploy. Cursor and Claude Code flipped this. They live inside your filesystem. The code is yours from the first keystroke. The conventions are yours. The deploy is yours. There is no sandbox tax because there is no sandbox.

The README is dead. The convention file is the real product

The single biggest predictor of an AI agent producing useful code is whether your repo tells it the conventions. Not "use TypeScript" — everyone knows that. The actual, specific, drudgery-level conventions:

Forms use zod schemas colocated with the route handler.
Components go in apps/web/components/. The cn() helper lives in lib/cn.ts.
Auth is session-cookie based, server-validated on every API route. Don't write client-side auth checks.
Every list view paginates with cursor-based pagination, not offset.
Never name a component index.tsx.

If those rules live in a comment thread in someone's head, the agent will guess. It will guess wrong. You will burn two hours debugging a <Button> it generated with the wrong variant prop.

The convention file — CLAUDE.md for Claude Code, .cursorrules for Cursor, AGENTS.md for everything else — is the new README. It is the contract between you and the agent.

[[CONCEPT: a single tested convention file at the repo root that every agent reads before it edits]]

A convention file that actually holds up

Here is what a real one looks like. Not a "be a good engineer" prompt — a repo-shaped document:

# Engineering conventions — read first

## Stack
- TypeScript strict, no `any` in new code, no `// @ts-ignore` without a comment.
- Server: Hono routes under `apps/server/src/routes/`. API returns
  `{ data, error: { code, message } | null }` — every route, no exceptions.
- Web: components in `apps/web/components/`. Tokens via `color.bg.canvas`,
  never raw hex.

## Auth
- Session-cookie, server-validated on every route via `requireSession()`.
- Never check auth in a client component.

## Pagination
- Cursor-based, response shape: `{ items, nextCursor }`. Never `offset`.
- Cursor is base64-encoded `{ createdAt, id }`.

## Naming
- No `index.tsx`. No `utils.ts` without a domain prefix. No new top-level
  folders without an entry in this file.

That file goes at the repo root. The agent reads it on every session. When the rule changes, the file changes, and every future session picks it up. Reviewed in PRs like any other code.

How to actually try this today

You do not need a kit. The pattern is portable.

# create the three files the major agents read
touch CLAUDE.md .cursorrules AGENTS.md
git add CLAUDE.md .cursorrules AGENTS.md
git commit -m "add convention files for coding agents"

Then run the agent against the repo. Ask it to add a Stripe webhook. Watch what comes back:

// app/api/webhooks/stripe/route.ts — written by the agent

import { stripe } from "@/lib/stripe";
import { db } from "@/lib/db";
import { verifySession } from "@/lib/auth/session";
import { errorEnvelope } from "@/lib/api/error";

export async function POST(req: Request) {
  const sig = req.headers.get("stripe-signature");
  if (!sig) return Response.json(errorEnvelope("MISSING_SIG"), { status: 400 });

  const event = stripe.webhooks.constructEvent(
    await req.text(),
    sig,
    process.env.STRIPE_WEBHOOK_SECRET!,
  );

  switch (event.type) {
    case "invoice.payment_failed":
      await db.subscription.update({
        where: { stripeCustomerId: event.data.object.customer as string },
        data: { status: "past_due" },
      });
      break;
  }

  return Response.json({ data: { received: true }, error: null });
}

That is convention-shaped code. It knew the error envelope, the Response.json shape, the db import path, the rule about session validation on every route. It did not invent a new pattern. It matched what was already there. That is the whole game.

What OTF ships on top of the pattern

If you do not want to write that convention file by hand, every kit we ship includes a tested one. Not generic — repo-shaped, covering the same six sections above, tuned for the kit you bought. The prompt library — twenty-plus files in ai/prompts/ — handles the common extension jobs: add a Stripe webhook, scaffold a new API route, generate a settings page, wire a new OAuth provider. Each one assumes the convention file is true.

// ai/prompts/stripe-webhook.md — first three lines, the rest is the prompt
// "Read app/api/webhooks/ for existing patterns. Use the error envelope
//  from lib/api/error.ts. Match the auth check from requireSession()."
// followed by the prompt body the agent consumes.

Run an agent against a kit and it reads the convention file first, then the relevant prompt, then edits. The output is consistent with what is already in the repo, not whatever the model invented at 3am. That ordering — convention file → task prompt → edit — is the difference between an agent that extends your codebase and one that rewrites it.

The deploy story: shipping without rewriting

Owning the repo is half the equation. Owning the deploy is the other half. The convention file gets you code you trust. A one-line deploy script gets you code you actually serve.

# from a kit: wire a custom domain + DNS + TLS + ship
pnpm ship --domain app.example.com

# or just the build-and-push, no domain
pnpm ship --push-only

That single command runs the design checklist (a 24-item script that blocks the build if a component is missing a label, an icon button is missing an accessible name, or a color token is hardcoded), runs tsc --noEmit, runs the tests, then wires the deploy. For mobile it kicks off the iOS/Android build with the right bundle ids and the keystore you already configured.

The agent wrote the code against the convention file. The deploy script ships it. Nothing in between is a sandbox you have to escape from.

What this gets us in practice

Three concrete scenarios where the loop closes:

Solo dev shipping a SaaS this weekend. Convention file in the repo from day one. Agent writes features against your conventions. pnpm ship puts it on a domain. Friday night, the product is live.
Team handing a junior engineer a feature. The convention file is the onboarding doc. The agent is the pair. The junior ships a settings page that matches every other settings page on day one, because the file told the agent how to write it.
Migrating from a sandbox builder. Download the code, drop it in a kit, write a convention file that captures the rules you wish it had followed, run the agent to bring the existing components up to the kit's contract. One PR at a time.

The pattern is not "AI replaces the engineer." The pattern is "the agent edits the same repo the engineer edits, against the same rules, shipped by the same script." Every layer — the filesystem, the convention file, the prompt library, the deploy — is something you own. Nothing lives in someone else's cloud waiting to be migrated away from.

The model will change again next quarter. The sandboxed builders will get better, or worse, or get acquired. Cursor will fork, Claude Code will fork, something new will appear. The parts that do not change are: the repo is yours, the conventions are tested, the deploy is one script, and the component is the same on web, iOS, and Android because you wrote it once. That is the durable layer. Build the rest on top of it.

Unify Your UI/UX Across Platforms with OTF's Component System

Dave Kurian — Sat, 11 Jul 2026 04:05:20 +0000

The button shipped on iOS at 9:47pm. By 9:51pm, three engineers had filed issues. Web had it grey. Android had it floating with the wrong radius. iOS — the one that looked right at first — had a press state that stuck after release.

Three teams, three button components, three regressions.

This is what platform drift actually costs. Not the abstract "inconsistent UX" line from a design system pitch deck — actual man-hours: the same button redrawn three times, themed three times, accessibility-checked three times, and still wrong in three different ways on the same Tuesday night.

The naive fix is "one codebase to rule them all" — write once, run anywhere. Most attempts at that die on contact with platform reality. iOS wants one gesture model. Web wants another. Native wants a third. Each platform has its own accessibility tree, its own focus model, its own idiomatic motion. A component that pretends those don't exist looks fine in a demo and breaks the first time a screen reader user encounters it.

So this isn't a "unified codebase" pitch. It's a tighter claim: the same component name, the same props, the same visual output — on every platform — without papering over the platform reality that makes each one usable. When the abstraction respects the platform, you stop redrawing. When it doesn't, you get the Tuesday night.

The drift problem, named precisely

"Cross-platform" usually splits into two:

One runtime, two skins. A web app shipped as a wrapped WebView. Same DOM, same CSS, same bugs in two app stores.
Two runtimes, two skins. A native iOS app and a native Android app, plus a React web frontend. This is the common case, and the cost here is the original sin: every component is rebuilt three times.

The first case is cheap on day one and punishing on day ninety — WebView keyboards, WebView accessibility, WebView pull-to-refresh that never feels right. The second is the one most teams actually live in, and the one that quietly bleeds the most hours.

Three primitives are usually duplicated:

Component	What's rebuilt	Cost
Atoms (Button, Input, Card)	Visual + interaction + a11y	Multiplied across every screen
Forms (validation, errors)	Submission flows per platform	Tests aren't portable
Navigation (stack, tab)	Idioms differ per platform	The hardest one to fake

The days lost aren't glamorous. They're the Tuesday-night pixel-fix days, repeated across every release.

What "the same component" actually has to mean

The cheap version of "unified" is "it renders something." A button-shaped rectangle that submits the form. That's the floor, not the goal.

The version that survives production has three properties, and all three have to hold at the same import:

Same name, same props. A Button accepts variant, size, onPress (or onClick on web), disabled. Same names, same types, same semantic values across runtimes.
Same pixel output, given the same tokens. Tap the design tool, copy the hex. The button on web, iOS, and Android renders that exact colour, at that exact radius, at that exact type scale.
Same a11y contract. A button is a button to VoiceOver, NVDA, and TalkBack. Role, label, focus ring, and disabled semantics — identical, not "close enough".

Most cross-platform libraries clear one of those. Almost none clear all three at the same component, same import.

Why "write once, run anywhere" usually means broken everywhere

The pattern that fails is the one that hides the platform. A View that "just works" on web and mobile has to make choices about touch vs mouse, flexbox vs Yoga, focus-visible vs focus-on-press. The moment the abstraction makes those choices for you, your designer files a ticket: "the web button has the wrong hover state." Your QA engineer files another: "Android focus order is reversed." Your accessibility lead files a third.

The right rule is respect the platform at the boundary, then collapse everything above it. The boundary is where the buttons actually live — a real DOM <button> on web, a real native view on mobile. Above the boundary, your team writes once.

[[DIAGRAM: a screen built from platform-respecting primitives — the same component name and props render on a real DOM in the web runtime, a real native UIButton on iOS, and a real clickable focusable view on Android; only the bottom layer adapts to the platform, everything above it is shared]]

// web — same import path a screen already uses
import { Button, Card, Stack } from '@otfdashkit/ui'

export function PricingRow({ plan }: { plan: Plan }) {
  return (
    <Card>
      <Stack gap="md">
        <h3>{plan.name}</h3>
        <Button variant="primary" size="lg" onClick={() => subscribe(plan)}>
          Choose {plan.name}
        </Button>
      </Stack>
    </Card>
  )
}

// native — same component name, same props, same visual output
import { Button, Card, Stack } from '@otfdashkit/ui-native'

export function PricingRow({ plan }: { plan: Plan }) {
  return (
    <Card>
      <Stack gap="md">
        <Text style={h3}>{plan.name}</Text>
        <Button variant="primary" size="lg" onPress={() => subscribe(plan)}>
          Choose {plan.name}
        </Button>
      </Stack>
    </Card>
  )
}

No translation layer. No prop-mapping utility. No "but on mobile it has to be..." comment in the PR. The screen file is identical except for the runtime-appropriate import and the platform-native event name. Convention beats configuration.

The token layer that holds it together

Pixel parity across platforms dies the moment each runtime defines its own colours, spacing, and type scale in three different files. The fix is a single token source, fan-out per runtime, and a guard script that fails the build when a runtime drifts.

// tokens — runtime-agnostic, the only source of truth
export const tokens = {
  color: {
    primary: { 500: '#5B6CFF', 600: '#4854E0' },
    surface: { 0: '#FFFFFF', 50: '#F7F8FA' },
  },
  radius: { sm: 6, md: 10, lg: 16 },
  space: { xs: 4, sm: 8, md: 16, lg: 24 },
} as const

# one script re-emits the token files per runtime
$ pnpm tokens:sync
  → apps/web/tokens.css        (CSS variables for the web runtime)
  → apps/mobile/tokens.ts      (typed consts for the native runtimes)
  → apps/landing/tokens.json   (design-tool export)

The cold practical detail: when a designer bumps the primary to a new brand colour, you change one file and the three runtimes pick it up in the same commit. When someone adds a new colour in one runtime and forgets the others, the guard script catches it before it ships. Configuration beats three drift-prone duplications.

The accessibility contract that doesn't ship as a footnote

The single biggest reason "unified" usually means "broken for screen reader users" is that the abstraction hides the accessibility tree. Web exposes it. iOS exposes it. Android exposes it. An abstraction that pretends to unify all three usually maps to one and ignores the other two.

The contract that holds in production:

Role maps correctly per runtime. A Button is role="button" on web, a real native button on iOS, a clickable view with proper accessibility state on Android — but in all three cases, assistive tech reads it as a button.
Focus order is the source order. No tabIndex games on web, no accessibilityElements reshuffling on iOS that differ from the visual order.
Disabled disables the right things. Inert pointer events on web, accessibilityState={{ disabled: true }} on native. Not just a faded look.

This is enforceable, not aspirational. A 24-item checklist runs before any kit ships:

$ pnpm kit:check
  ✓ every Button has an accessible name
  ✓ focus order matches source order on web
  ✓ disabled state propagates to a11y tree on all three runtimes
  ✗ Tab order drift in PricingTable.tsx (web) — fix before shipping

The last line is the point. The check runs in CI. A screen ships only when the contract holds across all three runtimes.

Why AI coding agents port screens instead of rewriting them

Most of the Tuesday-night regressions don't start in code — they start in a copy-paste from a snippet an AI coding agent wrote six months ago. The agent didn't know the company had a Button component. So it wrote a styled <div> with an onClick. Now there are three of those, in three files, across two repos.

The fix isn't "tell the AI to use the design system." That's a paragraph of guidance nobody reads. The fix is that the kit ships a recognised set of conventions the agent can extend without guessing:

<!-- CLAUDE.md / .cursorrules — the same hint, two agents -->

The codebase exposes a cross-platform component kit. Components have
identical names and props across web (`@otfdashkit/ui`) and native
(`@otfdashkit/ui-native`). When porting a screen, change the runtime-
appropriate import and the event handler name (`onClick` → `onPress`).
Do not regenerate an existing component as a styled primitive —
extend the existing one. Design tokens are the single source of truth
in `/tokens`; never hard-code colours or spacing in a screen.

This is the part that doesn't burn on a Tuesday night. A junior dev, a contractor, or a coding agent picks up the kit and inherits the conventions. The "use this, not that" decision is encoded once, in a file the agent reads, instead of being repeated in code review forever.

What this gets you on a Tuesday night

The version of this story you actually want:

It's 9:47pm. The button ships on all three runtimes. Web has it. iOS has it. Android has it. Press state releases on touch-up. The web focus ring matches the design. The accessibility tree is intact on every platform because the contract is checked in CI, not in QA.

Total drift: zero. Tuesday night: free.

The way to get there isn't a "unified runtime" pitch. It's a component kit where the name, the props, the pixels, and the a11y contract all hold across the three runtimes — and the convention is loud enough that everyone who touches the codebase (human or agent) extends instead of regenerates. That's the durable layer. The platforms underneath keep changing — that's their job. The interface your team writes against doesn't.

DEV Community: Dave Kurian

Why 'Write Once, Run Everywhere' Often Falls Short in Practice

The three failure modes of cross-platform

The contract that actually works

What this looks like in code

Design tokens flip one theme across every platform

Where AI coding agents make this worse (and how to fix it)

What this enables

The lie, restated

SpaceX Buys Cursor for $60B to Build the World's Most Useful AI Models

The receipt

The thing that already started

How to actually use Cursor today

What the 20–30× signal means for builders

The part that doesn't move when the model does

What this gets us

What to watch

Claude Code's Auto Mode Now Default on Major Cloud Platforms

What auto mode actually is

The inversion: from opt-in to default-on

Three things to do this week

What this gets us — and what doesn't change

Closing

Achieve True Cross-Platform Consistency with OTF's Unified Component System

The parity tax, line by line

One component, three platforms, one API

Tokens are the source of truth

The 24-item gate before anything ships

AI agents extend, they don't regenerate

From dev to production in one script

What this enables

Closing

Bezier AI Launches Conversational Website Builder for Rapid Prototyping

Cursor's AI Agent Takes Aim at Anthropic's Claude Cowork

Claude Cowork and Cursor's agent are racing for the same seat — your daily workflow

What Claude Cowork actually does

What Cursor's agent is shipping

Where the autonomy actually lives

How to use Claude Cowork today

How to use Cursor's agent today

The part that doesn't change when the agent does

What this enables

Cursor's Ambitious Leap into AI Agents Challenges Anthropic's Claude Cowork

What makes Cowork exciting

What Cursor is shipping in response

How to actually try both today

Where each wins right now

The part that does not change when the model does

China's AI Developers Pivot to Homegrown Tools After Claude Code Backdoor Alert

What the NVDB actually flagged

Why this advisory is different from a normal CVE

What the domestic alternatives are offering

A fair comparison, with the gaps named

Migrating without breaking Friday

The durable layer underneath the churn

Close

Claude Code's Mid-Year AI Boost: Enhanced Workflows and New Features

Claude Code's mid-year update: in-app browser, Sonnet 5, and the durable layer underneath the model churn

What shipped — and which piece actually matters

How to actually use this today

What's missing from the announcement — and what I'd want before forming a strong opinion

The part that survives the model

Why Owning Your AI Agent's Context Is Crucial for Production

Cold open

The "demo to prod" gap is the actual blocker

What "context" actually means in a repo

Sandboxes are great until the session ends

OTF's structured context — what ships in the box

What a CLAUDE.md actually looks like

Tested prompts are the part that compounds

The handoff that doesn't lose information

What this gets us

Use the agent. Make the repo hold the context.

Why File-System AI Agents Are the Key to Bridging the Gap to Production

File-system agents are the actual enable — and the gap to prod is closing

The sandbox tax is real, and it shows up at deploy time

The README is dead. The convention file is the real product

A convention file that actually holds up

How to actually try this today

What OTF ships on top of the pattern

What a `CLAUDE.md` actually looks like