You know how to code. You have spent time learning, tracing failures, and figuring out why one solution holds together while another eventually breaks.
So when you see someone ask an AI to generate a feature in a few sentences, some resistance is understandable.
Not necessarily because the tool is bad. Sometimes, you simply do not want your work to become code accepted without understanding.
That caution has a place. It should not become a ban on trying.
The argument over labels can miss the point
My earlier vibe coding article was aimed particularly at people who want to build a tool without knowing how to code. It already emphasized context, manageable steps, and verification. It was not an invitation to accept AI output blindly.
This time, I am speaking to developers who know their craft but hesitate to use these tools because they worry it will devalue their work. The question is no longer how to discover the method. It is where your expertise fits into the collaboration.
The terminology can be confusing. Here, I use “agentic development” to mean delegating work to an agent that can carry out a sequence of actions in a project. That says nothing, by itself, about the quality of the outcome. Neither “vibe coding” nor “agentic coding” is a quality certificate.
You can use an agent that changes an entire project and accept the result without reading it. You can also give it a small task, examine its explanation, verify the code, and reject its proposal.
The agent describes what the tool can do. Engineering discipline describes how you use it.
The second part is what matters to me.
Experience changes the questions you ask
On a business application, an experienced developer looks beyond whether the screen works.
They think about access control, inconsistent data, an operation running twice, and the consequences for existing users.
That experience remains valuable when working with AI. It helps you notice what a successful demo does not show.
You can ask the tool to prepare an implementation. Identifying the risks to investigate and deciding whether the result is acceptable are still part of the job.
That is not a loss of skill. It is another way of putting skill to work.
What you can delegate, and what you still own
You can ask AI to locate the relevant files or prepare an initial fix. You do not have to hand over decisions about business rules, architecture, or acceptable risk.
Imagine a fix that makes the tests pass by removing a permission check. The tool may have removed the symptom. Your job is to notice that it also removed a safeguard.
That is where experience matters: distinguishing a solution that works in the demonstrated case from one the team can responsibly ship.
Then ask yourself an honest question: could I explain this change to a colleague without asking the AI to speak for me?
If the answer is no, the work is not finished.
Solo: Giving Agent Work Some Structure
Once several agents are involved, another problem appears: knowing who is doing what, with which information, and in what order. That matters whether you are skeptical or already convinced.
Solo supports orchestration across tools: one agent can launch others, assign work, and collect their results. Its website describes five components as “Small building blocks for serious workflows”:
- Scratchpads: shared Markdown notes that keep context beyond a single conversation. For example, you could record an export’s business rules and the decisions a later fix needs to respect.
- Todos: tasks with blockers and dependencies. A verification task can wait for implementation to finish instead of starting against incomplete work.
- Prompt templates: reusable instructions with placeholders. You could prepare a review request once, then adapt it to the module being examined. Documentation for these features
- Control terminals: agents can read terminal output, send commands, and monitor execution. For a test run, that means examining the actual result before deciding what to do next.
- Agent spawning: one agent can launch another, give it an assignment, and collect its result, including across tools from different providers. This enables work to be distributed among several agents. Solo’s overview
What interests me is how those pieces can work together around a specific problem.
Imagine fixing an invoice export in a Laravel application. Here is a workflow you could organize: record the business constraints, request an analysis of the existing flow, assign the fix to one agent, and have another examine the change. The review depends on the fix; it should not assess an outdated version of the code.
That gives the work stages, responsibilities, and checkpoints. A second agent provides another perspective, but its approval is not enough to validate the result. You still need to understand and verify what will ship.
Reserve the Most Capable Models for the Hard Decisions
This setup also gives you a way to think about cost. One strategy I would suggest is to give scoping, decomposition, and difficult decisions to an agent using a more capable model, then assign straightforward tasks to agents using less expensive models.
The orchestrator needs the broader picture: identify dependencies, write precise assignments, and examine the results before bringing them together. Solo documents this pattern as a lead agent coordinating worker agents. Orchestration workflow
In our export example, the more capable model could investigate the problem and establish acceptance criteria. A cheaper model could then update a label, document a filter, or add a clearly specified test case following an existing pattern.
Each assignment needs an objective, an allowed set of files, boundaries on what must stay unchanged, and a way to check the result. You also need evidence that the chosen model handles that kind of work: a small task can still hide a difficult problem.
That reserves the expensive model for stages where its capabilities are useful. Reasoning and a large context can consume substantial tokens, although a more capable model does not necessarily use more of them. The bill also depends on token pricing and the number of attempts.
The savings still need to be measured. Passing context, coordinating workers, and repairing mistakes all have a cost. If a task becomes ambiguous or exceeds the worker’s capabilities, it should return to the orchestrator. For a tiny fix, one agent may remain the better choice.
If you are hesitant, start with one task you know how to evaluate. If you already use several agents, look for where you lose track: instructions, dependencies, or the results coming back.
To explore further, visit Solo’s website and try the app on a familiar project. See whether it actually helps you organize the work and stay in control of the changes. I will return to the tool in a dedicated article.
Speed is not the whole job
I do not think we need to divide developers into “old school” and everyone else. Teams need people who can make progress and people who can spot problems before they reach production. Often, they are the same people.
AI offers another way to explore and produce. It does not automatically turn an initial implementation into a reliable solution.
The useful measure is the time needed to get something you can understand, verify, and maintain. Not the number of lines generated.
You can experiment without lowering your standards
Skepticism is useful when it leads to a serious experiment: a bounded task, clear criteria, and an honest assessment.
It is less useful when it stops us from examining a tool because we are worried about the label attached to it.
You do not have to prove your ability by personally typing every line. You do have a responsibility for what you ship.
Learn the tool. Keep your judgment. Let the results, rather than the labels, determine the place it deserves in your work.