Tag Archives: claude code

Agentic Coding with Claude: The Bad Parts, Part 1 – Lack of Team Buy-In

Hi, I’m Brian. You may remember me from such posts as Using Claude Code to Automatically Fix Security Issues Discovered by Snyk, and Teaching Claude Code About Test Coverage. I probably sound pretty bullish about the future of AI augmented coding.

And boy howdy, am I ever. My team maintains a legacy product, which means often our daily tasks are not fun, or creative. AI tools are helping me automate away the drudgery so we can focus on the interesting, creative stuff again.

But this post isn’t about that. It’s the start of a discussion about the parts of using AI for software development that influencers seem not to want to talk about.

This is the first in a series of posts about problems I’ve encountered while using AI tools for software development, and strategies we’ve used to mitigate the issues.

The Problem: Lack of Team Buy-In

If you’re team has a profound disagreement about if/how to use AI, things could get messy.

And if you put 2 or more developers in a room, there’s a good chance they don’t agree on this topic. Not all developers feel the same way about using AI in software development. You’ve got a spectrum of opinions, some of which I’m about to poke fun at a bit.

  • The “If AI Were Jonestown, I’d Be Dead and Diabetic” Types. These folks drank the Kool-Aid and asked for seconds. Bro, AI is changing everything bro. Bro in 6 months software developers won’t have jobs, bro. Bro the CEO just has to describe what he wants to Replit and hope it doesn’t delete the prod database, bro. Also why didn’t you buy my NFT’s two years ago, bro? BRO???!
  • The Pragmatists. We love software development. We like having jobs in software development. We like tools that make our jobs and our work better. Maybe we should learn to use this thing but figure out when it is, and isn’t, the right tool for the job.
  • The AI Amish. AI is the devil! AI will destroy the environment, tank the economy for all but the 1% of the 1%, atrophy the skills of human developers, erode privacy, and bring shame on you, your family, and your cow! But also it’s completely useless and produces awful slop.

Let’s face it. When you start using AI tools, the code you submit has a scent of AI on it. That doesn’t mean it’s bad code. It means that folks familiar with your codebase sense something slightly off about it. They know it’s isn’t the artisanal, hand-crafted slop you usually submit to PR. It’s AI slop!

If someone isn’t aligned on if, when, or how to use these tools, they may look for every reason to criticize and block your code.

Possible Solutions

I live professionally in the quality consulting space and they often say “there are no people problems, only process problems.”

<rant> (But that’s definitely a little bullshit, isn’t it? There are totally people problems. I mean every company has a department specifically for people problems, at least for now. So don’t tell me there’s no such thing as people problems when it’s clearly a marketable skill to be able to ruin someone professionally without shifting your facial expression.) </rant>

Sometimes we can solve the alignment problem by building consensus and turning skeptics into cheerleaders by showing the way, and through crucial conversations. Sometimes we need to use the power of policy to draw some boundaries around what proper use of the tool is, and what level of disagreement will, or won’t, be tolerated. Sometimes we solve people problems by choosing to work with different people.

I can’t say I’ve solved this completely, but here are some strategies I’ve found somewhat effective.

Demonstrate Value

Obviously we’re going to start with Step 1 in the D.E.N.N.I.S System. Use generative AI to go faster while being better. After all: if you can’t do this, then what’s the point? Most of all don’t submit slop for review just to demonstrate velocity. You’ve just fueling their narrative.

(And yes, I’m guilty as charged on not taking my own advice a few times.)

Be Clear About PR Feedback Expectations, Be Brutal in Enforcement

If your team does peer review (PR), have a PR Policy that defines what appropriate and inappropriate feedback and change requests look like. When folks abuse the policy to block AI generated code they don’t personally like, fix the policy. When they block AI code they don’t personally like in defiance of the policy, rub it in their face.

And be honest when AI code passes your policy and is still slop. Improve your prompts to improve your code. And improve the policy where it falls flat.

Build the Team You Want

If AI is that important to adopt, then build the team you need to make adoption successful. Don’t suffer folks that will throw sand in the gears of the effort. Brutal, but honest.

Using Claude Code to Automatically Fix Security Issues Discovered by Snyk

My team has been working on a security remediation project for the last 8 months. At the beginning of the project we asked ourselves the question: could generative AI help solve this problem faster? And six months ago, the answer was probably not. Out experimentation with AI at that point suggested that none of the tools at the time could do a great job at working on the languages we use, in the shape much of our legacy code is in.

Today, that’s changed completely. In particular, I find Claude Code incredibly adept at working with legacy, especially when I don’t ask to much of it at one time.

I’ve been using it successfully to point it at a file, and ask it to remediate security issues such as SQL injections and Command injections. I’ve written custom slash commands to make it consistent and repeatable. But it’s still a manual process.

Today’s challenge: scale it up by letting Claude Code talk to Snyk, our secure code auditing tool, and let it spin up asynchronous subtasks which fix specific issues, and submit pull requests.

Talking to Snyk

I am having a heck of a time getting Claude Code to talk to Snyk in spite of the fact that:

  • Snyk has a good CLI
  • Snyk has preview MCP support

My issues seem to stem from the fact that we have an organizational account, not an enterprise account, and API (and therefore, MCP) access is limited unless we want our bill to explode. After working with Snyk the 8 months, this is my biggest gripe about it: their pricing structure and feature set for small teams… kinda sucks.

The Workaround: Generate Results Offline

Fortunately our account type and bank account balance don’t need to be a roadblock. I worked around the limitation by generating the results offline rather than having Claude get them via API in real-time. (This also happens to speed up future steps and reduce the number of prompts we need to get data iteratively in future steps.)

snyk code test --json-file-output=snyk-output.json

Now we have a JSON file that lists all the issues detected by Snyk.

Getting Claude Code to Read the File and Remediate Issues

What I want Claude Code to do is, well… exactly what I’d do were I to do the work myself. Most of our security remediation work is done with a scalpel, not a chainsaw. We fix the specific lines of code that have specific issues, and don’t make big changes unless they’re required. The process looks like this:

  • Pick the next vulnerability from the file.
  • Create a branch.
  • Fix the vulnerability.
  • Run all quality checks against the change (linters, tests).
  • Fix any quality check issues.
  • Stage, commit, push.
  • Submit PR

My prompt pretty much says that:

The file snyk_output.json is the JSON output of running "snyk code test," so it describes security issues Snyk found in out codebase. Go learn about this file format so you understand what the issues are. Then, for each issue start a sub task which creates a new branch, fixes the issue, runs all quality and testing commands available and, once they all pass, stages, commits, pushes the work, and then opens a PR which explains what was fixed and how to test. Stop at ten remediated vulnerabilities.

In other words: do what I would do, and stop at ten iterations. I build the limit into the prompt so if something goes wrong, or the automation can be improved, I want time to iterate before we go nuts with it.

The Results

Claude did a great job. I had to approve changes frequently, but I got the PR’s I expected, in more or less the shape that I want. My next steps will be:

  • Refine the prompt to make Claude include the Snyk issue link in the PR.
  • Refine the prompt to use Jira’s CLI or MCP to create a matching issue.
  • Refine the prompt to make Claude include the Jira issue ID in the PR.
  • Refine the prompt to include a test plan in the PR description and Jira issue.

Once things things are complete, and I test a few more PR’s, I’ll run with --dangerously-skip-permissions and go full auto mode.