
AI & Innovation
AI writes more code than anyone can retype. What still builds understanding is explaining it, testing it and owning what ships.

If there’s one thing that hasn’t changed from the first day I started writing code until today, it’s that not knowing where to start is incredibly intimidating. I remember the panic of learning HTML and having no idea how to get my divs to go where I wanted them to go. The concept of a grid system made sense to me, but the execution eluded me for days.
My relief came with the greatest realization of my young coding life: there is working code everywhere. Find it, copy it, see how it works, and you’re golden. I became a “view source” and “inspect element” maestro overnight, learning structures and logic by reading other people’s successful work. For a while that was all I needed. But as my skills improved, I found I couldn’t write code from scratch as elegantly as I wanted to. So I started a new system: instead of copying other people’s code, I type it out.
As a young copy boy at Time magazine, Hunter S. Thompson typed out parts of The Great Gatsby and A Farewell to Arms, to better understand what it feels like to write a great book. You can’t feel an author’s turns in logic and storytelling from reading alone. You have to feel what it’s like to create the thing. I’ve found coding works the same way.
Whenever I worked through a plugin someone else wrote, or built a small site on an unfamiliar framework, I put the source on one screen and my editor on the other and typed the whole thing. It’s amazing how deeply I understood the logic and the unfamiliar syntax once I had to write it out. My mind had to narrate: here’s where they split the string, here’s where they parse it, and whoa, I didn’t know you could do that.
That is my own experience. We found no study that tests whether retyping code teaches more than reading it, so treat it as a habit that worked for me, not a proven method.
Not really. An assistant can produce in a minute more code than anyone wants to retype, and nobody is going to type out a whole feature. In our view, that is not the real problem. The real problem is the part of typing that mattered: it forced me to slow down and think about every line.
AI removes that friction, and the code often runs, which is the trap. Running code and understood code are different things. Our own take on AI in QA comes down to the same point: the faster code gets written, the more the checking matters.
There is not much yet, and what exists is small. In a January 2026 trial, Anthropic asked 52 mostly junior engineers to build two features with a Python library they did not know. The group using an AI assistant averaged 50% on a follow-up quiz, against 67% for the group that coded by hand. The developers who kept their learning asked the assistant conceptual questions, or asked for code together with an explanation. The authors note the sample was small, the quiz came right after the task, and it was their own assistant, so read it as a signal, not a verdict.
Developers are wary of what AI hands them. In the Stack Overflow 2025 Developer Survey, 66% of respondents named “AI solutions that are almost right, but not quite” as a frustration, and more developers said they distrust the accuracy of AI tools (46%) than trust it (33%).
Our view is that the skill is no longer typing the code. It is understanding it. These steps are our practice, not research findings:
By what it does in production, not by how it got written. The question moves from “did I type it?” to “can I explain it, test it and defend it?” That is where AI in a real workflow pays off or falls apart. The 2025 DORA report, based on nearly 5,000 survey responses, found that AI adoption now goes with faster delivery but still with lower delivery stability. Its conclusion: “AI doesn’t fix a team; it amplifies what’s already there.” Judgment, decisions and outcomes are what get amplified. The same thinking applies when you bring AI into a large organization.
Nobody ever learned to become a great writer just by reading books, and nobody learns to build software just by accepting output. You have to feel it.
If your team is working out how to use AI without losing the judgment behind the code, talk to us about how we build.
In our view, only when you already understand what it does. Code that runs is not the same as code you can explain, and the gap shows up later, when something breaks and you have to say why. For anything new to you, read it, explain it back and test it first.
Not all of it. In our experience, retyping is worth the time for the parts that are new to you, such as an unfamiliar library or pattern. For the rest, explaining the code in your own words and writing the test first does more for your understanding per minute.
Explain it out loud, line by line, without looking at the AI's own explanation. Wherever you stall, you have found the part to learn or to question. Then write a test that would fail if your explanation were wrong.
It can, depending on how you use it. In one 2026 trial, developers who used an assistant scored lower on a follow-up quiz, while those who asked it conceptual questions kept their learning. In our view, the habit matters more than the tool.
If your team is working out how to use AI without losing the judgment behind the code, talk to us about how we build.