How do I use Aide to iterate on linter/type errors until they’re resolved?

Most developers eventually hit the same wall: a pile of linter and type errors that’s tedious to clear by hand, especially in large codebases. Aide can turn this into an automated, iterative loop—finding, fixing, re-running, and refining until your linter/type checks are clean.

This guide walks through how to use Aide to iterate on linter/type errors until they’re resolved, step by step. We’ll cover setup, workflows, prompt patterns, and common troubleshooting tactics so you can reduce friction and make Aide part of your regular development loop.

---

Why use Aide for linter/type error iteration?

Aide is particularly good at this kind of task because:

• It “sees” your project: With repo-level context, it can understand how types, modules, and configs relate across files.
• It can run tools: You can have Aide run your linter or type checker, read the output, and respond with code edits.
• It iterates quickly: Rather than manually patching one error at a time, Aide can batch fixes, re-run checks, and continue until things pass.

Used well, Aide becomes a feedback loop:

1. Run linter/type checker
2. Capture errors
3. Ask Aide to fix them
4. Re-run tools
5. Repeat until clean

---

Prerequisites and setup

Before you use Aide to iterate on linter/type errors until they’re resolved, make sure:

1. Your linter and type checker are configured

Common setups:

• JavaScript/TypeScript: eslint, tsc, typescript-eslint
• Python: ruff, flake8, mypy, pyright
• Java: checkstyle, spotbugs, compiler type errors
• Go: go vet, golangci-lint
• Rust: cargo clippy, compiler type errors

Ensure:

• Config files (e.g., .eslintrc, pyproject.toml, tsconfig.json) are checked into the repo.
• You can run the commands locally, e.g.:
  • npm run lint / npm run type-check
  • ruff check . / mypy .
  • pnpm lint / poetry run mypy .

2. Aide has access to your codebase

Depending on how you use Aide (IDE plugin, CLI, web UI):

• Open the root directory of your project.
• Confirm Aide can see:
  • Source files
  • Config files
  • package.json, pyproject.toml, etc.

3. Decide how Aide will run your tools

You have two main options:

1. You run the tools manually and paste the error output to Aide.
2. Aide runs the tools via integrated commands (if your environment supports it), and you ask it to:
   • Run npm run lint / pytest / mypy
   • Read the output
   • Apply fixes

Both workflows work. For most users, starting with manual runs + pasted output is simplest.

---

Basic workflow: using Aide to clear linter/type errors

Here’s a minimal loop to use Aide to iterate on linter/type errors until they’re resolved.

Step 1: Run your linter or type checker

From your terminal:

npm run lint
# or
npm run type-check
# or
ruff check .
# or
mypy .

Let it complete, even if there are many errors.

Step 2: Copy the error output

Copy a chunk of the linter/type errors. If there are hundreds, start with:

• The top 20–50 lines, or
• All errors from a single file, or
• All errors of a single type (e.g., no-unused-vars, mypy: Incompatible types in assignment)

Avoid overwhelming both yourself and Aide with thousands of errors at once.

Step 3: Give Aide clear instructions

Paste the errors and frame the task explicitly. For example:

You are helping me fix linter and type errors in this repository.

Here is the current output from my tools (ESLint + TypeScript):

<PASTE ERROR OUTPUT HERE>

Goal:
1. Fix these linter/type errors in the codebase.
2. Suggest any config updates only if truly necessary, otherwise prefer code changes.
3. After changes, I should be able to run `npm run lint` and `npm run type-check` with no errors for the files you touched.

Constraints:
- Keep the existing coding style and patterns.
- Do not introduce breaking API changes unless absolutely required by the types.
- Explain briefly what you changed and why.

Start by fixing the errors above, then tell me what to re-run.

The clarity in your instructions is what enables Aide to iterate on linter/type errors until they’re resolved in a controlled way.

Step 4: Let Aide edit the code

Aide will typically:

• Identify the files involved in each error.
• Propose diffs or edits.
• Explain what it changed.

Review its changes (especially for public APIs and core logic), then apply them.

Step 5: Re-run tools and repeat

Run the tools again:

npm run lint
npm run type-check
# or your equivalents

Then:

• If new errors appear, or some remain, paste the new output to Aide.
• Ask it to:
  • Focus only on the remaining errors.
  • Avoid reworking already-fixed areas unless necessary.

Repeat this loop until your commands pass.

