Zesty turned a mature AI toolchain into a software factory

Zesty builds a platform that automatically optimizes compute, storage and Kubernetes resources based on real-time demand. Its engineering organization was an early AI adopter: developers had capable AI tools for writing code, reviewing it and understanding it.

But every tool worked one step at a time, one developer at a time. A single unit of work still crossed Jira, GitLab, LaunchDarkly and Slack by hand. Someone had to notice a flag was ready to retire, open the ticket, write the MR description, chase the review, tell support what shipped and cut the release.

The AI was there. The factory infrastructure was not.

With Overcut, Zesty connected those capabilities into workflows that hand work to each other. Each station starts on a real event, a schedule, a ticket, a merge request or a merge, and passes its output to the next.

Discover: the factory finds its own work

Every week, a scheduled workflow reads the feature flags declared in Zesty's frontend repositories and checks each one in LaunchDarkly. Flags that are fully rolled out and stable for two weeks, or archived, are marked ready to retire.

Plan: a ticket for every unit of work

For each ready flag, the workflow opens a Jira ticket, after checking existing tickets and open merge requests so the same work is never created twice. Each morning the release workflow does the same: if dev is ahead of master, a release ticket is opened.

Build: from ticket to merge request

A new ticket starts the build workflow. It reads the ticket, finds the right repository, removes the retired code path and opens a merge request, then updates Jira and posts to the team's Slack channel.

Describe and review: every MR, every repository

Every merge request, written by a developer or by the factory, is picked up the moment it opens. Overcut writes the description from the diff in Zesty's template, linked to its Jira ticket. A review workflow plans the review by intent, consolidates overlapping findings and posts inline comments. Developers reply in the thread, and the reviewer answers.

Merge: a developer decides

Nothing merges on its own. A developer reviews and approves every merge request, including the ones the factory wrote.

Ship and notify

On every merge, a workflow summarizes what changed, who changed it and what to watch for, and sends it to Slack for the support team. The daily release MR carries the day's changes to master.

A factory that writes and ships code needs clear rules. Zesty's were built in from day one.

• A human on every merge. Workflows open merge requests. Developers merge them.
• Explicit permissions. Each workflow reaches only the systems and repositories it is granted.
• A full audit trail. Every run, step, tool call and decision is recorded and reviewable.
• Zesty's standards. Review rules, MR templates, ticket formats and Slack destinations follow how Zesty works, and are tuned against Zesty's own merge requests.

Zesty started with a single station and added the next once the last one had earned trust.

1. Code review on GitLab merge requests reached production two weeks after setup.
2. MR descriptions and merge notifications followed, across Zesty's repositories.
3. Feature-flag retirement connected LaunchDarkly, Jira and GitLab into a loop that finds, plans and builds its own work.
4. Daily release MRs automated the dev to master release.

Today developers ask for their repositories to be connected. That is the clearest sign the factory is delivering.

The governance model Zesty proved in engineering is becoming the model for the rest of the company. Other teams are adopting AI in their own areas, and running those workflows on Overcut gives them the same permissions, audit trail and human approval that engineering already relies on.