Recently, I have been using AI intensively almost every day to build Toket. Cursor writes code. Codex audits the system. ChatGPT helps me organize product logic, reports, and development notes.
From an efficiency perspective, this workflow is extremely powerful. A lot of work that would have been nearly impossible for one person can now move forward quickly.
But something strange has happened. The more I use AI, the less confident I have become. Not because I doubt whether AI can write code. I have started to doubt the assumption that a complete-looking answer is necessarily a correct one.
One problem has become very clear: AI rarely challenges my premise by default. If I say: “We should add another compatibility layer here.” It usually starts figuring out how to build it.
If I say: “This page should remain.” It starts designing how to preserve it. If I believe the root cause is A, AI often produces a very complete solution around A.
But what if I was wrong from the beginning? AI may not stop me. It may help me build the wrong direction extremely well. This is more dangerous than an ordinary bug.
Normal bugs are visible. The program crashes. The page fails. The test breaks. At least those failures tell me something is wrong. A wrong product direction is different.
The code can work. The tests can pass. The page can look good. The implementation can even be technically excellent. And the whole thing may still never have needed to exist.
Toket has recently gone through a lot of legacy cleanup, and this has made the problem much more obvious to me. Many old structures were not mistakes when they were created.
They had reasons. But the product changed. If I simply ask AI: “How should I fix this old page?” AI can fix it very well. The better question may be:
“Why does this page still exist?” That is why I now force myself to audit before implementation. Before touching the code, I want to understand:
What is the actual current state? Who owns this logic? Has a newer system already replaced it? Is this a real requirement or only my assumption?
Does anything need to change at all? Can it simply be removed? I used to think this process was slow. Now I think it is one of the most important parts of AI-assisted development.
Because the stronger AI execution becomes, the faster a wrong direction gets amplified. Another problem I have become more cautious about is hallucination.
Sometimes AI treats “what should exist” as “what actually exists.” It may assume a module owns a responsibility. Assume an old page still has consumers.
Assume data comes from a certain API. And it usually explains these assumptions very naturally. That is what makes it dangerous. It does not always sound obviously wrong.
It often sounds like a conclusion reached after understanding the entire codebase. If I am unfamiliar with that part of the system, it is easy to continue based on the assumption.
Only later, after reading the files, running tests, or opening the page, do I discover that the premise was never true. Report writing has a similar problem.
AI is very good at making reports look complete. Title. Summary. Findings. Recommendations. Priorities. Next steps. Everything appears to be there.
But recently I have become much more sensitive to a certain “AI feeling.” The writing is correct. The structure is clean. The logic is smooth.
But there is no person inside it. No hesitation. No specific moment. No detail that only someone who actually did the work would remember. Sometimes I finish reading a report and feel that it said everything.
And somehow, it still said nothing. That is also changing how I think about Lab Notes. Previously, I often used AI to make my development process more complete and polished.
Now I want to keep more of the incomplete parts. Things like: I was exhausted from changing the same thing again. Cursor gave me another series of multiple-choice questions.
One file was revised repeatedly. I thought the root cause was A and eventually discovered it was something completely different. A failed deployment test turned out to be the system successfully blocking a retired feature from returning.
These details may not sound polished. But they are real. And reality may be more valuable than completeness. I used to think about AI mostly in terms of how much work it could replace.
Now my view is changing. AI can handle a lot of execution. Writing code. Organizing information. Generating tests. Summarizing documents. Helping investigate problems.
But AI does not own the consequences of product decisions. If the direction is wrong, I lose the time. If the architecture becomes complicated, I maintain it.
If a report sounds impressive but the conclusion is unreliable, I am still the person facing the customer. The responsibility for judgment does not disappear because AI is involved.
In fact, stronger AI may make Builder judgment more important. In the past, a bad idea might never get built because development was too expensive.
That is no longer true. A bad idea can now become a complete implementation very quickly. That means “being able to build it” is becoming less valuable.
The more important questions are: Should this exist? Should it happen now? Is there a simpler solution? Is my assumption wrong? Is this an old problem or a new one?
Recently, I have started deliberately asking AI to challenge me before implementing anything. Instead of: “Build this.” I first ask: “What's wrong with my assumption?”
“Is there a simpler option?” “Who currently owns this responsibility?” “Could the correct solution be doing nothing?” This slows development down slightly.
But it also reduces the chance of rapidly scaling the wrong decision. I am not giving up on AI Coding because of these problems. Quite the opposite.
Without these tools, I could not have pushed Toket to its current level of complexity alone. But I no longer assume that a complete AI answer means the problem has been understood.
I verify more. Read the code again. Check real data. Open the page. Run tests. Challenge conclusions in reports. Sometimes I even throw away an entire completed round of work.
That process is not easy. Development has been intense lately. Constant changes. Constant deletions. Constant legacy cleanup. Constant corrections to AI output.
Some days, it feels less like “AI is helping me build” and more like managing a group of extremely fast and capable collaborators who still need constant direction.
Maybe that is a more accurate description of AI collaboration today. It is not autopilot. It is a powerful engine. The steering wheel still belongs to the Builder.
I am less blindly optimistic about AI than I was before. But that may not be a bad thing. Perhaps anyone who uses a tool seriously for long enough eventually reaches this stage.
First, you are amazed by what it can do. Then, you learn how it fails. Only after that do you understand: What can be delegated. And what must remain yours.
That boundary is becoming much clearer as I continue building Toket. AI can write code. AI can write reports. AI can propose options. AI can generate ten different directions in seconds.
But the person who decides which one is real, which one matters, and which one should be deleted is still me.
Estimate task cost in the AI Cost Analysis or refine prompts in the Prompt Optimizer.