Cygent Code

The coding agent. Plan, approve, execute, iterate — fix findings, build features, open PRs from chat.

Overview

Cygent Code is the coding agent. It plans changes, writes code, runs the build to verify, and opens a pull request — all from a chat conversation in Slack, Discord, or Telegram. It is the bridge between "Cygent found a bug" and "the bug is merged out."

Where CARA is the brain that finds vulnerabilities, Cygent Code is the hands that fix them. And it doesn't stop at fixes — it can build entire new features, scaffold new projects, refactor contracts, write tests, or update dependencies.

What Cygent Code handles

Fix audit findings

Remediate security issues CARA found — one at a time, in bulk, or by severity ("fix all High findings in Vault.sol").

Build new features

Implement new functionality from a natural-language description. Contracts, frontends, API endpoints, tests.

Refactor & improve

Restructure code, add test coverage, improve gas efficiency, update dependencies, rename things consistently.

Create new projects

Scaffold entirely new codebases — a starter contract, a foundry project, a Next.js frontend — from a single prompt.

Explore repositories

Read-only: analyze project structure, summarize dependencies, answer questions about how the code works without making changes.

Combine actions

Chain multiple steps in one request: "create a GitHub issue and open a PR for finding H-1."

The plan-approve-execute loop

Cygent Code does not write code on impulse. Every non-trivial task runs through a four-stage loop, and the loop is the reason the PRs it opens are safe to merge.

Request

You ask Cygent in natural language. @cygent fix the oracle staleness bug or @cygent add a withdrawal pause switch to Vault.sol. No special syntax.

Plan

Cygent generates an implementation plan — files it'll touch, functions it'll modify, new types, tests it intends to write. The plan is posted back to you before any code is written.

Review

You read the plan. If it's right, approve. If it's close but not right, push back in the same thread — "use a mapping instead of an array", "don't change the public interface", "also update the natspec". Cygent updates the plan.

Execute

Once approved, Cygent writes the code, runs the build (and tests, if they're wired up) to verify, and opens a pull request with a clear description.

Iterate

The thread stays live after the PR opens. Push follow-up instructions — also add a natspec comment, rename that variable — and Cygent adds commits to the same PR.

💡

For trivial tasks you trust Cygent to get right on the first try — typo fixes, rename-a-variable — skip planning by saying "just do it, no plan needed." For anything that changes protocol behavior, always plan first.

Example — Oracle staleness fix

The canonical Cygent Code demo walks through this exact flow on a lending protocol called GhostLend.

The finding: CARA identified that PriceOracle.sol fetches prices from Chainlink but doesn't check if the price is stale. An attacker could exploit a stuck oracle to borrow against outdated valuations.

The request: in Slack, someone types:

@cygent make a PR to fix the oracle staleness bug

The plan: Cygent replies with something like the plan above, plus the specific file paths and a confirmation that it won't change the external function signatures.

The execution: on approval, Cygent writes the change, runs forge build and forge test to confirm nothing regresses, and opens a PR. The PR description cites the finding ID and explains the fix.

The merge: a human reviewer reads the PR (it's a small, targeted diff) and merges. CARA's next audit on that branch shows the finding as Resolved.

From "found the bug" to "merged the fix" — minutes, not a week of back-and-forth.

Example — Catching a human PR

Cygent Code isn't only for fixes Cygent proposes. It also reviews PRs humans write — and catches things humans miss.

The scenario: a developer on the GhostLend team opens a PR to support additional tokens as collateral. The new function looks like:

/// @notice Register a new token for use as collateral.
function addSupportedToken(address token, address priceFeed) external {
    supportedTokens[token] = priceFeed;
    emit TokenAdded(token, priceFeed);
}

The catch: within a minute, Cygent's automatic PR review flags this as CRITICAL. The function has no access control modifier. Anyone — not just the owner — could call addSupportedToken with a fake token and a fake price feed, then drain the protocol by borrowing against the "collateral" at an attacker-controlled price.

The fix: Cygent suggests the missing onlyOwner modifier, and (if you're running Autonomous mode) will open a follow-up PR applying the fix. Even in Balanced mode, the reviewer sees the inline comment before the PR merges, and nobody ships a protocol-draining bug on accident.

ℹ️

This is the kind of thing a linter won't catch and a CI security check won't catch — they don't know what "access control for token registration" means in the context of your protocol. Cygent does.

See PR review comments for how automated reviews work end-to-end.

Referring to findings

Cygent Code is forgiving about how you refer to findings. You don't need to memorize IDs.

How you refer	Example
By ID	`fix finding H-1`
By keyword	`fix the reentrancy finding`
By natural language	`fix all findings related to claimReward`
In bulk	`fix all High findings in Vault.sol`
Contextually	`fix that one` (in a thread discussing a specific finding)

⚠️

Bulk operations still go through planning. Cygent will post a consolidated plan for all the fixes and wait for approval — it will not push ten commits without your nod.

Combining actions

A single prompt can trigger multiple actions. This is where the agent shines compared to a "fix a single finding" tool.

@cygent create a GitHub issue and open a PR for finding H-1 — files the issue, opens the PR, links them.
@cygent review PR #42 and if it looks clean, summarize it for #engineering — two conditional actions chained.
@cygent fix the oracle staleness bug and the transient storage bug, in separate PRs — two PRs, tracked separately.

The limit is what reads naturally as an instruction. If you can describe the task to a human engineer, you can describe it to Cygent Code.