Intro – my standard flow

In my daily work, I have consistently followed the same workflow (also before AI era).

1. Understand the problem
2. Create tasks (for the given problem)
   1. Provide a brief description why this change is needed
   2. A detailed technical description – I always tried to capture everything I’d discovered from the code: class names, which methods to change, which new methods to introduce, and any “gotcha” moments to watch out for. For me, a task was never just a business description of a unit of change; it was already a technical plan. This was particularly vital for intricate tasks and for work intended for subsequent implementation by others
   3. Detailed testing plan – what are the green paths and most crucial cases to cover, and some important edge cases to cover
   4. Identify dependencies and break the work into manageable parts suitable for both development and review, even though I sometimes struggled to optimize the size of tasks for efficient review.
3. Execute the tasks according to the specifications

With this method, I consistently retained sufficient context to resume implementation – even after weeks of delay – without needing to rediscover information from scratch.

Enter AI: the same flow, supercharged

The fundamental flow hasn’t changed. What’s different is that I now use AI to make my specs even more detailed and to keep me in check. ( Rovo Dev CLI – comes with built in skill research which is really great for such investigations and validation of thesis!) Here’s what the process looks like today:

So now it’s

1. HUMAN: Understanding the issue and incorporating AI that enables me to identify hidden implications and boundary conditions I may have overlooked. (This goes into multiple levels depending on complexity – from small features to big architectural changes – the flow remains the same – only scale and perspective change)
2. Create tasks for the problem
   1. HUMAN I begin the process by using AI to draft a technical plan, leveraging the skills from either native Rovo Dev CLI (research skill with plan mode) or you can try any other technical planner skill with Rovo Dev as for example Superpowers.
      1. (Side note) Superpowers offers several valuable skills that are particularly effective for vibe-coding – ideal for Hackathons projects – and for synchronizing your efforts with the AI on greenfield initiatives.However, for complex, existing projects where you take the lead, these skills can consume time (and tokens) without delivering sufficient value. I therefore selectively choose only a handful of them
   2. HUMAN: Based on my understanding of the problem (Step 1) and the context already loaded in the session, I write a lightweight plan listing the key change-points. It’s a much simpler version of what I used to do manually – I just point to the main classes, methods, and what to add, change, or watch out for. The goal is to make sure AI follows the repository’s existing patterns and my architectural vision
   3. AI writing-planswith research skills explores those points and produces a first draft – a structured list of tasks with dependencies in Markdown format
   4. AI Walks through every task (every step, one by one, is reviewed and confirmed) with me HUMAN to confirm the solution
      1. AI The resulting plan is far more detailed than anything I’d write by hand – exact class names, test scenarios, method signatures with parameters, flows, conditions, and feature flags. Pretty much ready as a prompt (well, Specs) for AI
      2. HUMAN I have the opportunity to refine each task – this happens in half of the provided steps, which shows it’s essential despite my initial simplified specifications. This suggests a healthy collaboration with AI
   5. HUMAN Finally, I ask AI to create the Work Items in Jira following our team’s conventions (labeling, prefixes, etc.)
   6. The result: specs that are far more detailed than anything I ever wrote manually in the past – and detailed enough for any AI agent (Rovo Dev in Jira) to pick up and implement
3. Based on priority and dependencies, I HUMAN now choose one of two paths:
   1. AI Run the Work Item implementation directly in Rovo Dev in Jira for low/medium complexity tasks. With that, I can run multiple Work Item implementations at once directly in Jira and work on them simultaneously
   2. Or run AI it locally (Rovo Dev CLI) for high-complexity tasks, adding my own comments and taking it step by step with me HUMAN in control, approving every step, adapting to requirements. I’m able to see live how code is being built step by step, so it gives me more time to dynamically evaluate if the approach I’ve put into Specs is actually correct, so I can easily pivot mid implementation (true pair programming)
      1. The goal is to catch wrong changes early, before they compound
      2. HINT In Rovo Dev CLI use /review tu run interactive UI and AI to review the code changes, where you can put your own comments and also see really great graph of changes

Simple example of such Specs in Work Items

Why the Spec Driven is also great for reviewers?

Because at the end Rovo Dev will do review based on specs and show you this in your Bitbucket PR – completing the AI loop of: Specs → Implementation → Review.

What this actually looks like in practice

Results for low/medium complexity tasks

Looking at my last seven changes made with Rovo Dev in Jira: about five of them needed between one and four additional prompts to address additional requests I had – and by that I mean more test coverage, different structure for maintainability, moving some of the methods to other class. Two of the seven needed no corrections at all (well, for one of them I manually tweaked a JavaDoc – you can still do manual changes in Rovo Dev in Jira!).

So is it now officially AI magic?

Not really. The spec-driven part, where I’m constantly in the loop, is essentially pair programming. I’m in the driver’s seat:

• Deciding exactly how the code changes should look from a local architecture perspective – classes, methods, flows, conditions, tests
• Reviewing every step of the AI’s detailed generated plan
• Improving the changes post-implementation

It shifts the focus of responsibility. If you’re used to teaching or mentoring others, this feels like the most natural workflow – you’re literally pointing at what to do, and leave coding and double checking your vision to colleague (AI).

So why not make it magical and automate everything?

In this blog, I’m describing the simplest, standard approach for spec-driven development with AI that gave me the most satisfactory results for complex projects – where the results generated by AI are exactly what I would expect if I wrote the code myself. It makes debugging, maintainability, and architecture much more stable – and with heavy use of AI – the stability, ratio of bugs and understanding of the flows are now even more important.

But as this blog post is only for basic understanding of it, this flow can be scaled much further to become semi-autonomous using Jira Automations, Confluence, and other Atlassian tools. You could imagine communicating with AI through Jira comments or Confluence pages and Rovo Dev being triggered using Jira Automations (and, well, Rovo pinging you for feedback on a plan) for implementation, creating PR and later reviewing it.

