The parts nobody enjoys

“I just want to show that my code works but not necessarily want to do the less interesting part, which is fully reading the requirements, reading all the documentation around it, creating new documentation, creating all of my unit tests…”

Most engineering teams already know what “good development” looks like:

• proper debugging procedures
• documentation
• requirement validation
• edge-case analysis
• testing
• architecture reviews
• code consistency checks

But, when deadlines are tight (and they always are), and project managers and product owners push for ‘something in production by yesterday’ (and they always do): engineers naturally focus on proving that the code works and shipping it.
The less exciting work (updating documentation, checking naming conventions, validating assumptions, reviewing legacy dependencies, writing comprehensive tests) often gets shortened or skipped entirely. Added to the technical debt backlog.

At one of our semiconductor customers, bug fixes often bounced back and forth between development and QA. Engineers would commit code, QA would review it weeks later, and bugs would return with comments about missing tests, naming conventions, documentation gaps, or overlooked edge cases. Fixing a bug could easily take six days.

That is why the first agentic workflow we discussed to tackle with this semicon customer was the debugger workflow – with the goal of lowering the time for bug fixing from six days to much less. We are still in the phase of actually measuring it, but expect to lower it to under two days. Quite cool!

Step 1: we brainstormed with the engineering lead and architects on the ‘theoretical’ debugging process. What do they want the steps to be?
Formally their process contains more than 15 steps. However, the team openly acknowledged that engineers rarely follow all of them in practice.

This is exactly where agentic workflows become valuable. They help to consistently follow the steps:

• surfacing relevant system knowledge automatically
• enforcing quality gates earlier
• generating clearer pull requests and documentation
• validating requirements before code reaches QA

Step 2 is of course: to build that 15-step flow in an agentic workflow, and nudge each developer into using it. The interesting part is that the workflow is not one giant AI agent. It consists of smaller skills. Each skill removes a small source of friction. Together they significantly reduce rework. And for the engineers, the debugger workflow removes a large amount of frustrating rework. Instead of repeatedly hearing: “Please fix naming conventions, missing edge cases, or missing tests”, those checks happen proactively during development.

“If I follow it because it's already built for me as an engineer, I get that productivity boost and at the same time I get that extra quality.”

So as developer you now work hand in hand with your agents, via the steps of the flow.

“After we finish, we agree on the unit tests. After that is done, I review the code. After that, we automatically send the PR that has clear comments, clear descriptions, all of that.”

Agentic Workflows: a structure around Engineering Best Practices

That exactly is what for us is the benefit of agentic engineering. An agentic workflow guides the engineer through a structured process that is difficult to skip.

For example, this is how it would work if you want to develop a new feature.
It asks you: where is the problem statement? And what are the requirements?
Then together you start looking at the tech stack and designing the architecture, based on the documentation and context the agent already has.

Next together you look at potential edge cases. And define what unit tests are needed to prove all works. While doing that, the agent looks at the legacy code to see what is similar to what you are trying to develop.

Instead of relying entirely on individual discipline or seniority, these quality checks become embedded into the workflow itself. The result is more reliable development. And processes that previously lived only inside the heads of senior engineers become repeatable and accessible across the team.

Following the agentic workflow magically makes junior engineers operating at a higher level: they are exposed to senior-level thinking much earlier. The workflow itself continuously teaches them how experienced engineers think.

At the same time, it increases the importance of senior engineers. Senior engineers become the people who define quality gates, evaluate tradeoffs, guide architecture, and validate whether generated solutions actually make sense. Judge the code that they are reviewing while enforcing the juniors to continue thinking:

“You need to be able to understand what's being pushed. If you do not understand it, I'm not going to approve it.”

The strongest engineers will not be the people who type the fastest. They will be the people who best understand systems, context, and quality.

In many ways, AI raises the bar for engineering maturity. One engineer in the discussion described it well: “I’m not becoming less technical. I’m becoming more like a senior engineer all the time.” The engineers who thrive in an AI-assisted environment will be the ones who continue learning, questioning, validating, and improving the systems around them.

The goal of using agents is not blind automation. The goal is accelerated understanding. And that may ultimately be the biggest shift of all.