If you've ever stared at a wall of linting errors at the end of a sprint, you know the drill. Fix one, see three more. It's tedious work that eats into time you could spend on actual features. A new post on blog.blundellapps.co.uk explores whether AI can take over this grunt work automatically—and the answer is more interesting than you might expect.
The concept is straightforward: feed your static analysis output to an AI model, let it generate the fixes, and apply them like any other code patch. But as with most things in development, the reality comes with caveats.
What the Post Actually Does
The experiment centers on a Python script that hooks into Google's Gemini API. Here's what it does:
- Collects output from detekt (a popular static analyzer for Android/Kotlin projects)
- Gathers the git diff showing recent changes
- Grabs the full content of files flagged with errors
- Sends all of this to Gemini and asks for a unified diff back
The example used is a classic pain point: a ReportGenerator function that has grown too long. Instead of manually breaking it into smaller methods, the AI analyzes the code, spots the LongMethod violation, and returns a diff that splits the logic into four separate private functions. You then apply it with a standard git apply command.
That flow works. Gemini can read the code, understand the problem, and produce syntactically correct refactoring suggestions.
The Real Bottleneck Nobody Talks About
Here's where it gets interesting for anyone working with large codebases. The post highlights a limitation that trips up most "dump everything to the AI" approaches: context windows.
Think of an AI model's context window as its short-term memory. It can only "see" a certain amount of text at once—measured in tokens, which are fragments of words or code. For most models, this becomes a problem fast. GPT-4 Turbo maxes out around 128,000 tokens. Claude 3.5 sits at 200,000 tokens. For a medium-sized Android project with multiple files flagged by detekt, you hit those walls quickly.
Gemini 2.5 changes the equation. Its 1 million token context window gives you breathing room to send substantial context without pruning everything down to useless fragments. This is a genuine advantage for this specific use case.
The script the post describes tracks token usage as it builds the context, ensuring you stay within limits.
Where It Breaks Down
Here's the honest part: AI-generated diffs don't always apply cleanly. The post ran into issues with incorrect line numbers, non-matching code chunks, and stray whitespace that caused git apply to fail.
This isn't a Gemini-specific problem. It happens with any LLM generating diffs, and it gets worse as the changes grow more complex. The more the model tries to fix at once, the higher the chance something goes sideways during application.
The proposed solution mirrors how a human developer would react: when a big patch fails, isolate the problem. The post sketches out a "divide and conquer" approach where if a unified diff fails, the system breaks it down and tackles smaller pieces individually until they apply cleanly.
There's also an alternative architecture worth considering. Rather than sending everything upfront, an agent-style approach lets the AI ask for specific files and context as needed. This is more lightweight and potentially more reliable for sprawling codebases, though it requires a more complex implementation.
Who Should Care About This
Android/Kotlin developers** working with detekt or similar static analyzers will find the closest match to what's described. The workflow translates to other linters (Checkstyle, ESLint, Pylint), but the implementation details skew toward JVM-based projects.
DevOps and platform teams** evaluating AI-assisted CI pipelines should note the practical constraints. Automating fix generation for large batches of violations is viable, but you need retry logic and human review gates built in from the start.
Teams with smaller codebases** can likely use the "one injection" approach as-is. For larger organizations with sprawling repositories, the agent-style or chunked processing strategies become necessary.
Our Analysis
This experiment sits at an interesting intersection of AI capability and developer workflow. The "one injection" approach works best for small-to-medium projects where context stays manageable. For larger teams, the agent-style approach or aggressive chunking becomes necessary—and arguably more resilient, since the model requests files as needed rather than receiving everything upfront.
What matters most is framing. This isn't about replacing code review. It's about handling the boring, predictable violations so reviewers can focus on logic and architecture. That distinction determines whether your team adopts this as a productivity tool or abandons it as automation theater.
Gemini's 1 million token window is a real advantage right now, but it's a temporal edge. Competitors will catch up. The more durable question is whether your team has the infrastructure to handle diff-rejection scenarios gracefully—because they will happen, regardless of which model you're using.
The practical recommendation: start with straightforward violations (naming conventions, method length, simple refactors) before attempting complex cross-file changes. Let the workflow prove itself on low-risk issues before trusting it with architectural decisions.
Bottom Line
AI-assisted linting is viable today, but it's not fire-and-forget. Gemini's context window gives it a real advantage for handling substantial static analysis outputs in one shot. The workflow—collect context, generate diff, apply with git—works for straightforward violations. For complex refactoring across many files, expect to need fallback strategies like chunked processing or agent-style file-by-file requests.
If you're managing an Android or Kotlin codebase with regular static analysis debt, this approach is worth evaluating. Just don't skip the human review step.
Key takeaways
- Gemini's 1 million token context window handles substantial static analysis output in a single request, unlike competitors with smaller limits
- AI-generated diffs require human review before merging—expect occasional application failures that need fallback handling
- The "one injection" approach works best for smaller projects; larger codebases benefit from agent-style or chunked processing strategies
- Automating repetitive lint fixes can free developer time for higher-value architectural and logic work
- Build retry logic into any automated linting pipeline to handle cases where generated diffs fail to apply cleanly
Frequently asked questions
Can I use this approach with tools other than detekt?
Yes. The core idea—feeding static analysis output to an AI and receiving a diff back—works with any linter that produces structured error output, including Checkstyle, ESLint, or Pylint. You'll need to adjust the script to parse your specific tool's format.
Do I need to use Gemini, or will other AI models work?
Other models work, but they face tighter context window limits. Running the same workflow with GPT-4 or Claude means you'll hit token limits faster and need to chunk your processing more aggressively.
Is it safe to automatically apply AI-generated code changes?
No—human review is essential before applying any AI-generated diffs to your codebase. The post documents cases where generated diffs failed to apply due to line number mismatches or whitespace issues.
What's the main advantage of the agent-style approach over the one-shot method?
The agent approach is more scalable for large codebases because the AI requests specific files as needed rather than receiving everything upfront. This reduces token usage and allows the model to make broader cross-file decisions.
Does this replace needing static analysis in my CI pipeline?
Not at all. This workflow complements your existing CI static checks by automating the response to violations. The linting still happens; the automation handles the initial fix writing.