February 2026
Your product is not your application, it's your LLM development pipeline.
System X
A theory: You used to write application code, CRUD ORM configuration, Frontend, APIs and API integrations. Your new job is to write the infrastructure to enable LLMs to reliably and repeatably do this for you.
Your software businesses fundemental goal is to produce useful, quality software. Your customers are unlikely to care who wrote the code.
They do care about utility, usability, dependability, speed, security (and cost).
We used to work on software System X, that does Y, for Customer Z.
We now work on a software system powered by LLMs that builds that System X.
I concede, this era will be short-lived compared to the SaaS software epoch of 2000-2025, but let’s do a good job of it for however long it lasts.
Claude Caude and Codex and OpenCode are (currently) too Generic
Claude Caude and Codex are broad-strokes, generic tools for writing software. They are essentially terminal and Web UIs built over LLM APIs configured with best-guess, most-useful tool calls . Each session is stored in a database.
Yes, there is a case to be made that with enough Claude.md files, MCP servers, plugins and skills they can be tailored to your specific use-cases, but in my experience so far the fine-tuned guidance required for production grade is still not present in these cobbled together systems.
A good next step for engineering teams would be to build their own agent wrappers bespoke to their application, tech stack, workflow practices, and professional culture.
You can read Claude Code’s default tools in full here , but roughly they look like:
File Operations:
- Read - Read files from the filesystem
- Write - Create or modify files
- Edit - Apply targeted edits to existing files
Search & Discovery:
- Grep - Powerful content search using ripgrep to find text/code patterns
- Glob - Fast file pattern matching to find files by name patterns
Execution:
- Bash - Execute shell commands in a persistent bash session (git, npm, docker, pytest, etc.)
- BashKill - Terminate running background bash shells
Task Management:
- TodoWrite - Create and manage task lists for complex work
- TodoRead - Read existing task lists
Web Fetch
- Fetches content from a specified URL and processes it using an AI model
- Takes a URL and a prompt as input
- Fetches the URL content, converts HTML to markdown
Advanced:
- Task - Launch specialized sub-agents for complex, multi-step autonomous tasks
- SlashCommand - Execute slash commands within conversations
Building your product with Claude Code Company Coder
Now let’s imagine you have a product built on Python & Django, Vue, Postgres, Lima VMs, AWS, and managed with JIRA.
As a team we start working on a bespoke Agent, built on top of something like Vercel’s AI Agent SDK, with tools tailored to our stack and workflows.
What’s rewarding and valuable about how it captures developer’s knowledge and experience of their product and force-multiplies. Your bespoke Agent, assembled by the people that know your software best, will always beat a generic tool.
The LLM spends less time in each session searching and discovering your codebase and toolset, or repeating and fixing mistakes, and more time working within tightly defined constraints that most organisations already have - even if they weren’t codified.
In our new tool, along with the generic tools like read/write file and bash in Claude Code/Codex/OpenCode describe above, we’d configure precision tool for:
Atlassian Suite:
- JiraIssue - Fetch, create, update, transition Jira tickets
- JiraSearch - Query Jira with JQL for relevant issues
- JiraSprint - View sprint status, backlog, velocity
- JiraComment - Add comments and tag teammates
- JiraWorklog - Log time against tickets
Bitbucket:
- BitbucketPR - Create, review, merge pull requests
- BitbucketBranch - List, create, checkout branches
- BitbucketDiff - View diffs between branches
- BitbucketReview - Request reviews, respond to comments
- BitbucketPipeline - View pipeline status for current branch
Core AWS:
- EC2Instances - List, inspect EC2 instances by environment
- RDSStatus - Check RDS database status and metrics
- S3Bucket - List/upload/download from S3 buckets
- CloudWatchLogs - Stream and search application logs
- IAMPolicy - Review IAM roles and permissions
Deployment:
- CodeBuildStart - Trigger builds for specific branches
- CodeBuildStatus - Monitor build progress and logs
- CodeBuildHistory - View recent build history
- ECSTask - Check ECS task status and health
- ECSLogs - Stream container logs
Local VM & Environment:
- LimaVM - Manage Lima VMs
- LimaExec - Execute in Lima instances
Database:
- PostgresQuery - SQL queries
- PostgresSchema - Schema inspection
- PostgresMigrations - Migration management
- PostgresExplain - Query performance
Frontend:
- WebpackBuild - Webpack compilation
- SassCompile - SASS processing
- VueComponent - Component scaffolding
Backend:
- DjangoManage - Django management
- DjangoMigrate - Migrations
- DjangoShell - Interactive shell
- DjangoTest - Test execution
Psuedocode Configuration Example
{
"integrations": {
"jira": {
"base_url": "https://yourcompany.atlassian.net",
"project_key": "PROJ",
"default_board": 123
},
"bitbucket": {
"workspace": "yourcompany",
"repo_slug": "main-app",
"default_reviewers": ["team-leads"]
},
"aws": {
"region": "us-east-1",
"profile": "dev",
"environments": {
"dev": "dev-stack",
"staging": "staging-stack",
"prod": "prod-stack"
}
},
"codebuild": {
"project_name": "main-app-build",
"notify_on_failure": true
}
},
"workflows": {
"new_feature": [
"JiraIssue → fetch story details",
"BitbucketBranch → create feature branch",
"DjangoMigrate → DB changes",
"VueComponent → UI work",
"DjangoTest → run tests",
"BitbucketPR → create PR",
"CodeBuildStart → trigger build"
],
"debug_production": [
"JiraIssue → check bug ticket",
"CloudWatchLogs → search error logs",
"RDSStatus → check DB performance",
"EC2Instances → verify instance health",
"BitbucketBranch → create hotfix"
],
"deploy_staging": [
"BitbucketPipeline → check branch status",
"DjangoTest → full test suite",
"CodeBuildStart → trigger staging build",
"CodeBuildStatus → monitor deployment",
"ECSTask → verify deployment health"
]
}
}Intelligent Workflow Examples
Our Company Coder can now answer queries with a laser focus and prior-knowledge of workflows embedded via the tool definitions and system prompts:
“I need to work on PROJ-1234”:
- JiraIssue → fetch ticket details, acceptance criteria
- BitbucketBranch → create branch
feature/PROJ-1234-description - Read → check relevant existing code
- Edit → make changes
- DjangoTest → run affected tests
- BitbucketPR → create PR with Jira link
- JiraComment → update ticket with PR link
- JiraIssue → transition to “In Review”
“Deploy my changes to staging”:
- BitbucketPR → check PR is merged
- DjangoTest → run full test suite
- CodeBuildStart → trigger staging build
- CodeBuildStatus → monitor build progress
- ECSTask → verify new tasks are healthy
- CloudWatchLogs → check for errors
- JiraComment → update ticket “Deployed to staging”
“Production is down!”:
- CloudWatchLogs → search for errors (last 15 min)
- RDSStatus → check database connections
- EC2Instances → verify instance status
- ECSTask → check container health
- JiraIssue → create incident ticket
- BitbucketBranch → create hotfix branch if needed
Psuedocode Permission Model
{
"permissions": {
"jira": {
"create_issues": "allow",
"transition_issues": "allow",
"delete_issues": "ask"
},
"bitbucket": {
"create_branches": "allow",
"create_prs": "allow",
"merge_prs": "ask",
"delete_branches": "ask"
},
"aws": {
"read_only": "allow",
"codebuild_trigger": "ask",
"ec2_actions": "deny"
}
}
}Now every single session an LLM starts is equipped with a comprehensive map of your organizational and application architecture, and using a provider-and-model-agnostic SDK, new models can be swapped out with ease when the latest Kimi, OpenAI or Claude model is released.
A fun thought: Instead of storing sessions in a database, we could store session as markdown records in the codebase itself. Plans store in plans/feature-name.md, write-ups post implentation as Architectural Design Records in adrs/branch-name.md or adrs/commit-hash.md , following the ethos of entire.io.
With the agent stored in version control, the entire team iterates on the Agent’s capabilities, adding new tools, refining prompts, improving the existing [guardrails](link to COMPUTED blog): tests, linters, typecheckers, visual diffing etc, so that our Company Coder can use them more efficiently.
Our agent can be deployed into the cloud and run in parallel, or individual engineers can run it locally. Your team might decide to write their own orchestrator agent too, that co-ordinates teams of our Company Coder agent.
“I don’t want to build my own agent”
Totally fair. Get started on going specific with something like Claude Code’s custom tooling. Build an MCP server using their SDK - configured with the key tools that constitute your workflow and represent the details of your stack: https://platform.claude.com/docs/en/agent-sdk/custom-tools . (But beware vendor lock-in.)
I’ve developed with this pattern myself, and alongside implementing the COMPUTED framework of guardrails [LINK] - I now have an agent that’s built a modern, zero-lag frontend replacement for JIRA without a single line of code being handwritten: https://airj.dev