Would You Build a Development Workflow That Depends Less on You?

There is an uncomfortable question behind a lot of the excitement around AI in software development.

If you could build a workflow that lets your client report a bug, have an agent investigate it, prepare a fix, and provide a working preview, would you build it?

Even if it meant the business needed less of your time?

Using AI to finish a ticket faster still leaves most of the process depending on you. You understand the request, prepare the environment, explain the codebase, run the tests, arrange the review, and deploy the change. The coding gets faster, but the workflow stays largely the same.

Changing that workflow raises a harder question about our role and our job security.

A client is not paying me to preserve a process that needs me at every step. They are paying me to help the business improve and compete. If I can remove a bottleneck, reduce risk, and shorten the path to a reviewed release, keeping the old workflow just to remain necessary would be the wrong trade.

That does not make concerns about layoffs unreasonable. Automation can change how much work a company needs, and nobody can promise otherwise.

The goal is not to remove humans from responsibility. It is to remove humans from repeatable coordination work. People should still decide what matters, resolve ambiguity, review risk, and approve releases.

I still want to put my effort into building better systems. The useful technical question is how to reduce manual work while keeping changes understandable, testable, and accountable.

Here is the kind of workflow I would explore, and the tools I would consider. This is a proposed architecture, rather than a claim that I have already deployed every part of it.

Start with a reviewable outcome

Imagine a client reports this issue:

On mobile, selecting a country clears the state field, but the form still submits the old state value.

The workflow I want would gather the missing details, reproduce the problem in an isolated environment, prepare a focused fix, and provide a pull request with test evidence and a preview URL.

The client could check the behaviour. The developer could review the implementation and its implications. The release pipeline would deploy the approved change.

If the problem cannot be reproduced, the workflow should return the investigation and ask a useful question. An honest blocked result is more valuable than an unrelated change delivered confidently.

Move the development environment into something reproducible

An agent needs more than access to a repository. It needs the correct runtime, dependencies, services, test data, and instructions for starting the application.

This is where I would consider Coder. Coder provides customizable remote workspaces and integrations with editors including VS Code, Cursor, and JetBrains. A developer can keep using a familiar editor while the project runs on managed infrastructure.

I would define a workspace template for each project, including its runtime versions, startup commands, test commands, and approved service access. Both developers and agents should be able to use the same reproducible setup.

Screenshot source: Coder documentation.

Remote development gives us a place to enforce controls, but moving code off a laptop does not automatically make it secure. Workspace isolation, credentials, network access, and the infrastructure underneath still need deliberate configuration. Self-hosting the workspace also does not imply that code stays within the organization if an external model provider processes its contents.

For separate clients, I would use separate credentials and resources. A branch or Git worktree separates file changes. It is not a security boundary. An ordinary container also shares its host kernel. Where stronger isolation is needed, I would evaluate dedicated VMs or a suitably hardened sandbox runtime.

Connect tickets to a workflow controller

Jira webhooks can notify an integration about issue events. I would use those events to feed a small controller that decides whether a ticket is eligible for an agent run.

A new client report might trigger triage immediately. Implementation could begin once the ticket has enough detail and enters an agreed status such as Ready for agent.

The controller would build a task brief containing the problem, expected behaviour, reproduction steps, repository, base branch, acceptance criteria, and relevant constraints. It should ask for missing business decisions instead of inventing them.

Webhooks and APIs are enough for an initial integration. MCP can be useful when an agent needs a consistent interface to approved tools, but it does not replace scheduling, workflow state, or authorization.

The controller also needs some ordinary engineering:

• Authenticate incoming events using the integration's supported mechanism.
• Deduplicate deliveries so a repeated event does not start duplicate work.
• Store the ticket, run, branch, pull request, preview, and reviewed commit together.
• Limit run time, retries, spending, and concurrent jobs.
• Recover from failures and clean up abandoned resources.

Ticket text, attachments, and repository content should be treated as input to investigate. They must not be able to grant the agent new permissions or override release rules.

Give each task its own workspace

For an eligible ticket, the controller would provision a workspace, check out the approved base revision, create a branch, and start the coding agent with the task brief.

There are several ways to provide the coding capability:

• GitHub Copilot cloud agent is a hosted route for GitHub repositories. Its documented workflow includes background changes, tests, branches, and pull requests in an ephemeral development environment. It has repository and session limits, so task size matters. See GitHub's documentation.
• Coder Agents provides a self-hosted agent interface and API with workspace provisioning. It is Coder's own agent, rather than a wrapper around another coding CLI. See Coder Agents documentation.
• OpenHands Software Agent SDK provides Python and REST APIs for building coding agents, including remote execution with Docker sandboxing. I would consider it when I need custom behaviour and integrations. See OpenHands SDK documentation.

These are alternatives to evaluate. I would start with one coding agent and a clear handoff protocol. Adding more agents before understanding the failure cases makes the workflow harder to debug.

The initial task should be to reproduce the issue and establish the baseline. Otherwise, an agent can spend its budget fixing existing failures that have nothing to do with the ticket.

Screenshot source: OpenHands project.

Separate the workspace from the client preview

