For the past several months, I have been experimenting with a different way of building software products, with efficacy of tokens usage by saving token saving 60~80%.
Instead of treating AI as a code-completion tool, I have started treating multiple AI systems as a small engineering team.
In my current setup, I think of the system as having three employees:
- Claude as the senior developer and technical lead
- OpenAI Codex as the senior software engineer and independent code reviewer
- A local Qwen3-Coder 30B model as the QA engineer, documentation maintainer, and content assistant
I am also planning to add GitHub Copilot as another supporting tool for repository navigation, retrospective analysis, issue management, and development assistance.
My estimated monthly software cost for this setup is approximately:
- Claude subscription: about $20
- Codex or ChatGPT subscription: about $20
- Claude API usage: approximately $10
- Planned GitHub Copilot subscription: approximately $10
That brings the total to roughly $60 per month, or approximately ₹5,800 to ₹6,000, depending on exchange rates and actual API usage.
For this amount, I am building a software product from scratch with architecture, implementation, testing, pull requests, CI validation, documentation, QA planning, and product knowledge management.
That is the part I find genuinely exciting.
However, the important question is not simply:
“Can AI write code?”
The more useful question is:
“How can multiple AI systems collaborate like an engineering team while maintaining quality, traceability, and cost control?”
This article explains what I observed during one long Claude CLI development session and how the work was delegated across different models and agents.
The Task I Gave Claude
During the session, I asked Claude CLI to perform several connected engineering tasks:
- merge existing pull requests
- verify CI status
- take the latest version of the main branch
- create separate branches for GitHub issues
- use project-specific engineering guidelines
- delegate repetitive work to cheaper agents
- implement features
- run code reviews
- fix review findings
- update the Obsidian documentation vault
- create pull requests
- wait for CI
- merge approved work
- continue with the next issue
This was not a simple “generate a function” request.
It was an end-to-end software delivery workflow involving:
- Git
- GitHub issues
- feature branches
- multiple worktrees
- backend development
- frontend development
- database changes
- automated tests
- documentation updates
- independent review
- CI monitoring
- pull-request management
- architecture decisions
- product knowledge maintenance
Claude did not perform all of this work using a single model in one continuous reasoning loop.
Instead, it acted as an orchestrator.
Claude Was Acting as the Engineering Lead
The main Claude session behaved like a senior developer, architect, and delivery lead.
Its responsibilities included:
- understanding the overall request
- checking current repository state
- identifying issue dependencies
- deciding the correct implementation sequence
- selecting agents for different tasks
- providing agents with focused context
- reviewing their findings
- correcting implementation problems
- managing branches and pull requests
- monitoring CI
- updating the product documentation
- deciding when human confirmation was needed
For example, when I asked Claude to work on several GitHub issues, it did not blindly process them in numerical order.
It first inspected the issues and discovered that one issue depended on another.
It then changed the implementation order to:
- build the required data model
- build the provider adapter
- continue with dependent features
This is an important distinction.
A basic coding assistant might follow instructions literally.
A senior engineer should identify dependencies, risks, and sequencing problems before implementation.
That is the role Claude was performing.
The Three-Employee Model
The easiest way for me to understand this setup is to think of it as a small engineering team.
Employee 1: Claude — Senior Developer and Technical Lead
Claude is responsible for the overall delivery.
Its work includes:
- understanding business requirements
- reviewing GitHub issues
- defining implementation scope
- making architectural decisions
- breaking work into smaller tasks
- selecting the right model for each task
- validating outputs from other agents
- resolving merge conflicts
- coordinating documentation
- managing pull requests and CI
- producing the final summary
Claude does not need to read and process every file personally.
Instead, it delegates focused tasks and receives compact reports.
This helps preserve the main session context for higher-value reasoning.
Employee 2: Codex — Senior Software Engineer and Independent Reviewer
OpenAI Codex acts as a second senior engineer.
Its main responsibility is not simply to agree with Claude.
Its purpose is to provide another technical perspective.
Claude delegates the completed code diff to Codex and asks it to review areas such as:
- correctness
- security
- database safety
- type mismatches
- edge cases
- tenant isolation
- null handling
- ordering logic
- API behavior
- missing test coverage
- migration reversibility
This independent review is extremely valuable.
In one case, Codex discovered a real cross-tenant validation problem.
The application allowed a tenant-level default spot ID to be updated through a generic field assignment flow. The database foreign key ensured that the spot existed, but it did not by itself guarantee that the spot belonged to the same tenant.
Codex identified that the new spot-selection logic could be undermined by this missing ownership validation.
Claude then:
- verified the finding
- inspected the Row-Level Security behavior
- added a tenant-scoped lookup
- rejected invalid cross-tenant references
- created a regression test
- ran the full backend test suite again
- updated the documentation
- continued with the pull request
This is exactly why a second engineering perspective matters.
Claude implemented the feature.
Codex challenged the implementation.
Claude verified and fixed the valid finding.
That resembles a real senior engineering review cycle.
Employee 3: Qwen3-Coder 30B — Local QA and Documentation Engineer
The third member of this AI team is a local model:
Qwen3-Coder 30B running through Ollama.
This model runs on my own hardware.
My goal is to use it for tasks that are important but repetitive, context-heavy, or suitable for local processing.
The next phase of my workflow is to assign Qwen3-Coder responsibilities such as:
- QA planning
- creating tasks for future work
- understanding the Obsidian product vault
- converting my observations into structured GitHub issues
- creating test cases for completed Claude tasks
- executing or coordinating test runs
- reviewing test results
- fixing or improving test cases
- maintaining product and technical documentation
- producing social-media and website content from the product knowledge base
This is important because a product requires much more than feature implementation.
It also requires:
- regression testing
- product documentation
- decision tracking
- issue preparation
- user-facing content
- release notes
- QA evidence
- knowledge consistency
A local model can handle many of these tasks without sending all product knowledge to another cloud provider.
How Claude Delegated Work
The development process followed a repeatable pipeline.
Step 1: Understand the Request
Claude first interpreted the user request and repository state.
It checked:
- which pull requests were open
- which issues were already completed
- which issues were still active
- whether main was clean
- whether CI was passing
- which issue depended on another
- whether the requested issue title matched the actual GitHub issue
In one case, I provided an issue number with the wrong title.
Claude checked GitHub and corrected the mismatch before starting work.
That prevented work from being performed against the wrong requirement.
Step 2: Use a Cheap Repository-Scanner Agent
Claude delegated repository exploration to a smaller, cheaper agent backed by Claude Haiku.
The repo-scanner was responsible for:
- finding relevant files
- identifying existing models and APIs
- locating current tests
- understanding documentation structure
- checking whether fields already existed
- identifying likely implementation gaps
- reporting architectural constraints
This task may require reading many files, but it does not always require the strongest reasoning model.
Using Haiku for repository discovery saves the main Claude model from spending a large number of expensive context tokens on repetitive exploration.
The scanner then returns a focused summary.
For example, it reported findings such as:
- the session already had a
spot_id - weather APIs already accepted spot IDs
- the UI was still using the tenant default spot
- activity calendars did not yet have their own spot field
- certain fallback behavior needed to be clarified
Claude used that summary to determine scope.
Step 3: Delegate Implementation to a Sonnet Builder Agent
Once the scope was understood, Claude created a dedicated branch or worktree and delegated implementation to a Sonnet-based builder agent.
The builder agent handled:
- backend changes
- frontend changes
- schema updates
- service-layer changes
- UI updates
- tests
- documentation changes
- type checking
- linting
- production builds
The builder worked with a task-specific context rather than the entire long-running conversation.
That is another form of token efficiency.
Instead of repeatedly sending the complete history, Claude gives the builder only:
- the issue
- architectural decisions
- relevant files
- acceptance criteria
- project rules
- expected validation steps
The agent then returns a concise implementation report.
Step 4: Send the Diff to Codex for Independent Review
After implementation, Claude did not immediately push or merge the code.
It delegated the diff to a Codex reviewer.
Codex reviewed the work independently and produced findings.
Claude then classified findings into categories such as:
- real defect
- security issue
- architectural concern
- missing test
- false positive
- out-of-scope suggestion
This part is important.
An AI reviewer can also make mistakes.
Claude did not automatically accept every Codex comment.
It verified the findings against the actual codebase.
In one case, Codex flagged missing mocks in frontend tests. Claude checked the files and determined that the mocks were already present and the finding was a false positive.
In another case, Codex found two genuine tool-call parsing problems in an AI-provider adapter:
- streamed tool calls could be returned in the wrong order
- malformed JSON arguments could silently become an empty object
Claude verified both issues and fixed them.
This demonstrates a useful multi-agent principle:
The reviewer should challenge the implementation, but the orchestrator must still validate the reviewer.
Skills Are Not the Same as Agents
The session also used skills such as:
- Karpathy guidelines
- gstack review workflows
- repository-specific operating modes
- documentation validation rules
A skill is not necessarily another LLM.
A skill is usually a reusable set of instructions, conventions, or procedures.
For example, a review skill may define:
- which files to inspect
- how to compare changes with the base branch
- what security risks to check
- when to stop
- how to report findings
- when to request user confirmation
Skills make agent behavior more deterministic.
The model still performs reasoning, but the skill provides a repeatable operating procedure.
This is similar to giving an employee:
- a checklist
- a standard operating procedure
- a code-review template
- a release process
- a QA playbook
The Obsidian Vault as Product Memory
One of the most important parts of my setup is the Obsidian vault.
Get Kedar Kulkarni’s stories in your inbox
Join Medium for free to get updates from this writer.Subscribe
Remember me for faster sign in
The vault stores product and engineering knowledge such as:
- architecture decisions
- module documentation
- development references
- business rules
- issue outcomes
- deferred scope
- test evidence
- change history
- prompts and implementation records
The vault acts as the long-term memory of the product.
GitHub stores code and issues.
The Obsidian vault stores why decisions were made.
This is especially important when AI agents are involved.
Without a persistent knowledge base, each new AI session may:
- repeat earlier analysis
- propose already rejected approaches
- misunderstand product scope
- contradict prior decisions
- recreate closed issues
- invent assumptions
By requiring Claude and the local LLM to update and read the vault, I am trying to create continuity across sessions.
My Planned Local-LLM QA Workflow
The next step is to move more QA and documentation responsibilities to Qwen3-Coder 30B running locally through Ollama.
The planned process is as follows.
1. Understand the Completed Work
The local model will read:
- the GitHub issue
- the pull-request description
- the code diff
- Claude’s implementation summary
- Codex review findings
- the relevant Obsidian documentation
- existing tests
From this, it should understand what was changed and why.
2. Create a QA Plan
Qwen3-Coder should generate a structured QA matrix covering:
- acceptance criteria
- happy paths
- negative paths
- edge cases
- permission checks
- tenant isolation
- API validation
- database behavior
- frontend rendering
- accessibility
- regression risks
- browser scenarios
The output can be stored in the Obsidian vault and linked to the GitHub issue.
3. Create Test Cases
The local model should produce test cases in multiple forms:
- backend unit tests
- service-layer integration tests
- frontend component tests
- API tests
- Playwright or Cypress scenarios
- manual QA steps
- data setup requirements
- expected results
Each test should be traceable to an acceptance criterion.
4. Run Tests and Collect Results
The local QA agent can execute or coordinate:
- backend test suites
- frontend tests
- linting
- type checking
- production builds
- API test scripts
- browser automation
- regression checks
The results should be summarized clearly:
- passed
- failed
- blocked
- not covered
- requires manual verification
5. Improve Test Cases
When tests fail, the model should determine whether the problem is:
- a product defect
- an outdated test
- incorrect test data
- missing environment configuration
- flaky timing
- incorrect assumptions
- a changed requirement
It should not simply change tests to make them pass.
The purpose is to preserve the intended product behavior.
6. Update the Obsidian Vault
After QA, Qwen3-Coder should update the product knowledge base with:
- QA results
- known limitations
- deferred work
- regression risks
- test coverage
- architecture notes
- issue status
- release readiness
This keeps the product documentation synchronized with the code.
Using the Local LLM for Product Content
I also plan to use Qwen3-Coder for content generation based on the Obsidian product knowledge base.
The goal is not to ask the model to invent random marketing copy.
The goal is to generate content grounded in actual product features, technical decisions, workflows, and customer value.
Potential outputs include:
- LinkedIn posts
- X posts
- Instagram captions
- blog articles
- product-update announcements
- release notes
- short promotional messages
- website articles
- feature explanations
- customer onboarding content
- image-generation prompts
- architecture articles
- founder journey posts
Because the model can read the Obsidian vault, the content can remain consistent with the actual product.
For example, it can understand:
- what AquaRosters currently supports
- which features are implemented
- which features are still planned
- why certain architectural decisions were made
- which customer problems the product addresses
- what changed in the latest release
This reduces the risk of publishing exaggerated or incorrect claims.
Where GitHub Copilot Fits
I am planning to add GitHub Copilot to the setup.
My expectation is that it can support areas such as:
- faster code navigation
- inline implementation assistance
- repository-level questions
- issue and task analysis
- retrospective summaries
- pull-request understanding
- repeated code changes
- GitHub workflow support
I do not see Copilot as a replacement for Claude or Codex.
I see it as another specialized team member operating close to the repository and IDE.
The likely division of responsibilities becomes:
- Claude: technical lead and orchestrator
- Codex: independent code reviewer
- Qwen3-Coder: QA, documentation, task preparation, and content
- GitHub Copilot: IDE and repository productivity assistant
Does Delegation Really Save Tokens?
The answer is more nuanced than simply saying yes.
Delegation does not mean fewer total tokens are always consumed.
Each agent uses tokens.
A Haiku scanner uses tokens.
A Sonnet builder uses tokens.
Codex uses tokens.
Claude uses tokens when reading their summaries.
However, delegation can improve efficiency in several ways.
1. The Right Model Handles the Right Task
A cheaper model can handle:
- file discovery
- repetitive searches
- documentation mapping
- test inventory
- simple summaries
A stronger model can focus on:
- architecture
- implementation
- security
- complex debugging
- final decisions
2. Context Is Isolated
The builder does not need the entire historical conversation.
The reviewer does not need every planning discussion.
The documentation validator does not need all implementation reasoning.
Each agent receives only the context required for its task.
This reduces unnecessary context processing.
3. Summaries Return to the Main Session
Instead of sending hundreds of files back to Claude, the agents return summaries such as:
- files changed
- tests passed
- risks found
- decisions made
- unresolved issues
The main Claude session can continue with a smaller context footprint.
4. Independent Review Improves Quality
Token saving alone is not the main benefit.
The larger benefit is separation of responsibility.
The builder builds.
The reviewer challenges.
The QA agent verifies.
The orchestrator decides.
This is much closer to a real engineering process than asking one model to design, implement, review, test, and approve its own work.
The Approximate Cost
My current estimated monthly setup is:
ToolPurposeApproximate monthly costClaudeMain senior developer and orchestrator$20ChatGPT/CodexIndependent code review and second engineering perspective$20Claude APIAdditional agent or automation usage$10GitHub CopilotPlanned repository and IDE assistant$10Qwen3-Coder 30B through OllamaLocal QA, documentation, and content workLocal hardware and electricity
The expected total subscription and API cost is approximately:
$60 per month, or around ₹5,800 to ₹6,000
This is my current working estimate, not a guaranteed fixed cost.
Actual costs may vary depending on:
- API usage
- plan changes
- exchange rates
- local electricity
- hardware costs
- model usage limits
Still, the economics are interesting.
For approximately ₹6,000 ($60) per month, an independent developer can assemble an AI-assisted workflow covering:
- architecture
- coding
- testing
- code review
- documentation
- pull requests
- CI monitoring
- QA planning
- task preparation
- product content
That does not eliminate the need for engineering judgment.
It increases the amount of work one experienced engineer can coordinate.
What AI Still Does Not Replace
This setup is powerful, but it is not autonomous in the way many people imagine.
A human still needs to:
- define the product vision
- understand customer problems
- challenge incorrect assumptions
- decide scope
- evaluate risk
- verify security implications
- reject unnecessary complexity
- protect production data
- approve deployments
- manage credentials
- decide what should not be built
- validate whether the product is commercially useful
AI can accelerate software delivery.
It cannot take responsibility for the business.
The human remains accountable.
My Main Learning
My biggest learning is that AI-assisted development becomes much more powerful when we stop thinking about one assistant and start thinking about a team.
Instead of asking:
“Which AI model is best?”
I now ask:
“Which model should perform this specific role?”
Claude is good at orchestration, planning, implementation, and synthesis.
Codex provides an independent technical review.
Qwen3-Coder can handle local QA, documentation, knowledge maintenance, and content workflows.
GitHub Copilot can support repository and IDE-level productivity.
The real value comes from the workflow connecting them.
Final Perspective
I am not simply using AI to generate code faster.
I am experimenting with an AI-native software engineering operating model.
The process looks like this:
Human product owner
→ defines the goal
Claude senior developer
→ plans and delegates
Haiku repository scanner
→ maps the codebase
Sonnet implementation agent
→ builds the feature
Codex senior reviewer
→ challenges the implementation
Claude
→ verifies and fixes findings
Qwen3-Coder local QA engineer
→ creates tests, runs QA, and maintains documentation
GitHub and CI
→ provide traceability and automated validation
Obsidian vault
→ preserves product and architecture knowledge
The result is not a replacement for a full professional engineering team.
But for an experienced independent engineer or product builder, it is becoming a highly capable virtual team.
And at an estimated cost of approximately ₹5,800 to ₹6,000 ($60) per month, it creates a serious opportunity to build, test, document, and evolve a production-oriented product from scratch.
That is the experiment I am continuing now.
The next challenge is to make the local Qwen3-Coder QA and documentation workflow as reliable and repeatable as the Claude and Codex development pipeline.