I started seriously using AI to write code for Toket in April 2026. Cursor was incredibly fast.

Sometimes I would come up with a feature, discuss it with ChatGPT, turn it into a clear task, and hand it to Cursor. A basic version of the page and its logic could appear very quickly.

That speed creates a dangerous illusion: If you can describe a feature clearly, you can start building it immediately. That was how I began building Toket AI V3 Workspace.

I did not spend enough time studying mature open-source workspaces on GitHub. I did not first download a complete project and carefully examine its architecture.

Toket already had models, prompts, cost calculation, authentication, and other product logic. Adding a multi-model chat workspace felt like a natural next step.

Looking back, this may be one of the most important decisions I need to reflect on from the past three months. I Thought a Workspace Was Mostly a Chat Interface

My original understanding of V3 was relatively simple. Users should be able to choose a model, enter a question, receive an answer, and save some conversation history.

Because Toket already had its own model data and product logic, I naturally assumed the workspace should also be built from scratch. Once I went deeper, I slowly realized that a workspace is not just a chat page.

Behind it are conversation management, message state, model switching, context handling, error recovery, files, attachments, storage, history, permissions, usage tracking, and many small details that directly affect the experience.

None of these things appears impossibly large on its own. Together, however, they form a complete product that requires long-term refinement.

A mature workspace looks simple because much of its complexity has already been hidden from the user. I only began to understand that complexity after I was already deep inside the implementation.

AI Coding Made Me Skip the Most Important Step I increasingly believe that the biggest risk of AI Coding is not only technical debt. It can also push people into execution too early.

In the past, if I had wanted to build a workspace from scratch, I probably would have spent much more time researching products, architecture, and open-source projects.

Traditional development was expensive enough that every major decision had to be considered carefully. Cursor changed that. When execution became dramatically cheaper and faster, I did not stop long enough to ask:

Should I build this myself at all?

I skipped part of the research, architectural comparison, and product-boundary work, and went directly into development. AI did not force me to do that.

But it created the feeling that since something could be built quickly, I might as well build it first.

By the time more features, files, states, authentication logic, model routing, conversations, and storage were connected, replacing the system with a mature open-source project was no longer a simple decision.

Yesterday, I Almost Wanted to Tear V3 Down Yesterday, while continuing to adjust V3, I became extremely frustrated.

I removed cloud storage and several other things that had previously been added. Then I continued dealing with old logic, product boundaries, and different parts of the workspace.

By the end, I honestly felt sick of it.

At that moment, I strongly believed that I should have started by pulling down a mature project from GitHub instead of writing everything myself.

I even considered tearing the current V3 down and replacing it with an existing open-source system. But the reality is that switching is no longer simple.

Toket’s authentication, model management, providers, usage tracking, prompts, admin system, and product logic are already connected to V3 in many places.

Replacing the workspace now would not be the same as replacing a chat interface. I might end up maintaining Toket while also continuously modifying and adapting another large codebase.

That may not be easier than continuing with what I have. So I am now in a very real and uncomfortable position. If I continue, there are still many features and experience details to build.

If I replace everything, much of the existing work cannot be migrated directly. That was the source of my frustration yesterday. It felt like being trapped between two bad choices.

I Do Not Regret Building V3 After calming down, I realized that I do not actually regret building V3 itself. Toket genuinely needs a multi-model workspace that I can use over the long term.

I need to switch between models on the web, test prompts, compare providers, track tokens and costs, and gradually connect Toket’s models, prompts, pricing, and knowledge assets.

Those needs are real. The real problem is that I failed to define one thing clearly enough at the beginning: How far should Toket V3 go? I do not need to build another ChatGPT.

I do not need to rebuild Open WebUI or LibreChat. Toket does not need every feature that exists in a mature general-purpose workspace.

Cloud file storage, complex collaboration, a large plugin ecosystem, a complete knowledge base, cross-device synchronization, and many other generic capabilities should not automatically become Toket’s responsibility simply because other products have them.

If V3’s real value is to serve as Toket’s internal multi-model experimentation workspace, it first needs to do only a few things well: Provide stable conversations.

Make model switching easy. Preserve the necessary context and history. Show token usage and cost. Gradually connect with Toket’s existing prompts, model data, and knowledge assets.

Everything else should be added through real usage, not because a theoretically complete workspace is expected to have it. Removing Cloud Storage May Not Be a Step Backward

When I deleted several features yesterday, my first reaction was frustration. It felt as though I had spent a long time building something only to remove it later.

Now I see it differently. It may not have been a step backward. It may have been an attempt to shrink a product scope that had expanded in the wrong direction.

Over the past three months, I have already experienced how quickly AI-generated technical debt can grow. AI can produce large amounts of code, but it does not naturally stop and ask:

Should this feature exist? Who will maintain this module later? Has this product boundary already exceeded what one person can sustainably manage?

When the product scope itself is wrong, faster development only creates more things that may need to be deleted later. Sometimes removing one unnecessary module is more valuable than adding ten new features.

The Most Valuable Part of Open Source Is Not the Code Over the past few days, I have returned to mature GitHub projects with a different perspective.

A few months ago, my first question when viewing an open-source workspace might have been: What features does it have? Now I care more about questions such as:

Why are its modules divided this way? Who owns conversations, messages, models, files, and user state? Which capabilities are core, and which are extensions?

How does the project support long-term maintenance instead of merely making the interface work? The real value of a mature open-source project is not only the code that can be copied.

It is the architectural trial and error that its maintainers have already paid for. This does not mean I must replace all of Toket with an open-source project.

A more realistic approach may be to preserve the parts of Toket that already have unique value, while gradually learning from mature projects and absorbing their architectural and product decisions.

Borrow what can be borrowed. Remove what should be removed. Stop building what does not need to exist. The Faster AI Writes, the More Humans Must Judge First

I used to worry mainly about whether AI-generated code would create technical debt. Now I realize that technical debt is only part of the problem.

Before technical debt comes product-decision debt.

When AI can complete in one day what used to require several weeks, a wrong direction can also expand at unprecedented speed. In the past, slowness itself forced people to think.

AI has removed much of that slowness. That means humans must deliberately create a pause: Research first. Compare first. Define the boundaries first.

Decide what will never be built. Then start writing code. Otherwise, the faster development becomes, the more expensive it becomes to return after choosing the wrong direction.

V3 Does Not Need to Become an Entire World I have not fully solved the V3 problem yet. Honestly, I am still frustrated, and I still know there is a great deal of work ahead.

But one direction is becoming clearer. Toket V3 does not need to become a complete general-purpose workspace. It should first become a multi-model experimentation environment that I genuinely want to use every day.

It should grow around Toket’s unique models, prompts, cost data, and knowledge assets, rather than chasing the feature lists of every mature workspace.

This experience has also helped me understand something more clearly: AI Coding makes starting from scratch extremely easy. But being able to start from scratch does not mean that you should.

I do not regret writing code for three months.

I regret that before writing the first line, I did not spend enough time studying the people and projects that had already walked the same road.

It is not too late. The most important task in the next stage may no longer be adding more features to V3. It may be answering a more fundamental question:

What exactly is Toket V3? And, perhaps even more importantly: What is it not?

Estimate task cost in the AI Cost Estimator or refine prompts in the Prompt Optimizer.