Teaching Claude to Code
This is a story about how Claude Code and I worked on a feature for work. And how I was still smarter than Claude.
The feature
We have a note editor on our web-app. (I will use simplified graphical examples, not the real ones.) On the home screen the editor is small, cause there are other things fighting for the limited screen space. But, obviously, you might want to write a really long note and not scroll back and forth between the different parts of your text. So, we invented... the expand button.
You click the button and you get a modal window with a bigger editor in it. A bit of a zen mode but also a dedicated space to write.
The prototype
During the prototyping phase I tend to think about getting the feature out as an experiment. We don't know yet if it's valuable, we don't know yet how people might want to use it actually. It's all a sack of assumptions.
Claude came up with this architecture, where the editor on the home page has its own local state (text, mostly). And the expanded editor modal has its own. When you click to expand, we shuffle the data from one local state to another through some init function. And when you close the expanded view, we shuffle the data back to the home page.
This worked and was easy for Claude to just run around and copy: a bunch of mechanical functions mutating local ratom (for my Clojure people).
The problem
After the prototype landed I played with it and realized we can do better. The prototype was a bit buggy. The text wasn't always synchronized correctly (having auto-save made things 100x more complex), the cursor placement was lost. You didn't get the feeling that you were in the same editor but in a bigger window, although the UI said you were.
I was feeding Claude more and more demands, requirements, bugs. The number of WTFs/second was growing fast.
Claude was really trying. Adding more and more variables to track stuff. Adding more and more conditions and logic piled on top of other logic. Layers of complexity. And still the experience from using the feature was... meh.
The solution
"Let's take a step back", I typed into the prompt.
The whole reason we're having this problem and this scary-looking, unmaintainable mess of a code is because we have two local states, while what we actually want is two views (and functionality) over the same state.
Claude did a facepalm (I didn't see it, but I could feel it).
Of course. If you just put the state in the central app-db (yes, it's Re-frame), the editors become views that subscribe to the same slices of data. They mutate the same data. It becomes very straightforward. No logic, no extra variables to track everything.
The lesson
Twenty years (actually, more now) of experience is not about how fast I can type or how many standard library functions I know by heart. It's not about whether I have a portrait of Torvalds on my desk or whether I am friends with Tsoding (call me!).
It's about: "I've seen this shit before. I know how not to do things".
Someday code generators might get to the same level. But this post is not about that.