---
title: "Comment by Kartik N V J K on \"Design as Code: The Engineering Problems Nobody Warned Me About\" | Hashnode"
description: "The move from regex replace to AST editing keyed off a stable node id is the right call, and the \"Submit\" example shows why: text matching has no way to tell a"
url: "https://hashnode.com/posts/design-as-code-the-engineering-problems-nobody-warned-me-about/6a4e205836b5edc04dfdf77f/comment/6a4fd87bb199c39e17801e70"
---

[Discussion](https://hashnode.com/posts/design-as-code-the-engineering-problems-nobody-warned-me-about/6a4e205836b5edc04dfdf77f)

Comment [Design as Code: The Engineering Problems Nobody Warned Me About](https://hashnode.com/posts/design-as-code-the-engineering-problems-nobody-warned-me-about/6a4e205836b5edc04dfdf77f)

[Kartik N V J K](https://hashnode.com/@kartik-nvj)

[Jul 9](https://hashnode.com/posts/design-as-code-the-engineering-problems-nobody-warned-me-about/6a4e205836b5edc04dfdf77f/comment/6a4fd87bb199c39e17801e70)

The move from regex replace to AST editing keyed off a stable node id is the right call, and the "Submit" example shows why: text matching has no way to tell a button from a test assertion or a prop name. The broader point about pushing pieces from probabilistic to deterministic wherever a wrong edit is expensive is one I wish more agent tooling took seriously. On the compositional drift across pages, that feels like exactly the thing you would want a check on at generation time, comparing spacing and structure against your component definitions rather than hoping the tokens hold.