Learning to Work with AI, Not Just Use It

Today was probably the first time I seriously and systematically studied how to work with AI.

Looking back, the way I had been using AI before was surprisingly inefficient.

The Limits of Browser-Based AI

At first, I mostly used cloud-based AI models through their web interfaces. I would describe a problem, submit my request, and wait for the model to respond.

This worked well enough for simple tasks. However, as conversations became longer, the limitations started to become obvious.

The browser had to render and manage an increasingly large conversation history. Pages gradually became slower, older messages became harder to find, and navigating the discussion became inefficient.

This was especially noticeable during development work. Once the amount of code increased, or the conversation approached the model's context limit, I had to start a new chat.

Every new conversation meant reorganizing the project background, existing code, previous decisions, and unfinished tasks before providing all of that information to another AI.

The process was time-consuming, repetitive, and easy to get wrong.

IDE Tools Help, but Context Is Still Fragmented

I later started using AI features inside tools such as Cursor, Xcode, and VS Code.

Because these tools can interact more directly with a codebase, they reduce some of the friction involved in managing context. However, they do not completely solve the problem of continuity.

When a task spans multiple conversations, models, or development environments, I still have to act as the information bridge.

I copy conclusions from one AI to another, explain the current state of the project, and repeatedly clarify what has already been completed.

In many cases, the most exhausting part is not writing the code itself. It is repeatedly helping the AI understand the project.

Discovering AI Through the Command Line

Recently, I started experimenting with several CLI-based AI tools.

That was when I began to realize how effective the command line can be for development-oriented AI workflows.

A CLI tool can directly access local files, understand the structure of a project, run commands, and operate within an existing development environment.

Compared with asking isolated questions in a browser, it feels much more like allowing the AI to enter the project itself.

Claude Code, for example, gave me an experience closer to an agent-like workflow.

Instead of simply responding to prompts, the AI could inspect files, understand a task, create a plan, and attempt to complete the entire process.

But this approach introduced another very practical problem:

Cost.

The Cost of Agent-Like Workflows

After modifying only a few sections of code, I quickly reached the usage limit of my Claude Pro subscription and began consuming additional tokens.

The changes themselves were not especially complicated.

The real issue was that a CLI agent repeatedly reads files, project structures, instructions, and historical context while completing a task. Even a relatively small code change can therefore consume a large amount of context.

This kind of workflow is powerful, but assigning every step to a single expensive model does not seem sustainable.

That led me to reconsider the entire process.

Why Should One Model Do Everything?

Different models have different strengths.

Why should one model be responsible for planning, decision-making, implementation, interface generation, debugging, and documentation?

A more effective approach might be to let several models collaborate, with each one handling the work it does best.

My initial division of responsibilities looked like this:

• Claude handles planning, decision-making, and task decomposition, almost like a product manager.
• Codex handles backend implementation and engineering tasks.
• Gemini handles frontend generation and interface-related work.

Claude is particularly useful for high-level reasoning and planning, so I only use it for decisions that genuinely benefit from that capability.

Codex handles more implementation-heavy programming work, while Gemini focuses on frontend and visual output.

A Multi-Model Workflow

Once I began combining the three models, the workflow felt noticeably different.

I no longer needed to repeatedly reorganize the entire project context. I also reduced the amount of information I had to manually transfer between AI systems.

Each model could focus on a narrower responsibility instead of repeatedly reading and processing the entire project.

This helped control token usage while also improving overall efficiency.

Of course, this does not mean that context management has disappeared.

A multi-model workflow still requires clear task boundaries, shared documentation, and a deliberate system for passing information between agents.

The models do not automatically understand what the others have done. The workflow itself still has to be designed.

However, compared with constantly copying, pasting, and re-explaining the state of a project, the process now feels much clearer and more manageable.

From Using AI to Organizing AI

For me, this was an important shift.

I began to understand that using AI effectively is not simply about finding the most powerful model and assigning every task to it.

It is also about understanding the strengths of different models and designing a process that allows them to work together.

The capabilities of individual AI models matter.

But the way we organize those models may matter just as much.

My next step is to make this multi-model workflow more systematic and eventually turn it into a web-based tool.

Once the process becomes stable enough, I also plan to organize the project and publish it on GitHub.

This feels like a direction worth continuing to explore.