Felipe Cruz

AI Delivery Workspace

Simple front-end tasks took up to five days to be done, sometimes with two or three developers. I built a command flow so a business analyst can ship them with an AI agent, on components that already exist. A developer reviews the merge request. The time fell to up to two days.

Outcome
60% reduction in delivery time
Role
Lead UI Designer
Area
Delivery · Front-end · Business Analysis

From ticket to merge request

Select a step

AI acts BA validates AI continues

Ticket update, optional

Documentation, optional

Clone the repositories and the branch, then start the local environment. Once, unless the branch changes.

AI Setup BA Ticket AI Understand BA Validate AI Implement AI Verify Git MR

Ticket update · Documentation, optional

Visual artifacts and client details omitted per NDA.

The situation

I started this as an internal proof of concept. The client did not ask for it. The first use is an OSS product for a North American telecom, and that project is where the team is validating it. The aim is to take it to other teams and other projects. The command package is flexible. Nothing in the install is tied to this project’s repositories.

A business analyst could already define a simple front-end change. Shipping it still sat with development. Up to five days to be done, and sometimes two or three developers, depending on complexity. The tasks were routine. They used components that already existed in the design system.

The product is a shared base, supplied to each client project. The project keeps its own overlay: what gets built on top of that base. Some of the overlay is later standardized into the product. Some of it stays specific to the project. This flow is for the project overlay.

The decision

I built a package of commands so the analyst could do that work with an AI agent.

First time, through to a shipped change

  1. 1 · Clone/git-pullfrom the pack
  2. 2 · Setup/setup-new-envreopen the UI
  3. 3 · Ticket/work-taskconfig or package
  4. 4 · Check/validate-taskreturns READY
  5. 5 · Shipcommit + MR+ activate

Done when check returns READY. Development only for a true code gap.

Typical day, once the environment is up

  1. Start day/start-stack
  2. Change/work-task
  3. Validate/validate-task
  4. Shipcommit + MR

Check is mandatory. A commit without /validate-task READY is not done.

The constraint

The limit on product files was set with the development team, so the agent would not break what was already in production. It may only change the project. When a change belongs in the product, it stops and tells the analyst. That path sits outside this flow.

The flow uses components that already exist in the design system, so design stays out of it. If a ticket needs a new component, the agent stops and tells the analyst it is out of scope. Work that reaches further into the system stays with development. This path is for the simple, routine tasks.

On one ticket, the acceptance criteria named fields that lived in the product base, not in the project. The agent stopped. It would not guess the type, because a guess could duplicate a field or produce an invalid model. The analyst could provide the product model, or mark the gap for the team that owns it. Until then, the file stayed as it was.

A ticket

One ticket added a network configuration. The acceptance criteria asked for a new data model, a button to create it, and a form filled from information already in the system. After creation, the details had to be visible, and editable when something needed to change.

The change was interface configuration and the new data model. A business analyst took it from the start of the work to validation with the team in two days.

The role

I built the command package in Cursor. With the development team, I validated the limits of the tool, so what was already in production would hold. With stakeholders, I validated the need: reduce the development cost of simple, routine tasks.

Results

60% reduction in delivery time

Simple tasks went from up to five days to up to two, depending on complexity. The same work had sometimes taken two or three developers. A business analyst now does it, and one developer validates the merge request.