Your Coding Agent Keeps Breaking ESLint
Your Coding Agent Keeps Breaking ESLint
The agent fixes the bug, then reformats three unrelated files, invents an import order, and adds an ESLint suppression. You spend longer cleaning the patch than reviewing the logic. In 2026, the useful approach is not a longer prompt about clean code. It is giving the agent the same executable contract your editor and CI already use.
Make package scripts the formatting contract
Start with the repository, not the model. Commit formatter and linter configuration, pin tool versions through your lockfile, and expose predictable commands. In a JavaScript project, that might mean npm run format:check for prettier --check ., npm run format:write for prettier --write ., and npm run lint for eslint . . Keep checking and rewriting separate so the agent knows which commands mutate files.
Document the correct working directory, package manager, and setup command. A monorepo agent running the wrong package script can produce perfectly formatted code under the wrong rules. Match the CI commands instead of creating a second, agent-only definition of correctness.
Put executable rules in the agent's instruction file
Use the repository instruction mechanism your client actually reads, such as AGENTS.md, CLAUDE.md, or GEMINI.md. Check that client's current discovery and directory-scoping behavior; these files are not universally interchangeable. Keep shared guidance consistent, and put package-specific exceptions close to the affected code.
- Use the repository's pinned tools instead of installing global alternatives.
- Format only changed files unless the task explicitly requires broader cleanup.
- Never weaken lint rules or add suppressions without explicit approval.
- Run the documented checks and report their actual exit status.
- Preserve unrelated edits and stop when ownership of changes is unclear.
Include concrete commands rather than saying follow existing style. Name generated directories, vendor code, and files that must not be rewritten. Keep secrets out of instruction files, and remember that instructions guide behavior; they do not enforce it.
Give the agent a short repair loop
My task prompt usually ends with: implement the smallest change, format the touched files, run lint and relevant tests, inspect the diff, and summarize anything still failing. That sequence is easier to follow than a paragraph of stylistic preferences.
Ask the agent to establish a baseline before editing when the repository's health is uncertain. Existing lint failures should be recorded, not silently repaired across the tree. After editing, feed actual diagnostics back into the next attempt. File paths, rule names, and line numbers are better repair inputs than make it cleaner.
Allow a bounded number of repair attempts. If checks keep failing, require a concise blocker report instead of endless edits. If dependencies or sandbox permissions prevent execution, the agent should say not run, not passed.
Use hooks for feedback and CI for enforcement
A client hook can run targeted checks after file edits, while a pre-commit hook can catch mistakes before a commit. Treat both as feedback layers: hook support varies, local hooks can be skipped, and concurrent formatter processes can race. Prefer one clear formatting owner rather than having the editor, agent, and watcher rewrite the same file simultaneously.
CI remains the merge gate. Run non-mutating formatting checks, lint, and appropriate tests there. Before accepting the patch, inspect git diff --check and the full diff. Passing tools do not prove the agent avoided unrelated changes or preserved behavior.
Keep the formatter contract stable across Fluxo models
When trying Claude Sonnet 5.5 or GPT-6.1 Sol through Fluxo, keep the repository commands unchanged. Fluxo provides one key and one base URL, https://api.fluxorelay.com, for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK; client-specific instruction loading and hooks still need verification.
Fluxo bills per real token, including cache reads and writes, with no monthly fee, so watch repair-loop usage rather than assuming retries are free. Users also earn a referral share when people they invite pay. If you want to try this workflow with your existing terminal tools, you can create a Fluxo account.
The win is a boring patch: small diff, unchanged rules, reproducible checks, and an honest report. Make that the acceptance criterion, regardless of which model writes the code.