They Don't Let Agents Write useEffect; the Linter Blocks It

At the Day 1 workshop at the AI Engineer Code Summit, @factory's @ross_cefalu described a very concrete practice: at @factory, agents cannot add useEffect. The linter rejects it.

useEffect is the hook in React for handling side effects, and it easily introduces implicit behavior. @factory delegates this rule to the linter instead of relying on agents to follow it voluntarily. This detail is small but useful. When agents generate code, verbal standards are often ignored; only when the linter turns the rule into a hard failure will the agent change. Letting agents write code ultimately still depends on the linter as the gatekeeper.

The video comes from a tweet by @aiDotEngineer. Ross Cefalu talks about how to make opinionated code standards easier for agents to enforce. The key word here is opinionated. Standards need to be specific enough to be checked, rejected, and repeated.

But the linter also has blind spots. In the replies, IronRed mentioned that they are working on How-Could-I-Be-Hacked, with the goal of enabling agents to detect sneaky useEffects that bypass the linter. This direction fills the linter's blind spot. Rules can block the normal path, but behavior that bypasses the rules needs another layer of checking.

The description at the link is very clear: this library provides coding agents with real security investigation context for use in code review. It contains 37 anonymized cases, 113 investigation and review steps, and 475 search entries. The tool runs locally, uses Python and SQLite, and does not require an API key.

Usage is not complicated. To install the Skill, you can use:

npx skills add sandhiveio/How-Could-I-Be-Hacked --skill how-could-i-be-hacked

Then, in a repository where you have permission to review, have the agent use $how-could-i-be-hacked to review code, match cases, explain which checks apply, and turn locally confirmed issues into regression tests. You can also directly run corpus.py search to look up cases by keyword, for example, credential masking formatter.

The case catalog includes SQL injection, HTTP request smuggling, and JWT algorithm confusion, as well as prompt injection in payment, travel, calendar, and messaging workflows. Defense review examples include OIDC client-secret redaction, upload directory containment, and archive extraction containment. Each entry comes with investigation steps and evidence context and can be read directly.

Back to @factory's approach. Setting rules for agents has two layers. The first layer is to keep mistakes from being written in at all: the linter rejects them outright. The second layer is to ensure that rule-bypassing behavior has cases to consult and tests to run as regressions. The first layer relies on engineering constraints; the second relies on security context and regression tests. Only when both layers are in place does the speed of agents writing code have engineering significance.

Sources:
@aiDotEngineer's tweet
How-Could-I-Be-Hacked
Skills CLI