# My craft was never my code > A web developer's reflection on two decades of tooling, from hand-tuned HTML to AI-assisted development, and why the craft was never the code itself. - Source: https://verygood.ventures/blog/my-craft-was-never-my-code/ - Published: 2026-09-10 - Author: Kyle Crouse - Tags: AI, AI Tooling, Best Practices, Very Good Engineering --- I built [ge.com](https://ge.com) in the early 2000s, and I was a perfectionist about how it was written, maybe a little too much of one. I cared whether a heading should be an h2 or an h3, and what a blind user's [screen reader](/blog/accessibility-wcag-compliance-skill/) would make of the difference. I cared whether a list of products was a real ul or a table I'd talked myself into because the design wanted a grid the markup wouldn't give me honestly. I cared about dragging layout out of tables and into CSS, back when that was still an argument you could lose. And I cared about file size in kilobytes, because every kilobyte was time somebody spent waiting, and I wanted the page there before they'd finished asking for it. The code had a second life beyond the page, and I minded that one just as much. Every file was something another person would open someday and have to live inside, so I kept it livable. I named things so they explained themselves. I kept the cascade coherent so a selector wouldn't go off three files away when someone added a rule six months later. I thought about the cost of owning the thing, because a page ships once but a codebase gets inherited, over and over, by people who never met you and have every reason to resent you. The code wasn't plumbing. It was something I'd made, and I wanted it to be good. Then the tooling came. Bootstrap, then React, then webpack and Babel and Sass and PostCSS and styled-components and Tailwind, and I took all of it gladly, because it made the work faster and the results better. The tools gave me repeatable workflows, deployments I could trust, [design systems](/blog/where-does-your-design-system-end-and-the-llm-begin/) that kept a hundred screens in line, whole applications where there used to be documents, for better and worse. What changed wasn't how much I cared. It was how far down the caring could reach. The output went opaque. A button I wrote in twelve lines of JSX came out the far end as a hundred lines of markup and a framework that loaded before it could render a hover state. I could read that output, but I could no longer groom it. So the rigor moved up a floor, to the source. The JSX and the Sass and the components were still mine to name and shape, and that was where the care went. I made my peace with the compiled result the way you make peace with a translation. Around then I also gave up trying to hold the whole stack in my head. There were too many layers and they turned over too fast, and what I needed from a tool was not a theory of how it worked but an honest account of what it gave me and what it cost. Whether the bundler was Babel or SWC was not my problem. How much JavaScript reached someone's phone was. Then AI happened, and I stopped caring about code. The same thing happened again, one floor higher. This time the source went opaque too. I don't write the code now, the model does, and what it hands back is generated all the way down, source and output alike, opaque in a way I've stopped needing to open. The part a human still reads and frets over isn't code at all. It's the design and the spec, the description of what the thing is and how it should behave and feel and hold up under a thumb. That's the artifact I groom now. The judgment I used to spend on selectors and semantics, I still spend. If it comes back heavy, I ask for it lighter. If it's slow, I ask for it faster. If it's inaccessible or wrong, it goes back, because the code is disposable and the only question left is whether what it produces is what I wanted. There's something strange about holding firm opinions on an artifact you no longer make, but the opinions were always the part that mattered. I was minding two things all along, the experience and the code beneath it. Because the code was the part I built by hand, I spent years mistaking it for the craft, when it was only ever the cost of the craft. It writes itself now, and I get to spend my whole budget on the experience. Twice now the floor has moved up under me, and both times the thing that survived the move was the standard I held the work to. That's the part worth protecting on a team, and the part hiring was never built to find. A job posting asks for years in a framework and a list of things shipped, which is hiring for output, and output is what just got cheap. What's left to hire for is taste, and the knack for carrying it up a floor every time the floor moves. You can teach someone to prompt in an afternoon. Teaching them to look at what comes back and know the markup is lying about its structure, or that someone on a bad connection will give up before it paints, takes years of having built the thing by hand. I got mine that way. I don't know what replaces that apprenticeship for the people coming up now, and I'd rather say so than pretend I do. What I'm sure of is that the budget moved. It used to go on making the thing. Now it goes on deciding whether the thing is any good, and a team that plans for that gets faster. One that doesn't just gets more output nobody's checking.