What Disappeared After AI Started Writing Our Code?

This article is translated by AI, if have any corrections please let me know.

Over the weekend, while evaluating which frontend framework Tsuzuri should move to from Stimulus, I opened the Svelte tutorial to keep the whole thing lightweight. To my surprise, it doesn’t allow copy and paste at all, so for the first time in a long while I wrote the code by hand.

After about an hour of typing it all out, I was amazed at how much Svelte achieves with such concise syntax, and it made me wonder: when AI does the implementation, can we still find surprises like this?

Polish

When was the last time we opened the code and asked, “Wouldn’t it be better if we did it this way?” I’m not sure people still do this, since it seems to be the same thing as Code Review. And if AI rarely gets the implementation wrong, do we really still need to?

Although I don’t really read it line by line either, I still glance at the generated code to adjust the direction, and sometimes I browse the project on GitHub to see how the implementation is going.

In reality, AI-generated code still has problems quite often. But they are not “it doesn’t work” problems; they are more like things that went unnoticed, or a lack of deeper understanding.

So polishing is still necessary, but in an environment where we can develop this fast, it’s hard to say how we should do it.

Blind Spot

When I’m able to move fast, at some point I always notice, “Did it get slower?” But this kind of slowdown isn’t obvious. After all, we’re already leaving AI to run for an hour or two, so it usually takes a while of development, until it’s slow enough that even giving feedback means waiting, before we notice the problem.

Take the Godot extension I’m developing as an example. When I got mruby close to usable, I pointed out that CI was particularly slow and we should improve it. That’s actually quite normal; most projects run into this once they grow to a certain size.

But what was actually slow? Basically, mistakes we wouldn’t have made in the hand-written era. For example, when the CI checks were first designed, the entire test suite was run twice to compare results, and removing that instantly made it twice as fast. Or when the Godot editor starts up and needs to index files, AI didn’t design any cache at all, so every file load triggered a rescan, making the time complexity O(M * N) instead of the O(N) of scanning the files once.

But is anything functionally wrong? Not at all, and it certainly works well.

These are still the lucky cases. A friend ran into this with a deployed service: AI didn’t look carefully at how D1 (the database) on Cloudflare Workers is billed and came up with a write-heavy design. The data was indeed updated in real time, but the write costs nearly multiplied the bill.

And none of this is wrong, the tests all check out, yet we are quietly paying some kind of price, and it may be higher than we realize.

A Solution?

Honestly, I still don’t have a good solution so far. The only thing I’m sure of is that our understanding of computer science and how familiar we are with the language we use will greatly affect whether we can handle these problems well. And that’s before even considering “is the design elegant?”, a question few people cared about even in the hand-written era.

Would a typed, faster language help? Like DHH’s talk at Rails World 2026 suggested, when you don’t need to read the source code, Rust might be an option. But does it really help?

The Godot extension I mentioned earlier is developed in Rust. Setting aside the silly-looking issues of running tests twice and the editor rescanning repeatedly, I also ran into it being nearly 10 times slower than native GDScript, far off from the roughly 2 times I had estimated.

Why? Although Rust guarantees type and memory safety well, it doesn’t guarantee the whole path is optimal. I found a new problem in beni, the Rust binding crate for mruby. Wrapping it in Rust does provide protection the original C API lacks, but it also adds “redundant” checks. The C API already validates these, yet AI, while wrapping it, “assumed it was unsafe” and checked again. In the end, these few microseconds add up into a huge drag in a game context.

In my COSCUP talk this year, Let AI Take Over Your Application, I also spent a lot of time explaining how to push “speed” to the limit step by step. Looking back now, this may be a sign of some new symptom: when we can move this fast, do the problems we used to hit “later” surface much sooner?

I can’t shake the feeling that something is missing from this process. Even though I think carefully about structure and naming conventions, when moving fast it always feels like something has been left undone. I’ve tried at least everything that’s commonly discussed online, but it seems there’s a more fundamental problem that nobody has found yet.