A year ago my team started using Claude Code to assist us in writing code. Instead of changing the way we work, we tried to make the way we already work “agentic”. This is the story, and a few things I have learned along the way.

“Does AI make us more productive?”

You have probably heard this question in your team already. Or heard people claiming that AI will, for sure, make you more productive. Maybe, as I did, you felt a bit of skepticism about it. I was totally skeptical about the idea of something else writing, or better, generating code instead of me. I thought my work would double: 1) review the mess generated by the AI, and 2) rewrite it from scratch the way the team and I wanted.

After one year, I can say I was wrong to be skeptical.

One year ago, our product manager at Hemnet, Michelle Rea, kept poking us, the team, about using AI to be more productive. It was one of the liveliest discussions we ever had in the team: we developers were skeptical, she was more than optimistic. It was a Friday afternoon, the last week of November. That very same day we ended up generating a small admin feature for our internal backoffice, and released it to production. The best way to assess something is to try it before jumping to any conclusion. It worked. From there, a new journey started in our team.

We started using Claude Code to assist us in writing code, and step by step we ended up with an agentic workflow that helped us speed up our development process, while keeping our code standards in place.

After a while, what we built in our team became an example for other teams and colleagues.

In this post I want to share what we did and what I have learned so far. It is not a recipe, it is just our experience. Perhaps some of it will be useful in your context too.

What I mean by agentic workflow

An agentic workflow is not “the AI that writes the code for you, alone”.

The way I see it, an agentic workflow is a structured process made of an agent, specifications, guidelines, and guardrails. It is a repeatable pipeline that:

  • describes the way you and your team are already used to work,
  • organizes and consolidates your common principles and practices,
  • helps with consistency,
  • is grounded in your real context, not a generic one.

The workflow and the experience matter more than the AI. AI is a tool.

Looking back, there are three ideas that shaped our journey the most.

The workflow was already there, we made it agentic

We didn’t invent a new process, and there was no AI “magic wand”. We already had a way of developing product changes, and we tried to make each of its steps agentic:

  1. Plan the feature. Agree on the specification (a.k.a. what to develop) before writing any code.
  2. Implement the feature. Test-first, or strict and incremental TDD, one test at a time.
  3. Organize the commits. Shape a clean, semantic, and reviewable story of the changes.
  4. Create the pull request. Write a brief and human-readable description for the reviewers.

At first, there was no skill at all. It was just a custom prompt describing these steps, which we gave to Claude as input. Only later, as the prompt grew, did we start to extract each step into its own skill: a small set of instructions the agent follows for one specific task. That is when the prompt became a workflow. What worked well for us was to keep each skill:

  • small and focused on one task,
  • self-contained and composable, so it can be used on its own,
  • code agnostic, while code-specific guidelines live in the code repository,
  • easy to resume or restart, keeping track of the progress in local markdown (or version-controlled) files instead of relying on “memory”.

Keeping the skills code agnostic paid off: we ended up using the same workflow for the backend, the web, and the mobile apps.

For the client side, web and mobile apps, we went a step further. We connected the agent to Figma and/or Miro, together with our UX design guidelines, so that the agent was able to implement a first version of a feature while keeping the design rules in place, aligned with the rest of the company.

Since the skills are isolated from each other, we could change the workflow by putting more skills to work together. For example, when a feature was too big for a single pull request, we added a multi-phase flow on top of the same four steps: one main plan, and many small phases that go through the normal flow. We even ran phases in parallel through git worktrees, it was crazy!

Fundamentals still decide the outcome

What I noticed is that the agent amplifies the habits we already have. Good practices get multiplied, and so do the weak ones. When the guidelines don’t cover enough, the worst thing is to see the agent drifting on its own. So we tried to catch these drifts and keep the skill definitions always up to date. Treat your skills as a living artefact.

This is why tests, conventions, and small increments still made the difference for us. On top of them we added guardrails: linting rules, tests to validate every code change, and checklists the agent goes through before a step is considered done. Test-first (or TDD) and incremental changes give the agent a way to quickly check whether the current implementation is going in the right direction, instead of implementation first and tests after. Tests are part of the implementation process.

As I said, the guidelines were not written in one go. They grew one learning at a time, every time we noticed something worth keeping. Rules like “always ask before pushing”, “database migrations go in separate commits”, or “implement one test at a time” all came from real situations. At some point we also asked the workflow to suggest new guidelines after each pull request review, so that feedback had a chance to become a shared practice.

The specification as the unit of work

The biggest shift for me was this one: the specification became the primary unit of work, and the code became the output. Design decisions moved into the specification, where we discuss and agree on them before any code is written.

As a team, we are used to pair and, lately, more and more mob programming. We always discuss what to do together, product manager included, and then write the specification in a pair, as a mob, or solo.

And the human stays in the loop. The process is supervised, every step asks for confirmation before moving on, and we still review the code as we always did.

Some time ago I had a conversation about all of this with Pietro Di Bello and Matteo Pierro, when I presented the workflow to them. Pietro summarized it in Eight takeaways from a conversation about agentic workflows, which I think is a great companion to this post.

Why it worked well for our team

Looking back, the biggest change was where our time goes. Most of the team’s time shifted from the act of typing code to the two ends of the workflow: writing the specification and reviewing pull requests. With more work done, there was also more work to review.

Here is why I think the review step still worked well for us. It comes from a few habits we already had:

  • Tight feedback loops. We used to release small changes, one at a time. This kept our pull requests small and focused. Small and focused doesn’t necessarily mean few file changes: renaming or moving packages and modules from one place to another can touch a lot of files, but the pull request is still small in terms of context.
  • No surprises at review time. Working in pairs and mobs, the work was already implicitly reviewed while defining the specification and while working together. Reviewing a pull request was, for us, more of an act of acknowledgement.
  • Context upfront. Moving most of the work a little bit upfront, into the specification, kept context switching and cognitive load low. During the review there was no need to understand the nature of the change from scratch: we already had the context.

What I have observed so far

In our experience, the agentic workflow helped us to:

  • Reduce context switching and keep the cognitive load low, because everything is in the specification.
  • Be more consistent: commit hygiene, PR quality, and conventions are applied every time.
  • Keep shared practices on point across the team.
  • Spend much less time on development.

There are also situations where I think it might not help as much:

  • The codebase has no good structure or reusable patterns in place yet.
  • The code is not “agent-ready”: no AGENTS.md, no Architectural Decision Records, no clear instructions.
  • Leaving it running fully unsupervised. I am not feeling confident about it yet.
  • A lack of knowledge and experience of software engineering practices to understand what the agent is actually doing.

What about junior developers?

I have heard that it will be difficult for junior developers to find a job because of AI. I think it’s a cultural thing. My take is that junior developers, if supported by more experienced developers, would benefit a lot, in terms of knowledge, from using agentic workflows like these. They could use the agent to learn more about the practices of software engineering, speed up their learning, and grow faster and better as software engineers.

In that context, AI can be a great source of knowledge, for example when juniors ask about specific decisions taken during the workflow: “Why did we follow test-first here instead of TDD?”

Automate what you already do

Here is a small exercise that might be a good starting point:

  1. Write down the steps you already follow to ship a change, from the idea to the pull request.
  2. Pick one step, maybe the most repetitive one, and turn it into a skill: a short set of instructions, with a checklist of what “done” means for you and your team.
  3. Try it on a real, small task, keep an eye on it, and every time something goes wrong, add one guideline.

References