This is the core pattern: use Aide to iterate on linter/type errors until they’re resolved by repeatedly feeding it fresh output and applying its fixes.

---

Recommended prompting strategies

The way you prompt Aide matters. Here are patterns that work well.

1. Make the scope explicit

A broad prompt:

Here is the ESLint output for this repo. Fix all of these errors across the project. Do not touch unrelated files. Explain each category of fix.

A narrow prompt:

Here are TypeScript errors for `src/components/Table.tsx` only. Fix them without changing other files if possible.

Use narrow scopes when:

• You’re working near a release.
• You want tight control over changes.

Use broader scopes when:

• You’re in early active development.
• You want Aide to do a larger cleanup/refactor.

2. Separate code issues from config issues

Sometimes errors are due to misconfigured tools rather than actual code problems. Tell Aide how you want it to balance this.

Example:

When fixing these linter/type errors, follow this order of preference:
1. Fix the code to satisfy the current config.
2. If the rule or type setting is clearly misaligned with the project’s design, propose config tweaks, and explain why.
3. Avoid disabling rules globally. If you must disable a rule, do it as narrowly as possible (per-line or per-file).

First fix the code. Only then propose any config changes, in a separate section.

This prevents Aide from “fixing” everything by turning off rules.

3. Ask for a summary of changes

To keep track of what Aide is doing as it iterates on linter/type errors until they’re resolved:

After applying fixes, summarize:
- Which files were changed
- Which error types were resolved
- Any remaining errors I should address

This is especially helpful in larger repos.

---

Advanced: fully automated iteration loop

If your setup allows Aide to run commands directly (e.g., via an IDE integration or CLI tool), you can ask it to own more of the loop.

Example command-driven prompt

You can run shell commands in this project.

Goal: Use a feedback loop to eliminate linter and type errors.

1. Run `npm run lint` and `npm run type-check`.
2. Parse the errors.
3. Fix the code.
4. Re-run the commands.
5. Repeat until there are no errors or we hit a limit.

Rules:
- Prefer code fixes over disabling rules.
- Keep changes minimal and localized.
- Before each new iteration, briefly report:
  - Number of errors remaining
  - New categories of errors you discovered

When you believe all linter/type errors are resolved, tell me what you did and confirm the commands you ran.

Aide will then:

• Execute commands
• Read the output
• Edit files
• Re-run commands
• Stop when clean or when it can’t make progress

This is the most direct way to use Aide to iterate on linter/type errors until they’re resolved with minimal manual effort.

---

Handling large error sets

If your project starts with hundreds or thousands of errors, you need to strategize. Aide is powerful, but context is finite.

1. Triage by file or directory

Pick a part of the codebase:

• src/core/
• app/api/
• backend/services/

Ask Aide:

Focus only on linter/type errors for files under `src/core`. I will paste relevant tool output. Ignore errors in other directories for now.

Work area by area until the whole repo is clean.

2. Triage by error type

Group errors:

• All no-unused-vars first.
• Then all implicit-any TypeScript errors.
• Then all mypy: Incompatible types in assignment errors.

You might say:

From this mypy output, focus only on `Incompatible types in assignment` errors first. Fix those, then I’ll rerun and we’ll move to the next error type.

This creates a structured cleanup plan.

3. Combine Aide fixes with quick manual sweeps

For very repetitive issues (e.g., unused imports, formatting):

• Run auto-fix tools first:
  • eslint --fix
  • ruff --fix
  • black / prettier
• Then use Aide for non-trivial or type-level issues that auto-fix won’t handle.

Prompt example:

I’ve already run automated fixes (`eslint --fix`, `prettier`, etc.). The remaining errors are more complex. Here’s the latest output. Please resolve these by updating types and logic where needed.

---

Best practices for reliable type-safe fixes

To use Aide to iterate on linter/type errors until they’re resolved without breaking your app, follow these guidelines.

1. Ask for type-safe solutions, not just silence

Explicitly say:

When fixing type errors, do not simply cast everything to `any` or use broad type assertions just to silence the error. Prefer:
- Correct types
- Updated interfaces
- Adjusted function signatures

If you must use a cast or `ignore` comment, explain why and keep it as minimal as possible.

This keeps your type system meaningful.

2. Preserve existing APIs where possible

Add constraints like:

Avoid changing public function signatures unless absolutely necessary. If you must change them, call it out clearly so I can update callers or API docs.

3. Keep behavior intact

