My Agentic Engineering Workflow In Late 2026

As writing code by hand is mostly dead by now (economically speaking of course), the bottlenecks shift greatly towards speccing and verification.

Development quality now depends on how well an engineer can formulate the problem before generation and how strictly they test the output afterward.

I want to note that coding can still be a great hobby to pursue, and I really wonder how this year’s Advent of Code will turn out (check this if you are unfamiliar with it: 2023-12-01 Advent of Code 2023). Maybe for the fun of it I will code those by hand if I find the time.

In this blog post I want to pin down my AI workflow in late 2026. I already did this earlier this year in 2026-03-20 My Agentic Engineering Workflow In Early 2026.

Before walking through the stages, here is my current understanding of Agentic Software Engineering in contrast to Vibe Coding:

The difference comes down to where the engineer spends the majority of their effort.

Vibe Coding means that the developer enters an informal prompt, lets the model produce code, and checks if it seems to run. There is no written specification, no verified shared understanding, no test-driven verification, and no feedback loop process. When the code breaks or drifts, the user feeds error messages back into the prompt until it appears to work again. This works for quick experiments but fails as complexity grows.

Agentic Software Engineering means that the agent executes within explicit constraints, using specialized skills for each stage of development. This means building a shared understanding between agent and human, persisting this in a spec and ADRs if necessary. Implementing is then a precise operation for the agent, followed by specified test-driven verification, an (Agentic + Human) code review, and finally a feedback loop to make the workflow more robust.

The five stages of the agentic lifecycle

My current workflow is heavily influenced by Matt Pocock’s skills model. Each stage has clear inputs, human responsibilities, and agent roles.

1. Ideation

This is the part where we either start a /Wayfinder session or use /grill-with-docs. As I do not want to go into Wayfinder here, let us continue with the scenario that you know what you want to do and even think you know the solution.

You could just write down the goal and the acceptance requirements into a spec and be done. Why do we not just think about the spec and write it down directly for the agent?

This is where the /grill-with-docs skill comes in. It does not replace the human speccer. Instead, it acts as a tool that challenges your goal and your proposed path to get there. It reads the local documentation and codebase, asking targeted questions to lift assumptions the agent would otherwise guess during implementation.

2. Specification

Once the ideation interview settles the assumptions, you decide how to formalize the plan. There are two paths here depending on the feature scope:

Small: For small tasks where the problem space and the solution are simple, you can skip writing a spec and move straight from the grilled plan into implementation using /implement this.

Big: For larger features or changes with lasting architectural impact, turn the grilled plan into a written specification (using /to-spec) and record Architectural Decision Records (ADRs) when making structural choices.

The plan should definitely be persisted as a spec in markdown or your issue tracker of choice. Look into /setup-matt-pocock-skills for that. Right now I am using a small project I found on GitHub, called Boardown, to persist all my local markdown issues. Maybe I will share more on that in the future if I keep using it.

Large specifications overwhelm model context windows if passed all at once. Slicing breaks the specification down into discrete work units using /to-tickets. Instead of having to implement everything in a single session going forward, the skill slices the spec into smaller tickets. You can then just call /implement #42 in a session to implement a slice of the spec.

3. Implementation

Implementation executes one frontier ticket at a time. I don’t like to hand this off as a completely autonomous task where you let the agent run free for an hour (yet).

Instead I like to focus on a tight review and steering loop while the task gets implemented. This might sound contradictory to the main offering that agentic coding brings us: speed. But actually following all implementation steps and continuously reviewing the diffs helps catch architectural flaws that the agent might miss, and more importantly, it greatly helps in understanding the implementation yourself.

Changes that pass my review get staged immediately. This prevents the agent from undoing good work or making uncontrolled modifications across the working tree.

4. Code review

Reviewing agent-generated code is then an (Agentic + Human) split. The review consists of two steps:

1. Agentic review (/code-review): An automated reviewer pass checks the diff along two separate axes. The first axis checks repository standards, such as lint rules, conventions, and formatting. The second axis checks on correct implementation of the spec, confirming the diff actually satisfies the ticket requirements without introducing scope creep.
2. Human review: You review the diff directly in your editor before committing. The human check ensures the business logic makes sense and that the implementation fits into the existing architecture.

5. Retrospective

After a session is finished, I close the loop with a brief retrospective using /retro. This is a quick pause to reflect on how the session went:

• Did the agent drift or struggle with specific commands?
• Can something be checked programmatically in the future instead of having the agent spend a lot of tokens on it (e.g. linting, prettifying, …)?
• Did we need to steer any assumptions that could become part of the AGENTS.md or GLOSSARY.md?

What’s next?

Comparing this workflow to where things stood in early 2026, the progress is big. Early on, agentic engineering for me was mostly about basic planning modes, managing prompt context, and watching diffs. Tooling and automated CI/CD are more important than ever.

With all those skills emerging from the community of software developers all over the world, the workflow seems to mature. Writing code by hand is basically obsolete and we as Software Engineers shift more and more towards speccing.

It will be interesting to see if the big coding harnesses like Copilot and Claude Code will adopt the functionality of those skills and what this means to using this specific workflow. For example, /grilling already appeared in the Antigravity CLI. Maybe these skills will either need to be modified, not used at all, or harnesses like Pi will increase in popularity as the developer can control the harness functionality much more here. Let’s see what 2027 brings.