The agent's workspace is where commands run and files change. The preview is where someone evaluates the resulting application. Production is a third environment with separate permissions.

For frontend changes, a pull request preview may be enough. Netlify Deploy Previews can automatically build previews for pull requests in connected repositories.

For an application with separate frontend and backend services, that frontend URL only covers part of the system. The preview may also need a matching backend revision, database, media fixtures, and environment configuration.

My proposed preview setup would give each relevant change its own frontend build and backend instance, using synthetic or sanitized data. The frontend would point explicitly to that backend. Email, payments, analytics, and external integrations would use safe test configurations.

Some tasks only need frontend isolation. Others change Drupal configuration, database structure, or API behaviour and need a fuller environment. The controller should select the appropriate template instead of provisioning the most expensive setup every time.

Previews should have appropriate access control and an expiry policy. Completed or abandoned workspaces and previews need automatic cleanup.

Produce evidence that makes review easier

A useful pull request should explain the original problem, the change, the checks performed, and any remaining uncertainty.

For the form example, I would want evidence that changing the country clears the submitted state value, validation still works, and the affected mobile interaction behaves correctly.

Playwright Trace Viewer helps inspect recorded browser tests, including the actions and application state around a failure. I would attach relevant traces or screenshots to the review alongside unit, integration, and static-analysis results appropriate to the change.

Screenshot source: Playwright documentation.

A passing test suite is evidence within its coverage. It does not establish that every business requirement is correct. Tests created by the same agent can share its misunderstanding, so acceptance criteria and human review still matter.

Client feedback would return to the same ticket and pull request. Any resulting revision would receive fresh checks and an updated preview.

Keep the release boundary explicit

For an initial implementation, I would let agents prepare changes and previews while developers retain merge and release approval.

Approval needs to refer to the exact revision reviewed. If the agent pushes another commit, earlier checks and approval may no longer apply. Where possible, the pipeline should promote the tested artifact. Otherwise, it needs a reproducible build and checks against the approved revision.

Database changes need their own recovery plan. Rolling back application code does not necessarily reverse a database migration safely.

The release pipeline should also verify the deployed behaviour and record the outcome back on the ticket. That closes the loop between a client request and an observable result.

Three stack options I would consider

These are proposed combinations. Connecting them requires integration work, and product availability depends on the relevant plans and deployment configuration.

Hosted pilot

GitHub Issues, Copilot cloud agent, GitHub Actions, Netlify previews, and Playwright. I would choose this for one GitHub project where I want to test the process with little infrastructure work.

Controlled remote workflow

Jira webhooks, a small TypeScript or Python controller, PostgreSQL, Coder workspaces, Coder Agents, existing CI, and per-ticket previews. I would choose this for client projects that need reproducible environments and more control over access and integrations.

Custom workflow platform

Jira integration, Temporal, PostgreSQL for application metadata, OpenHands SDK workers, isolated compute, preview provisioning, and CI. I would choose this for multiple projects with long waits, recovery requirements, and enough usage to justify operating a platform.

For the third option, Temporal provides durable workflow execution and recovery using event history. I would use it to coordinate stages such as provisioning, implementation, checks, and review. External operations, including model calls and infrastructure APIs, belong in Activities rather than deterministic Workflow code.

Durability does not remove the need for idempotent side effects. A retried provisioning or pull-request operation must recognize resources already created.

For a first experiment, I would choose the hosted pilot or the controlled Coder setup. Temporal becomes worth evaluating when recovery and coordination are real problems.

Smaller projects worth building first

1. Ticket readiness assistant. Identify missing reproduction steps and draft acceptance criteria. Measure whether developers spend less time clarifying requests.
2. Bug reproduction assistant. Investigate a ticket and return a reproducible test or a precise blocker before changing code.
3. Preview environment service. Create a consistent review environment for a pull request, including test data and expiry. This helps human developers too.
4. Regression test assistant. Propose a focused test after a bug fix, with evidence that it fails before the fix and passes afterward.
5. Dependency maintenance assistant. Prepare small updates, run compatibility checks, and open reviewable pull requests.
6. Release verification assistant. Check agreed user journeys after deployment and attach results to the release record.

I would begin with one repository and one narrow class of bug. The first milestone would be simple: an approved ticket produces a focused pull request, meaningful checks, and a working preview without manual environment setup.

I would measure total time to an accepted change, reviewer effort, rework, escaped defects, and cost. Generating more pull requests is only useful if reviewing and maintaining them remains manageable.

What I want to contribute

I cannot predict how every company will respond as these workflows improve. Some will invest the saved time in more work. Others may reduce staffing.

Becoming less necessary to each individual ticket is not the same as becoming less valuable. The work moves toward designing the system, understanding the business, handling exceptions, and improving the safeguards around delivery.

What I can decide is the kind of engineering I want to do. I want to understand the business, make delivery more reliable, and build systems that other people can operate and improve.

That means documenting decisions, making environments reproducible, defining useful tests, and removing unnecessary dependence on one person's availability.

If I can help a team move from a reported problem to a reviewed solution with less friction, I think that is valuable work.