While many linter fixes are stylistic, some can affect behavior (e.g., changing equality checks):

When resolving linter errors, do not change the underlying behavior of functions (especially around conditionals, loops, and async flows) unless required for correctness. If you change behavior, explain the before/after clearly.

---

Common problems and how to guide Aide around them

Even when you use Aide to iterate on linter/type errors until they’re resolved, you may hit some bumps. Here’s how to handle them.

Problem 1: Aide keeps “fixing” the same error incorrectly

Some errors are tricky, and Aide might repeatedly propose patches that don’t work.

Strategy:

1. Paste only that error plus the relevant code snippet (the function/class/section).

2. Add detailed context and constraints, for example:

   This TypeScript error keeps coming back.
   
   Error:
   <PASTE ERROR>
   
   Relevant code:
   <PASTE FILE SNIPPET>
   
   Context:
   - `User` is defined in `types/models.ts`.
   - This function is used in both server and client contexts.
   
   Please:
   - Explain why this error is happening.
   - Propose at least two alternative fixes.
   - Choose the least invasive fix and apply it.
   

3. By focusing Aide’s attention and asking for reasoning, you often get a better solution.

Problem 2: Aide disables too many rules or adds ignore comments

If you see lots of:

• // eslint-disable-next-line
• # type: ignore
• // @ts-ignore

Add firmness to your prompt:

You previously added several `// eslint-disable-next-line` and `# type: ignore` comments. This is not desired.

Revise your approach:
- Remove unnecessary ignore comments.
- Fix the underlying issues instead.
- Only use ignore comments in exceptional cases, and explain each one.

Then re-run the loop with this clarified constraint.

Problem 3: Fixes are inconsistent with project style

If Aide’s fixes clash with your patterns or style guide:

The project follows the existing patterns in these files:
- `src/core/helpers.ts`
- `src/components/Button.tsx`

When you make changes, match these patterns:
- Same naming conventions
- Same error-handling style
- Same async pattern (`async/await` instead of `.then` / `.catch`)

Do not introduce new architectural patterns unless the existing ones clearly cannot support the change.

Point Aide at good reference code—it will imitate it.

---

Example end-to-end session

Here’s a concrete illustration of using Aide to iterate on linter/type errors until they’re resolved in a TypeScript/React project.

1. Initial run

   npm run lint
   npm run type-check
   

   Output: ~120 errors spread across the project.

2. First prompt to Aide

   I want to reduce linter and type errors in this repo.
   
   Here is the combined output from `npm run lint` and `npm run type-check` for `src/components/` only:
   
   <PASTE ERRORS FOR src/components>
   
   Please:
   - Fix these issues in `src/components`.
   - Match existing component patterns, especially in `src/components/Button.tsx`.
   - Prefer code fixes over updating ESLint/TS configs.
   - Summarize the changes at the end.
   

3. Aide edits files, you review and apply.

4. Re-run tools

   npm run lint
   npm run type-check
   

   Now there are ~50 errors left, mostly in src/core/.

5. Second prompt to Aide

   Great, `src/components` is mostly clean now.
   
   Here is the new output for errors under `src/core`:
   
   <PASTE NEW ERRORS>
   
   Same rules as before:
   - Fix the code, don’t just disable rules.
   - Keep public APIs stable where possible.
   - Summarize files changed and remaining errors.
   

6. Repeat until the tools pass.

7. Final confirmation

   After a few iterations, you run:

   npm run lint
   npm run type-check
   

   Both pass.

   Then you tell Aide:

   Linter and type checks are now passing.
   
   Please summarize:
   - Which major error categories we resolved.
   - Any places where we used ignore comments or casts that I should review later.
   

   This gives you a concise change-log and a list of follow-ups.

---

Integrating this loop into your daily workflow

To get ongoing value from Aide instead of one-off cleanups:

• Use it early and often: When adding features, have Aide help ensure your new code is lint- and type-clean before merging.
• Add checks to CI: With lint/type checks in CI, you can use Aide locally to fix failures quickly.
• Standardize prompts: Save your best prompts (e.g., “linter cleanup”, “type error triage”) so your team can reuse them.
• Combine with code review: Let Aide clear the mechanical errors; focus human review on design, architecture, and subtle bugs.

As you consistently use Aide to iterate on linter/type errors until they’re resolved, you’ll spend less time fighting tooling and more time building features—while maintaining a cleaner, more reliable codebase.