Results for complex tasks

And what are the results for complex tasks?

Complex tasks naturally take more time because I insist on stepping through each stage with my confirmation, keeping everything in a tight review loop.

I’ve learned that staying actively involved in the loop saves more time than letting AI run unsupervised for 20-30 minutes, only for it to get stuck and try to resolve issues heroically with something that doesn’t make sense or goes against the given requirements, or becomes too complex for maintainability. For me, maintainability with AI is really important. You can always create a lot of code with AI, but with that accelerated momentum, each subsequent change will be more complex and more prone to bugs. We need to keep it in check for your software development flow to scale.

To emphasise this, “pair-ai-programming” gives me a live view of the code, so I can interrupt when I spot a mistake and redirect the work. I can also split the session (/sessions fork) into two contexts to compare how each approach looks in code and discuss the best approach of two. At that place I’m also using /memory reflect if I spot common problems, or good approaches that should be used for other tasks driven by AI, so Rovo will improve its rules for the future.

Important distinction. This is not vibe-coding

It’s worth stressing that this is nothing like “vibe-coding.” The specs come from you, and the code is shaped by your existing codebase (this example is not a greenfield project, but live production one). If your code quality is solid, AI will follow those patterns – just make sure to point them out explicitly. But if your code is already overly complicated, AI will struggle with it. The key is keeping AI close to your current repository patterns and flows, rather than letting it invent a new approach with every session or model switch, and from my experience, each model has its own implementation quirks, so if you leave it be and approve everything, your codebase quality will gradually decrease – making you less productive.

For less supervised flows, you would have to put more focus on E2E tests, to at least keep in check business quality, if not the code one.

For actual vibe-coding projects (Hackathon alike) – this approach with Spec-driven development will actually give you at least some confidence about having a somewhat maintainable codebase for your project to later be improved to production quality.

Good Hacks and Tips to Maximize Your Rovo Dev Experience in Jira

Enhancing AI Prompts and Skills Within Jira – Self-improvement flow

My team and I heavily rely on Rovo Dev in Jira to power numerous automated processes. Some use cases include:

• Cleaning up feature flags
• Analyzing Help Channel queries with AI
• Generating code automatically for recurring tasks
• Updating internal documentation based on feedback received via Slack or Work Items
• Revising the FAQ in response to Slack or Work Item insights

We run multiple automations triggered by specific conditions or transitions, executing Rovo Dev in Jira with prompts stored in our repository.

When an automation needs enhancement – whether to accommodate new requirements or to tighten the output to match your team’s specific conventions – continuous improvement is essential. To support this, we developed a “Jira-native” self-improvement workflow: a flexible command and Jira automation that refines any AI process running within the scope of a Work Item.

How it works

This is a general outline of the steps involved in executing our prompts via Jira automations with the Rovo Dev platform

For instance, here is the workflow we use to analyze threads in our help channel.

1. An internal help channel Work Item is closed.
   • Feedback and any pending queries may cause the Work Item to transition to the ‘Analysis’ state before final closure is granted.
2. Jira automation is triggered.
3. The automation updates Work Item labels by invoking a skill that retains the original name of the executed command.
4. The system analyzes conversation threads and stores the resulting data in a custom field

The self-improvement flow

Suppose we want to refine the output – maybe the format needs adjusting for a new use case, or we’ve learned a better way to handle a particular scenario.

So the flow goes like this:

1. Open the work item
2. Write a comment describing the problem
3. Jira Automation kicks in and invokes the improve-command stored prompt (which we have in our repository and use both directly in Rovo Dev CLI and in this automation)

Executes command via Rovo Dev “Generate code” action.

Note: The setting “Infer repository from Jira work item“ makes Rovo Dev try to infer the repository URL from your Work Item before starting the session. Ensure you mention your repository in the description – just “Use {workspace}/{repository name} repository“ should suffice!

4. The command checks whether it’s running in a Work Item context and looks for a command-{command/skill name} label
   1. If it’s not running with Work Item context, because someone has executed it locally, it will ask for the proper context
5. It finds the original command file based on the label
6. Applies the improvements
7. Creates a pull request

Why this matters

As we add more AI flows, we’re constantly finding ways to make them sharper – adapting to new edge cases, evolving team conventions, or incorporating lessons from recent work. This pattern gives everyone on the Team a single, consistent way to contribute improvements, without any need to know the internal workings of the executed saved prompt or skill.

Two short automations where we are using this self-improvement flow day-to-day

Automatically updating our FAQ from Jira and Slack

We maintain an FAQ page in Confluence that powers our Rovo Agent that works in Slack. This Agent also syncs Slack conversations with Work Items, where the automations run.

With this flow, you don’t even need to remember the FAQ page exists. You just:

• Make a comment mentioning the FAQ in a help channel thread (it’s so natural that people are even surprised that the FAQ was updated). Eg.:

Based on this conversation we should update our FAQ to remember this specific case handling.

• Wait for the work item to be closed
• Jira automation kicks in with Rovo Dev in Jira and updates our Confluence page (additionally, we always provide a label that it was generated by AI and the link from which conversation it was generated)

Automatically updating our developer documentation from Jira and Slack

Sometimes we need to improve our internal documentation. This improvement can come from different flows: standard implementation Task, discussion on Work Item, etc.

1. Add label to Work Item: internal-documentation-improvement
2. Describe what you want to improve (we also use the Slack → Jira integration to make this step automatic) if this Work Item does not yet contain any feedback/context on updating documentation.
3. Jira Automation kicks in and runs Rovo Dev in Jira with stored prompt: update-internal-documentation.md 
4. And we get a generated PR with improved documentation to review.