Noushad Hossain
CV
← All work

Autonomous coding agent: tracked task to tested pull request

A tool-calling LLM agent that takes implementation-ready tickets, implements them with tests on a feature branch, opens the pull request and reports the cost of every run.

WhereOwn tooling
When2025 – 2026
My roleDesigned and built
OwnershipSole author
Task tracker (ClickUp)status = implement, priority order, not yet processedTriggerMCP client (Claude Desktop, Cursor), CLI, or FastAPIAgent loop, bounded by iterations and a timeoutModel (Claude or OpenAI)task + repo instructions + 4 toolsTool executorbash · read · write · editCloned repositoryfeature branch, testsrepeat until implemented, tests written and green, PR openedPull request on GitHubURL and tag posted back to the task; a human reviewsCost ledger (SQLite)tokens × price per model, provider and day

What it is

An agent that takes tasks from a ClickUp list, clones the target repository, lets a model implement the change with tests, opens a pull request and posts the result back to the task. It runs as an MCP server for Claude Desktop or Cursor, as a CLI, or headless behind a FastAPI service.

The problem

A small team with a long backlog of well-specified, low-risk tickets: cutovers, small fixes, boilerplate modules. I wanted those turned into reviewable pull requests without a human babysitting an IDE session, and I wanted to know exactly what each run costs.

How it works

  • An agentic loop on native tool calling. The model receives the task, the repository's instruction file and four tools: bash, read_file, write_file and str_replace. It iterates until the change is implemented, tests are written and pass, and a PR is open. Tool output is truncated to a budget so context stays bounded.
  • A provider abstraction: Claude and OpenAI behind one interface, switched by one environment variable. The first version drove the Claude Code CLI from Node.js; the Python rewrite calls the APIs directly and needs no external binary.
  • Guard rails: priority-ordered task selection, skip when a PR already exists, a tag that prevents reprocessing, iteration and timeout limits, a dry-run mode.
  • Cost tracking: every API call records tokens and price per model, provider and day in SQLite, exposed through /costs endpoints. The cost of a PR, not just of a month.

Related: LLM-generated analytics reports

In the analytics platform I led the initiative to add AI-written narrative reports. The service embeds the platform's API documentation into Azure AI Search and uses vector search plus function calling so the model fetches property, overview and scorecard data through the platform's own authenticated endpoints before writing. The narrative is split into sections, paired with generated charts and rendered through the existing PDF report engine. I owned the product direction, the architecture and the reviews; most of the implementation was done by a team member under my lead.

What I learned

The useful unit of automation is the well-specified ticket. The per-repository instruction file and the test-before-PR rule mattered more than the model choice. Grounding a model in the same endpoints the UI uses makes every number in its output traceable to an API call.