What if an approved GitHub Issue could become a tested draft pull request while your team focuses elsewhere? We’re exploring a cloud-hosted workflow that keeps engineers in control.
AI coding assistants have already changed what happens inside a developer’s editor. We’re interested in what happens when that assistance moves beyond the editor and becomes part of the wider engineering workflow.
At Fluenty, we’re experimenting with a practical combination of Claude Code, GitHub and AWS: a cloud-hosted development agent that takes an approved issue, works on a separate branch, runs checks and returns a draft pull request for a human to review. This is still an experiment, not a claim that autonomous software delivery is a solved problem.
From GitHub Issue to draft pull request
The starting point is familiar. Developers log bugs and feature requests as GitHub Issues. The difference is what happens after a task has been reviewed and approved for the agent to attempt.
- Log the work. A developer describes the bug or feature in a GitHub Issue, with enough context to understand the expected outcome.
- Approve the issue. Only approved issues are picked up automatically by the cloud-hosted agent. Opening an issue alone is not permission to change the code.
- Implement on a separate branch. Claude Code analyses the codebase, creates a feature or bug-fix branch and attempts the requested changes.
- Run the checks. The agent runs the relevant tests and quality checks to assess the proposed implementation.
- Open a draft pull request. If the checks pass, the agent opens a draft pull request linked to the original issue, making the proposed work available for review.
- Keep the human decision. A developer reviews the changes before anything is merged. The agent proposes an implementation; it does not make the final decision to ship it.
That last step is central to the idea. A passing test suite is useful evidence, but it is not the same as knowing that a change is correct, secure and appropriate for the product.
Why run the agent in the cloud?
The interesting part is that the work can run independently of a developer’s laptop and IDE. The agent can attempt a bounded task in the background while the team focuses on architecture, investigation, client requirements or another piece of engineering work.
In this exploration, GitHub holds the issues, branches and review process. Claude Code provides the coding-agent capability. AWS is the cloud environment we’re exploring for running the work. The exact hosting and orchestration choices are still part of the experiment; there is no single architecture we’re presenting as the finished answer.
Cloud-hosted does not mean unattended forever. It shifts where the implementation attempt runs, not who is accountable for its outcome.
Clear issues matter more than clever prompts
An agent cannot reliably implement a requirement that the team has not clarified. A vague issue such as ‘fix the login page’ leaves too much room for assumptions. A useful issue explains the observed behaviour, the expected behaviour and how the result should be checked.
For example, a tightly scoped bug report might identify the failing input, provide reproduction steps, state the expected validation behaviour and ask for a regression test. That is a much more reviewable task than asking an agent to improve authentication generally.
- Describe the problem and the expected outcome.
- Include reproduction steps or acceptance criteria.
- Identify relevant constraints and anything that must not change.
- Keep the task small enough for a reviewer to understand the complete diff.
Human review is the boundary, not an optional extra
An AI-generated implementation can look convincing and still misunderstand a requirement, weaken a security control or solve the wrong problem. Tests also have blind spots. A change may pass existing checks simply because those checks do not cover the behaviour that matters.
The review therefore needs to cover more than whether the checks are green. Does the code actually address the issue? Is the approach consistent with the existing system? Are there changes to permissions, dependencies or data handling? Can another engineer maintain it?
The agent can propose the change. Engineers still own the decision to merge it.
The guardrails worth designing before scaling
Beyond issue approval and human review, there are safeguards we would want to validate before expanding this workflow. These are design priorities, not a claim that every control below is already implemented in the experiment.
- Least-privilege access: give the agent only the repository and cloud permissions needed for the task, not broad administrative or production access.
- Isolated execution: keep development attempts separate from production systems and avoid exposing production data or long-lived secrets.
- Protected merge rules: enforce review and required checks independently of the agent’s own instructions. Draft status alone is not a security boundary.
- Treat external content as untrusted: issue text, repository content and tool output can contain misleading instructions and should not be allowed to expand the agent’s authority.
- Bounded runs: set time, retry and spending limits so a failed attempt cannot loop indefinitely or create an unexpected bill.
- Traceability: retain the issue link, change summary and check results so reviewers can understand what happened and why.
If checks fail or the task is ambiguous, the safe outcome is to stop and return the problem to a developer, not to bypass checks or keep widening the scope until something appears to work.
What would make this useful in practice?
The goal is not to maximise the amount of code an agent writes. It is to reduce repetitive implementation work and shorten the time between a well-defined task and a useful review.
Small bug fixes, bounded feature changes and straightforward maintenance tasks are sensible candidates to explore first. Ambiguous requirements, security-sensitive changes and major architectural decisions need much closer human involvement.
We would judge the experiment by the quality of its output: how often a proposed change genuinely solves the issue, how much rework reviewers need to do, whether regressions are caught and what each accepted change costs. Faster implementation is not a win if it simply moves more work into review.
More time for engineering, not fewer engineers
This is not about replacing developers. It is about giving engineers more time for the work that needs their judgement: architecture, problem-solving, code quality and understanding what a business actually needs.
Claude Code, GitHub and AWS provide an interesting foundation for that exploration. The exciting direction is not an agent that ships whatever it wants. It is a controlled workflow that turns approved work into reviewable proposals, while keeping responsibility firmly with the engineering team.
Still an experiment. But a practical direction for AI-assisted software engineering—and one we’re keen to keep exploring at Fluenty.