Best Practices

Five patterns that turn Cygent Code from 'sometimes useful' to a daily driver.

Overview

Cygent Code is good out of the box. It gets dramatically better when you prompt it the way you'd brief a junior engineer — with scope, constraints, and intent. These five patterns are the ones customers who get the most out of the product use instinctively.

Plan first

For anything that changes protocol behavior, ask for a plan before you ask for a PR. Every time.

@cygent plan how to add a pausable withdrawal switch to Vault.sol

You get back an implementation plan — files touched, functions modified, storage changes, tests. You either approve, or you push back on specifics before any code gets written.

This pattern is load-bearing. Cygent Code's plans are cheap to iterate on — "use an enum instead", "keep it compatible with existing callers", "don't touch the initializer". Iterating on a plan takes seconds. Iterating on a PR means re-running the build, re-pushing commits, re-reviewing the diff.

@cygent rename `amt` to `amount` in Vault.sol, no plan needed

Scope specifically

Vague prompts get vague results. Every specific detail you give Cygent is a constraint it doesn't have to guess at.

Less effective:

@cygent fix the high findings

More effective:

@cygent fix finding H-1 in Vault.sol. Don't change the public interface.
Keep it Solidity 0.8.19 compatible. Add a test covering the revert path.

Every detail in that second prompt pays off. Cygent knows which finding, which file, and the three non-negotiable constraints. You won't get a PR that refactors an unrelated function or bumps the pragma.

Scope anchors that work

Iterate in the thread

The same Slack/Discord/Telegram thread that started a Cygent Code session is the iteration surface. Don't start a new thread to ask for changes to the PR — reply in the existing one.

Initial PR opens. You review it, it's 90% right. In the same thread:

@cygent looks good, but rename `MAX_HB` to `MAX_HEARTBEAT` and add a comment
explaining where the 3600-second value comes from.

Cygent pushes a new commit to the same PR with those changes. No context lost, no re-briefing needed.

This is different from most AI coding tools — Cygent Code keeps the full thread as context, so referring to "the PR" or "that fix" or "the thing you just changed" just works.

Combine actions

Cygent Code handles multi-step prompts natively. Use them when the steps logically belong together.

@cygent create a GitHub issue for finding H-1 with the full context,
then open a PR that fixes it. Link the issue in the PR description.

@cygent review PR #42 for access-control issues. If it's clean, approve
it and summarize the changes for #engineering. If it's not, leave the
findings as inline comments.

@cygent fix the oracle staleness bug and the transient storage bug,
in two separate PRs.

Combining actions is more reliable than firing three independent prompts back-to-back, because Cygent has the full intent in one context and can sequence the work correctly.

Use as a second opinion

Not every request needs a PR. Cygent Code is also a read-only analyst when you want one.

Before deciding whether a finding is valid:

@cygent explain finding M-3. Is it actually exploitable given that we
only support WETH and USDC as collateral?

Before committing to an architectural decision:

@cygent what are the trade-offs between using a mapping vs an array
for the supported-tokens allowlist? Consider gas and admin operations.

Before merging a human's PR:

@cygent read PR #42 and tell me what the worst thing in this diff is.

Cygent has the full context of your codebase, your past decisions, and the finding backlog. It's a competent second opinion — use it before you commit to a direction, not after.

When Cygent Code is the wrong tool

Cygent Code is a coding agent, not a consulting service. A few situations where reaching for it isn't the right move:

Related