kelos-dev / kelos-dev/kelos

New use case: AI-powered dependency maintenance with breaking change resolution

Open
#384 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

actor/kelos generated-by-kelos kelos/needs-input kind/docs priority/backlog triage-accepted
Dominant language
Go
Stars
331
Forks
40
Avg merge
1d 21h
Merged PRs (30d)
70

Description

🤖 Axon Agent @gjkim42

Summary

Dependency management is one of the most time-consuming maintenance tasks in software engineering. Tools like Dependabot and Renovate automate version bumps, but they stop at opening a PR — when a dependency update introduces breaking changes, the PR sits unmerged until a human fixes the build. Axon can go further: an AI agent that not only bumps dependencies but also resolves breaking changes, updates call sites, and fixes failing tests.

This proposal outlines concrete TaskSpawner configurations for dependency maintenance workflows that leverage Axon's unique strengths over traditional bump-and-PR tools.

Why this is different from Dependabot/Renovate

Capability Dependabot/Renovate Axon Agent
Detect outdated dependencies Yes Yes
Open a version-bump PR Yes Yes
Fix breaking API changes No — PR sits with failing CI Yes — agent reads changelog, updates call sites
Migrate deprecated APIs No Yes — agent follows migration guides
Fix failing tests No Yes — agent investigates test failures and patches them
Handle multi-package updates Limited (groups) Yes — agent understands cross-cutting changes
Fan out across repos Separate config per repo Yes — single TaskSpawner with dependsOn pipeline

The key insight is that dependency updates are not just "change a version number" — they often require code changes. This is exactly the kind of task where an AI coding agent adds value over a simple automation.

Proposed configurations

Use case 1: Weekly dependency audit + fix (single repo)

A cron-triggered agent that checks for outdated dependencies, updates them, and fixes any resulting build/test failures:

apiVersion: axon.io/v1alpha1
kind: TaskSpawner
metadata:
  name: dependency-updater
spec:
  when:
    cron:
      schedule: "0 6 * * 1"  # Every Monday at 6am
  maxConcurrency: 1
  taskTemplate:
    type: claude-code
    model: sonnet
    credentials:
      type: oauth
      secretRef:
        name: claude-credentials
    workspaceRef:
      name: my-app
    branch: "deps/weekly-update-{{.ID}}"
    ttlSecondsAfterFinished: 86400
    agentConfigRef:
      name: dependency-agent
    promptTemplate: |
      You are a dependency maintenance agent. Your goal is to update
      outdated dependencies and ensure the project still builds and
      passes tests after the update.

      Steps:
      1. Check for outdated dependencies using the project's package
         manager (go list -m -u all, npm outdated, pip list --outdated,
         cargo outdated, etc.)
      2. For each outdated dependency:
         a. Read the changelog or release notes for breaking changes
         b. Update the dependency version
         c. If the update causes build failures, fix the affected code
         d. If the update causes test failures, fix the tests
      3. Run the full test suite to verify everything passes
      4. If there are no outdated dependencies, exit without changes
      5. Create a PR with a summary of what was updated and any code
         changes required

      Guidelines:
      - Only update to stable releases (no pre-release versions)
      - Update one major version at a time for breaking changes
      - Group minor/patch updates into a single commit
      - Skip updates that require architectural changes — create an
        issue instead
      - Include the changelog link for each updated dependency in the
        PR description
  pollInterval: 5m
Use case 2: React to Dependabot/Renovate PRs and fix failures

For teams already using Dependabot or Renovate, Axon can be the "fixer" that unblocks their PRs:

apiVersion: axon.io/v1alpha1
kind: TaskSpawner
metadata:
  name: dependabot-fixer
spec:
  when:
    githubIssues:
      types: [pulls]
      labels: [dependencies]  # Dependabot labels its PRs
      excludeLabels: [axon/fixed]
  maxConcurrency: 2
  taskTemplate:
    type: claude-code
    credentials:
      type: oauth
      secretRef:
        name: claude-credentials
    workspaceRef:
      name: my-app
    branch: "axon-fix-deps-{{.Number}}"
    ttlSecondsAfterFinished: 3600
    promptTemplate: |
      A dependency update PR was created by Dependabot:
      PR #{{.Number}}: {{.Title}}
      {{.Body}}

      Task:
      1. Check out the Dependabot branch and check if CI is passing
      2. If CI passes, add the label "axon/fixed" and exit
      3. If CI fails:
         a. Read the build/test errors
         b. Read the dependency's changelog for breaking changes
         c. Fix the code to work with the new dependency version
         d. Push your fixes to a new branch and open a PR that
            targets the Dependabot branch
         e. Add the label "axon/fixed" to the original Dependabot PR
      4. If the fix requires architectural changes beyond your scope,
         comment on the Dependabot PR explaining what needs manual
         attention
  pollInterval: 5m
