What you can hand to Jigward, and what stays with your team

A backend engineer sees a message in the team’s Slack channel: rides booked after midnight cost ten times what they should. They reply in the thread, “@Jigward can you find out why and fix it?”, and go back to what they were doing.

Jigward reads the thread, takes the request on as a Task and replies with its link. It reads the repository, writes a test that reproduces the wrong price and sees it fail, changes the code in an isolated workspace, and runs the repository’s own checks. Then it opens a draft pull request and posts its report in the same thread: what it found, what it changed, what it decided and how it checked. The engineer reviews the pull request and merges it, or asks for changes in a review.

The company in that example is Orbit Cab, a made-up cosmo-taxi company the site’s examples use. The steps are the ones Jigward takes today.

What you can ask it to do

Jigward is an AI engineering coworker: one colleague for the whole organization, reached wherever the team already works. People ask it to:

• Investigate a bug and fix it. It reproduces the bug with a test first, then fixes the code and proposes the change as a draft pull request.
• Answer a question about the code. In a private Chat, it reads the repositories, the database schema their migrations build and their API before it answers, and lists what it read.
• Review a pull request when someone with write access asks. The review is comments, never an approval.
• Check the app in a real browser, sign in with a stored profile, and keep a recording, console log and screenshots.
• Look through logs in AWS CloudWatch Logs, in the log groups an admin allowed.
• Keep an eye on something on a schedule, such as a channel before stand-up or a pull request waiting for review.
• Build a small internal tool for the team, with a page and data of its own.

Each piece of work is a Task: a request in your own words that Jigward works through to a report. You can give one on the web, from a Chat, in a Slack thread, by assigning a Jira issue, on a GitHub pull request, from a scheduled check or from a team tool’s page. It is the same Task wherever it came from, and the report goes back there.

What comes back

Every piece of work ends with a report written for the person who asked. It says what Jigward found and on what evidence, what it changed, what it decided and why, and how it checked the result. A change arrives as a draft pull request. Things it noticed on the way that were not part of the request sit under their own heading, “Also noticed”. The next step it could take is offered, never started.

The report carries Jigward’s own verdict: Done, Partly done or Blocked. That verdict is Jigward’s word, not a check. A report that says Partly done or Blocked never reads as a success, and the person reading the report decides whether the work is what they asked for.

Where reasonable choices differ, Jigward records what it chose, what settled it and what that rests on. A decision that rests only on its own judgment is shown as exactly that, so anyone who disagrees can see what to undo.

What stays with people

Jigward acts only through the integrations your organization connected. Some decisions are never its to make:

• Merging. Jigward opens its own changes as draft pull requests and never merges them. The Task waits as Awaiting code review until a person merges.
• Approving or blocking a pull request. Its reviews are comments. Approving and requesting changes stay with the people who own the repository.
• Closing work in Jira. The status of an issue assigned to Jigward follows the work, but Jigward never moves it to Done.
• Questions it cannot answer responsibly. When a change would lose or rewrite data people already use, when a request reads two incompatible ways, or when it lacks access, Jigward stops and asks one question, with two to four options or room for your own words.

Everything else it decides as a colleague would, and says what it decided. There is no approval step in front of its work. A member can stop a Task at any time, from the web or from the channel it came from. Stopping keeps what was done so far and does not undo what already happened outside Jigward, such as a pull request it opened.

Why a coworker, and not a tool

Most AI development tools sit next to one developer. Jigward belongs to the organization instead. Everyone in it works with the same Jigward, in every place the team reaches it, and a Task an analyst shaped in a Chat is there for every engineer working on that product.

The work is divided into Contexts. A Context is one lasting area of work, such as a product’s backend, with its repositories, its Tasks and what Jigward knows about it. Contexts divide the work, not the people: every member can reach every Context.

A colleague who forgets everything after each conversation is not much of a colleague. When the work settles something about the product, Jigward keeps it for the Context as a small statement with where it came from and when. A newer statement replaces an older one, and nothing remembered is rewritten. When a person leaves the organization, what they worked on stays with it. There is no screen yet where a member reads that memory directly.

Who it is for

The product is built for Software Engineers, Tech Leads, Business Analysts, QA Engineers and Engineering Managers. An engineer hands over a fix. An analyst works a request out in a Chat before it becomes a Task. A QA engineer asks which table holds a record or what an endpoint accepts, and the answer comes from the schema and API documents Jigward read from the repository.

It works with repositories in any language, and is tuned most deeply for Java, Kotlin, Spring Boot, Gradle and Maven on the backend; Angular, React and Vue on the web; and npm, pnpm and Yarn for packages.

Where it stands today

Jigward is in closed testing. Registration is closed: a new organization’s first account is created by hand, and an invitation creates the account of the person invited.

Part of what Jigward is designed around is not built yet, and I would rather say so here. The clearest example is the workspace: repository code that runs there still reaches the public internet directly. Isolating it is designed and not yet applied. No certification or attestation is claimed.

The three guides below walk through a Slack request, a browser check and a small internal tool step by step. How Jigward works explains the ideas behind them.