Imagine you're a hardware architect trying to answer questions like "if we add more memory bandwidth to this chip, how much faster will Llama run?" To answer that, you need a performance model — a symbolic simulator that estimates how long an ML workload will take on hypothetical hardware. These models are essential for designing next-gen accelerators, but they're notoriously painful to maintain. Every time a new model architecture drops (mixture-of-experts, new attention variants, novel parallelism schemes), the assumptions baked into your framework break, and engineers spend weeks refactoring.

The authors of SMART make a provocative argument: stop maintaining the code. Maintain the design doc, and let AI regenerate the code.

Their reasoning is that AI coding agents have crossed a threshold. Regenerating an entire performance-modeling library from a well-written specification is now cheaper than paying down the accumulated tech debt of incremental patches. Instead of engineers wrestling with a decade of layered abstractions, they update a natural-language design document describing what the tool should do, and an AI agent produces the implementation.

Key ideas in the paper:

• Design docs as the source of truth. The human-readable spec becomes the canonical artifact; code is regenerated output, not hand-maintained input.
• Symbolic modeling remains rigorous. This isn't "ask an LLM to guess runtime." SMART still produces analytical performance models with real math — the AI is just the compiler from spec to implementation.
• Rapid iteration on new architectures. When a new model like DeepSeek's MoE variant appears, updating the doc and regenerating is faster than patching.
• An "AI-native" workflow. The tool is designed from the start assuming an agent will read, modify, and regenerate it — rather than retrofitting AI onto a human-authored codebase.

Why is this interesting beyond ML performance modeling? It's a concrete case study in a broader shift: when generation becomes cheap and reliable, the economics of software maintenance invert. Codebases that used to accrue technical debt become disposable artifacts. The valuable, durable thing is the specification. If this pattern holds, we may see whole classes of internal tooling — simulators, DSLs, glue code — move to this "spec-first, regenerate on demand" model.

The obvious tensions: how do you version and test regenerated code? How do you trust that two regenerations produce equivalent behavior? The paper is a proof-of-concept in a domain where correctness is checkable against ground-truth hardware measurements, which makes it a good testbed for the idea.