Engineering
AI is a great reverse-engineer. That's the trap.
An AI read Motion Canvas's compiled bundle and Excalidraw's renderer for me and handed back the parts that mattered. That was useful enough to keep doing — and comfortable enough to lead me into a month building a tool I should have just adopted.
Two of the most useful pieces of VizLearn's rendering layer were built by an AI reading code I never read myself. The trick behind the hand-drawn rounded corners came out of Excalidraw's renderer; a player I spent a month on and then threw away came out of Motion Canvas's compiled bundle. Both times I described what I was after, pointed an AI at someone else's source, and it handed back the part that mattered.
That workflow is worth being honest about, because it is at once one of the most useful things AI does for me and the exact place it nearly cost me a month — and those two turned out to be the same property of the tool, seen from opposite sides.
What it's genuinely great at
Start with the win, because it's real and I'd do it again tomorrow.
The Excalidraw case is the clean one. I needed to know how Excalidraw makes a rounded corner look right at every size, and the answer was buried in a renderer I had no desire to read end to end. So I described the symptom — my corners look terrible, here's the file, find the part that fixes this — and the AI came back with the actual trick: build the whole outline as one continuous path, tell roughjs preserveVertices, and scale the corner radius and the roughness by two specific constants. The constants were exact. I ported a dozen lines, credited them, and moved on the same afternoon.
That is genuinely useful, and it's worth naming precisely. The thing AI is brilliant at here isn't writing code. It's reading code you would never sit down and read: a minified bundle with no whitespace and three-letter variable names, someone else's renderer with five years of edge cases compiled into it, an artifact that was never meant for human eyes at all. You hand it the haystack and a description of the needle, and it hands back the twelve load-bearing lines. Reverse-engineering used to be a day of squinting at a debugger. Now it's a paragraph and a short wait.
What it cost me
Now the other case, which looks identical and went very differently.
When Motion Canvas wouldn't give me the playhead control I wanted, I had the AI read its source and bundle the same way, and I wrote a from-scratch player off what it surfaced. The reverse-engineering succeeded completely. That's the problem.
Because understanding Motion Canvas's internals was suddenly cheap, I kept going. The player needed a timeline, so I built one. The timeline needed an interpreter to turn the generator syntax into clips, so I built that too — and every time I got stuck on how their version did something, I sent the AI back into the source instead of stopping to ask why I was in there at all. Six weeks later I was sitting on 679 lines of my own animation engine, a second and worse Motion Canvas, and the only reason the detour ran that long is that no single step of it ever hurt enough to make me stop.
That's the part I want to underline. In the old world, reverse-engineering a framework's bundle by hand to reimplement its player is miserable, and the misery is information. Somewhere around hour six of reading minified source you look up and think: this is insane, why am I rebuilding the tool instead of using it? The pain is a smoke alarm. It is the thing that makes you question whether you're on the right path at all.
AI disconnects the smoke alarm. Every step that should have been painful enough to make me reconsider was instead a pleasant ten-minute exchange that produced working code. I sailed straight past the warning that the friction was supposed to give me, because the friction was gone. The same tool that made building the wrong thing possible also made it comfortable, and comfortable is the more dangerous of the two.
The question it can't answer for you
So this is the note I keep for myself now, and it isn't "don't use AI to read code." That would be giving up a useful tool out of superstition.
It's that AI collapses the cost of can I build this? to nearly zero and leaves the cost of should I build this? exactly where it was. Those two used to be coupled. When building a thing was hard, the difficulty itself forced the second question — you wouldn't sink a week into a player unless you were fairly sure you needed one. Now you can have the player by dinner, so nothing forces the question, and I have to ask it on purpose.
I treat that now as a separate, deliberate step. Before I let an AI go read a bundle and hand me the missing piece, I make myself answer the question the cheapness is hiding: not can this be built — the answer is almost always yes now — but should this exist, or am I about to reimplement something I ought to just adopt? For the player, the honest answer was always "you picked the wrong tool, go get the right one." The AI could not tell me that. It can read any code in the world and it has no opinion whatsoever on whether the code should be written.
Standing on shoulders, with a research assistant
None of this changes the credit I owe. I ported Excalidraw's constants; they are Excalidraw's, named as such in the source and on the licenses page, and it makes no difference that an AI was the one who found them instead of my own eyes at 2am. "I learned this from them" carries the same obligation whether I did the reading or delegated it.
What it changes is how I think about the method, because the method is what taught me the trap. The reading was real. The constants are right. The player worked. I just had a research assistant do all of it — and a research assistant who never gets tired, never gets bored, and never mutters "this is taking forever, are you sure about this?" is exactly the assistant who will help you build the wrong thing beautifully, all the way to working, before it occurs to you to ask whether you should have built it at all.