A security reviewer finds a critical issue a day or two before the release of an application. While it's an important issue, it sets the team back weeks, frustrating their product management partners and customers. The review came at the most expensive time in the process.
There are many examples of how work items move through different processes to deliver software in large companies. While GenAI has allowed us to rapidly create code, it also moved and exposed the bottlenecks in our processes. It has also caused us to re-examine where it is most effective to make certain decisions. This is the challenge, and a deliberate blend of automated, programmatic, and human judgment is well suited to help you solve it.
We can borrow from the well-trodden path of value stream mapping here. It is useful for spotting bottlenecks and waste in a given process, but it's also valuable to ask the deeper question of who or what should own each step. Each option earns its place differently. Is there an earlier step that may reduce costs with an agent where it was previously limited by human availability? Or is the stronger determinism of a programmatic step more important for a critical piece of the flow? Some decisions should stay with human judgment, where confidence without context is a liability. The opportunity for security teams and other stakeholders is to scale their impact across these options rather than scaling headcount.
Workflow-as-code is not a new idea. There are a number of existing engines where the workflow definition is its own entity, separate from the work itself. GitHub Actions defines pipelines in version-controlled files, while the execution happens on separate runners. Airflow and Temporal follow a similar pattern for data and application workflows. Because the definition lives on its own, a team can change how a given step runs without rebuilding the whole flow. That separation is what makes it practical to adjust who or what owns each step over time.
Rather than a last-minute security review, an agent could flag categories of change as work is refined, well before anything is delivered. In this case the agent itself isn't doing the review but flagging the work that needs attention among all the rest. While some changes warrant a consultation with a human reviewer, others can trigger an automated check. A human review is still worth keeping for something like a sign-in flow. I outlined an agentic example around dependency management in one of my previous posts. None of this requires reworking the whole process at once. By modeling ideation and story definition as a workflow, a team can introduce one of these changes, see whether it catches what the late review used to, and adjust from there.
In his essay on automation, Dan Shipper draws a distinction between the frame and the framer. While agents are great at accomplishing tasks, we still need humans to decide what the goal is and what good looks like. Engineers who can think and navigate at the workflow level will keep providing value while execution of steps becomes more commoditized.
The tools are here. What step would you change first?
Top comments (0)