The Best Rubber Duck I've Ever Had

For me, AI started out as the best rubber duck I ever had. Then it became the new clipboard, the place I copied snippets from instead of Stack Overflow. After that, it became the best spellcheck and code completion I've had. I reach for it when I'm in a deadlock and not sure how to proceed.

Now, in 2026, it can write genuinely useful code.

The rubber duck effect

There's another great thing about it, something Stack Overflow always had too. It helps a lot simply because I have to write my problem down, and writing it down clarifies it in my own mind before the AI even answers.

Cutting through procrastination

It also helped me a lot with procrastination. I always try to make things work the simplest way possible first and improve later. Sometimes, though, the simple way is not obvious, and you hesitate on a simple task just because you miss some small piece of information. Most routine programming tasks have already been done before, so for an AI, finding that simple, common way is fairly easy. There is no reason to be stuck on simple things just because of a lack of info. It gets you moving, and you can take it from there.

Juniors vs. seniors

As a junior, I think you should use it only when you're stuck, otherwise it will be hard to catch up. As a senior, I know what good code looks like, so I can spot when the AI drifts and correct it. A junior who leans on it too early skips that step. They get working code without understanding why it works. Without that foundation, they cannot tell good output from bad, so they just trust it. Not every junior will do this, but I think most will if AI becomes the default first move instead of a fallback. Struggling with the problem first is how you learn; skipping the struggle skips the learning, even if the code that comes out works fine.

I believe there are companies that will hire more seniors instead of juniors, simply because the AI is already a very good junior in terms of execution.

Entropy

In some sense life is a fight against entropy, and code is the same. The more you touch code without keeping it simple, the more it decays, and AI speeds up that decay if you are not careful. It won't tell you on its own that a class has grown too large or that two modules are too tightly coupled. That is still your job. Refactoring is how you fight back: watch how the larger pieces fit together, and keep cutting them down. If you use AI well, refactoring actually becomes cheaper because small iterations are easy to test. If you use it carelessly, you just end up with messy code much faster.

Where it misleads you

It works best in small steps; give it too much scope or too little context and it fills the gaps with assumptions. Some of those assumptions are reasonable, but many are not. It tends to generate too much code, it misses obvious things, and it keeps adding instead of simplifying. I have asked for one small change and gotten back an extra abstraction I never asked for, like a new config option or a helper class to solve a problem I did not have. I learned to build incrementally and keep the code understandable at every step, instead of asking for a big leap and hoping it holds together. Even when it is wrong, it can still be useful. A bad answer often points me in the right direction just by showing me what a solution might look like.

What changed for system design

I feel that with AI, your system design skills matter a little more than before. The code is easier to produce now; knowing what to build, and how the pieces should fit together, is the part that does not get automated. I try to keep the overall shape of the system in my head. You have to watch coupling and cohesion yourself, because it is easy to blur boundaries when you let an AI generate code piece by piece.

What I've learned

If I look at how I work with AI today, my practical learnings come down to a few habits.

First, keep your changes small and incremental. Tell the AI clearly what good code looks like: do not add extra features, keep it simple, and prefer pure, testable methods. While building a feature, I also prefer adding new code instead of modifying what is already working, and I refactor once it works.

Second, build a proper safety net. Knowing how to use tools like Playwright is a must, because good tests let you verify generated code quickly. If you work on a production system, make sure the AI has access to logs so it can debug issues directly. I also keep markdown notes where I document large changes and the reasoning behind them.

Third, actively simplify. An AI is great at producing code, but it will never clean up after itself. Take the time to simplify the system after you get it working, otherwise the code will quietly rot.

Finally, make sure you actually understand the code you keep. It is easy to accept working output and move on, but you do not learn that way. When you take the time to do things slowly, you gain real experience, thoughts, and ideas. This is why I dislike when companies push AI purely for speed. They look at how fast code is produced, but real understanding does not work like that. Terence Tao pointed this out in a short talk about AI and science: you arrive faster, but you understand less.

Speed is cheap now, but good software still takes care. Invest in the design of your system every day, and take the time to understand what you build.