Use case 3: Fleet-wide dependency update (multi-repo)

For platform teams managing multiple services, update a shared dependency across all repos:

# Shared agent instructions for dependency migration
apiVersion: axon.io/v1alpha1
kind: AgentConfig
metadata:
  name: grpc-migration-agent
spec:
  agentsMD: |
    # gRPC Migration Agent

    You are migrating services from grpc-go v1.x to v2.0.

    Key changes in v2.0:
    - Package import path changed from google.golang.org/grpc to google.golang.org/grpc/v2
    - NewServer() now requires options; bare NewServer() is removed
    - Interceptor API changed to use new middleware pattern
    - Dial() renamed to NewClient()

    Follow the migration guide at https://grpc.io/docs/languages/go/migration/
---
# Step 1: Update each service (fan-out)
apiVersion: axon.io/v1alpha1
kind: Task
metadata:
  name: migrate-user-service
spec:
  type: claude-code
  credentials:
    type: oauth
    secretRef:
      name: claude-credentials
  workspaceRef:
    name: user-service
  agentConfigRef:
    name: grpc-migration-agent
  branch: deps/grpc-v2-migration
  prompt: |
    Migrate this service from grpc-go v1 to v2 following the
    migration guide in your instructions. Run tests to verify.
    Create a PR with the changes.
---
apiVersion: axon.io/v1alpha1
kind: Task
metadata:
  name: migrate-order-service
spec:
  type: claude-code
  credentials:
    type: oauth
    secretRef:
      name: claude-credentials
  workspaceRef:
    name: order-service
  agentConfigRef:
    name: grpc-migration-agent
  branch: deps/grpc-v2-migration
  prompt: |
    Migrate this service from grpc-go v1 to v2 following the
    migration guide in your instructions. Run tests to verify.
    Create a PR with the changes.
---
# Step 2: Verify cross-service compatibility (fan-in)
apiVersion: axon.io/v1alpha1
kind: Task
metadata:
  name: verify-grpc-migration
spec:
  type: claude-code
  credentials:
    type: oauth
    secretRef:
      name: claude-credentials
  workspaceRef:
    name: integration-tests
  agentConfigRef:
    name: grpc-migration-agent
  dependsOn:
    - migrate-user-service
    - migrate-order-service
  prompt: |
    The gRPC v2 migration PRs have been created:
    - user-service: {{index .Deps.migrate-user-service.Results "pr_url"}}
    - order-service: {{index .Deps.migrate-order-service.Results "pr_url"}}

    Run the integration test suite against these branches to verify
    cross-service compatibility. If tests fail, create issues on the
    affected repos with details about what needs to be fixed.

Why Axon is uniquely positioned for this

  1. Agent intelligence handles breaking changes. Dependabot can bump v1.2.3 to v2.0.0, but it cannot read a migration guide and update call sites. An AI agent can.

  2. dependsOn enables migration pipelines. Update a shared library across multiple services, then run integration tests to verify compatibility — all coordinated via task dependencies.

  3. AgentConfig centralizes migration knowledge. A migration guide written once in AgentConfig is shared across all tasks, ensuring consistency.

  4. Kubernetes-native scheduling. Long-running dependency updates run in isolated pods without tying up CI runners. Resource limits prevent runaway costs.

  5. Fan-out across repos. A single set of manifests can update a dependency across dozens of services simultaneously — something Dependabot requires per-repo configuration for.

Target audience

  • Platform engineering teams managing shared libraries across microservices
  • Teams with Dependabot/Renovate who have a backlog of unmerged dependency PRs due to breaking changes
  • Security teams who need to patch CVEs across a fleet of services quickly
  • Any project with outdated dependencies that have been deferred due to migration effort

Relation to existing issues

  • #291 (New use cases) — That issue covers PR review, fleet migration, and security audit. This proposal is complementary, covering a different high-value use case (dependency management) with the same fan-out patterns.
  • #314 (TaskSet CRD) — If implemented, TaskSet would make the fleet-wide migration pattern (use case 3) even more ergonomic.
  • #283 (Task completion triggers) — Would enable the "Dependabot fixer" pattern to trigger automatically when a Dependabot PR fails CI.

Next steps

If this use case resonates, I can create a concrete example in examples/ demonstrating the single-repo weekly update pattern (use case 1), which requires no new API features and works with Axon today.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the proposed TaskSpawner, Task, and AgentConfig examples and the related issues #291, #314, and #283. The issue does not identify a concrete file or settled implementation; done would need to be clarified, such as adding a worked example under examples/ or defining the API changes required for dependency-maintenance workflows.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
ai-infra-agents, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.