Agentic Workflow for Automating QA Issue Resolution

The biggest factor that slows down software team productivity is not complex bugs.

More often, the real time sink comes from small and repetitive issues.

For example:

A button that does not respond when clicked.

A list that appears empty under certain conditions.

Most of these issues can be resolved with only a few lines of code. However, fixing those few lines still requires engineers to repeat the entire development cycle.

1. Understand the context of the issue
2. Explore the relevant repository
3. Identify the correct location to modify
4. Write the code change
5. Create a pull request
6. Request a review

In many cases, the overhead of this process is larger than the code change itself. As these interruptions accumulate, the overall workflow of the team becomes fragmented.

This raises an important question.

Which parts of an engineering workflow truly require human judgment?

‍

‍

Why Repetitive Execution Still Falls on Engineers

Most development organizations handle QA issues in the following way.

1. The QA team reports a bug in a Slack channel.
2. An engineer reviews the issue and determines the direction for resolving it.
3. The actual code changes are then implemented in GitHub or in a local development environment.

This structure itself is a natural and effective collaboration model.

Slack serves as the most practical communication channel for sharing and discussing issues with team members who may not have access to the development environment. It also helps maintain transparency by keeping the context of the issue and its progress visible to the broader team.

However, in practice, the largest amount of effort in issue resolution is spent on repetitive execution tasks.

Identifying the root cause of a bug and deciding how to fix it are tasks that require human judgment. After that point, the workflow typically moves into a series of repetitive operational steps.

For example:

• exploring the relevant repository
• locating the file that needs modification
• writing the code change
• creating a branch
• opening a pull request
• requesting a review

These steps are repeated in almost the same form for most issues.

In other words, the core problem is not the collaboration structure between Slack and GitHub. The real issue is that the execution steps that follow human judgment still rely entirely on manual work.

This brings us back to the original question.

Within an engineering workflow, how should we distinguish between the tasks that require human judgment and the execution tasks that can be handled by systems?

‍

‍

An Execution Workflow That Starts in Slack

To address this problem, we designed a system called issue-resolver-bot.

This bot uses Slack emoji reactions as a trigger and automatically performs issue analysis, repository exploration, and pull request generation.

The core idea is simple.

Connect discussion and execution within the same environment.

The workflow operates as follows.

1. A QA team member reports a bug in the Slack QA channel. The report may include text, screenshots, or attachments.
2. If an image is attached, the system sends it to Amazon Bedrock so that visual context can be analyzed together with the message.
3. A team member then adds a bug emoji reaction to the message. This reaction acts as the trigger for the automation process.
4. A continuously running Go service called issue-resolver-bot detects the Slack event and initiates the automation pipeline.

‍

‍

AI Processing Based on Issue Complexity

Not all issues require the same level of reasoning.

The system therefore analyzes issue complexity and selects different AI models accordingly.

This structure balances speed, cost, and reasoning capability.

Simple fixes are handled by faster models, while more complex changes use models with stronger reasoning ability.

‍

‍

From Repository Exploration to Pull Request Creation

Once the issue analysis is complete, the system begins exploring the relevant repositories.

If necessary, both frontend and backend repositories are analyzed. The system then performs the following steps automatically.

• Code modification
• Branch creation
• Pull request generation

The pull request author is the bot account.

As a result, the amount of repetitive execution work required from engineers is significantly reduced.

Engineers first review the issue in Slack, clarify the context, and determine the appropriate direction for the fix. Once the approach is agreed upon, they trigger the automation pipeline.

From that point forward, execution tasks such as repository exploration, code modification, branch creation, and pull request generation are handled by the system.

The engineer’s role then shifts to reviewing and approving the generated pull request.

Human judgment defines the direction, while the system carries out the execution.

‍

‍

Issue Resolution That Happens Entirely in Slack

The most important change introduced by this system is not simply automated code modification.

The entire issue resolution process now happens within Slack.

An engineer can propose a potential fix directly in the Slack thread. QA or product managers can add additional context. Once the discussion reaches a clear direction, someone adds the emoji trigger.

At that moment the automation begins.

No new commands or interfaces are required. The workflow starts through an interaction that the team already uses.

In practice, several issues have already been resolved by team members who are not engineers simply by triggering the emoji reaction.

Within less than two weeks of deploying this agentic workflow, more than ten issues were resolved through this system.

‍

‍

The Human Role Is System Design

Most of the code in this project was generated using Claude Code.

The human role was not to manually implement every feature, but to define what should be automated.

The primary tasks included:

• Defining functional requirements
• Designing issue classification criteria
• Reviewing the quality of generated pull requests
• Providing feedback on edge cases
• Designing the overall system architecture

The architecture consists of Slack App integration, GitHub App automation, Amazon Bedrock for multi-modal analysis, and a Go based orchestration service.

Claude Code generates the implementation.

Humans determine the direction.

This structure reflects the philosophy behind the system itself.

‍

‍

Current Limitations

The system still has limitations.

The bot performs best when the issue description includes clear hints about which repository or module should be modified.

Accurately identifying the correct modification point from minimal context remains an area for improvement.

UI related issues are also more difficult to handle.

Layout breaks or styling inconsistencies often require understanding design specifications rather than just reading code.

To address this challenge, we are preparing an integration with Figma MCP. Once the system can reference design tokens and component specifications directly, UI related issues can also be processed within the same automation pipeline.

‍

‍

Delegating Execution to Systems

Liberation from work does not mean automating everything.

It means clearly defining the boundary between human judgment and mechanical execution, and delegating the rest to systems.

issue-resolver-bot is an early step in that direction.

A simple emoji reaction that becomes a pull request may appear small, but it changes how engineering workflows operate.

Repetitive execution is handled by systems.

Humans focus on judgment and direction.

This is how Enhans defines New Digital Labor in real operational workflows.

‍

‍

If your team is exploring agentic workflows or AI driven automation in engineering environments, feel free to reach out to the Enhans team.

Contact

‍