DEV Community: Taras Lysyi

How I Completed 70+ Jira Tickets Using AI Agents (and Slept Through It)

Taras Lysyi — Thu, 26 Feb 2026 17:34:35 +0000

We had ~70 legacy Go API endpoints that needed migrating to a modern framework. Instead of doing it manually ticket by ticket, I built a multi-agent AI system that grouped, delegated, and executed migrations autonomously — including running overnight while I slept.

The agents coded all ~70 migrations in just 2 days. The remaining weeks were spent on code review, feedback cycles, and merging PRs into the codebase.

Results: ~30 PRs opened. Most merged or in review. Code quality: 8/10.

This entire article was vibe-coded during a morning walk using voice chat, then lightly edited. That's the world we live in now.

Tools Used

MCP Integrations (Model Context Protocol):

Jira MCP — connects directly to the project board, pulls all migration tickets with descriptions, acceptance criteria, and links to legacy code
Git MCP — branch creation, commits, pull request management
Filesystem — direct access to the codebase for reading and writing

Claude Code CLI — the runtime that orchestrates everything. Previously I used Claude inside Cursor, but switched entirely to Claude Code CLI — it handles larger changes and runs multi-step workflows autonomously.

Skills Hierarchy

Skills are reusable workflow templates. I built a hierarchy where each level calls the next:

migrate-batch              ← INPUT: list of ticket IDs
  └─ for each ticket:
      └─ migrate-fullstack     ← runs FE + BE together
           ├─ migrate-backend      ← backend migration
           └─ migrate-frontend     ← frontend migration

migrate-batch — takes a list of tickets, groups similar ones into logical PRs (e.g. all User endpoints in one PR), then kicks off migration for each group. This turned 70+ tickets into ~20 focused PRs instead of 70 scattered ones.

migrate-fullstack — splits work into backend and frontend streams running in parallel. Each stream knows its own context and patterns.

migrate-backend / migrate-frontend — the actual migration workers. They're pre-loaded with codebase standards, test patterns, and target framework conventions.

Custom Agents (The Team)

Inside each migration, specialized agents handle different layers of the codebase. Think of them as a dev team where everyone is an expert in their area:

Orchestrator — the tech lead. Reads the ticket, delegates to specialists, tracks progress, collects results. Never writes code itself — only coordinates.

Code Researcher (read-only) — the analyst. Digs into the legacy Go code, traces the full request flow, documents all dependencies, business rules, edge cases, and the request/response contract.

Store Agent — the database specialist. Writes the data access layer and tests. Knows the project's SQL patterns, handles null checks, parameterized queries.

Service Agent — the business logic expert. Wires up store calls and external APIs into endpoint handlers. Implements all business rules identified by the researcher.

External API Agent — handles integrations with third-party services. Knows retry patterns, error handling, timeout configs.

Reviewer Agent (read-only) — the senior reviewer. Checks correctness, pattern compliance, test coverage, security. Returns specific feedback with file and line references.

Execution order: Researcher → Store → External API → Service (assembles everything) → Reviewer → fixes if needed → PR ready.

Each agent has its own context window, its own tools (some are read-only for safety), and its own system prompt with detailed instructions.

Key Principle: Atomicity

The most important insight: learn the first migration manually, then scale the pattern.

I spent 2–3 days setting up the system:

Did the first migration hands-on, understanding every step
Encoded each step into an agent with specific instructions
Compiled agents into skills with clear input/output contracts
Tested on a few more migrations with manual review
Once confident — launched batch migration

Without this upfront investment, the agents would produce inconsistent, low-quality code. The 2–3 days of setup paid for themselves on the first batch run.

Running Overnight — 2 Days of Agent Coding

The entire batch of PRs was generated in roughly 2 days of agent runtime. Here's how:

Claude Max has usage limits — I hit them multiple times during heavy migration runs. The limits reset approximately every 4 hours.

My solution: when the system hits a rate limit, it automatically pauses and retries after the cooldown period. I launched the batch migration on my laptop, went to sleep, and woke up to completed PRs. Between the active coding sessions and overnight runs, all migrations were coded within ~2 days.

The weeks that followed? That was the human part — code review, feedback from the team, fixes, and merging. The AI was literally working while I was sleeping.

Results

Metric	Value
Total tickets migrated	~70
Pull Requests opened	~30
Batch-generated PRs	~25
Agent coding time (all batch PRs)	~2 days
Review & merge period	~3 weeks
Code quality (self-assessed)	8/10
Setup time	2–3 days

Conclusion

The agents wrote all the code in 2 days. The humans spent weeks reviewing, refining, and merging it. That's the real takeaway — AI doesn't eliminate the human, it compresses the mechanical work so you can focus on the parts that actually need your brain.

Was I satisfied with the code quality? 8 out of 10. This was an experiment, but the results are real — PRs have been reviewed, approved, and merged into the codebase.

Does it still need a human in the loop? Yes. Every PR goes through review. The AI handles the boilerplate and repetitive structure, but a developer still validates the business logic and edge cases.

Can it get better? Absolutely. With more investment in agent prompts and codebase-specific training, this system can approach near-autonomous migration quality. Each iteration gets more accurate.

My recommendation: start small. Take one ticket. Build one agent. See how it works. Then scale. The tooling is ready — MCP integrations, custom agents, skills, batch processing. The question is not whether AI can help with your migrations. The question is how much time you're willing to invest upfront to make it work.

Try it. Test it. Iterate.

Vim keybindings for efficient text editing

Taras Lysyi — Sun, 17 Jul 2022 04:30:54 +0000

Hello, I am Taras. I am working as a backend developer.

If you’re a software engineer, you probably heard about Vim, a free, open-source, screen-based text editor program.

In this article, I’ll show you how you can radically speed up your development workflow by leveraging one of the most potent things about Vim — its keybindings — without even having to use Vim.

You might be thinking, “ugh, keybindings, too nerdy and difficult, I don’t need that”… Hold on! It’s not as difficult as you might think, and you don’t need to memorize all of them. Once you understand the core logic behind keybindings, the following experience should come naturally. Let me show you!

What is so special in Vim keybinding?

Vim has different editing modes and it lets you use easy-to-remember keybinding without needing to add a couple of key modifications (ctrl+shift+…, alt+shift+…). It has it's language for editing text. And once you get the basics you can combine them to do different actions. Everything you can think about editing text there is probably a keybinding for it, if not you can easily create it. Let's start with Vim modes.

Normal Mode

You can’t write text in this mode. By default, Vim starts in this mode. In Normal mode, key presses don’t work as one would expect. This mode is responsible for editing and moving around. Remember, this is what makes Vim different.

Basic movements that I use on a daily basis

Cursor movement:

h move one character left
j move one row down
k move one row up
l move one character right

If you are a touch typist like me you will like these movements because you don’t have to leave a ‘home row’. Keys ‘h’ and ‘l’ were easy to remember for me but ‘jk’ took me some time to used to.

Word movements:

w move to the beginning of the next word
b move to the previous beginning of the word
e move to the end of the word
ge move to the end of the previous word
W move to the beginning of the next word after a whitespace
B move to the beginning of the previous word before a whitespace
E move to the end of a word before a whitespace

Beginning/End of line movement:

0 move to the beginning of the line
$ move to the end of the line

targeted movements:

move to the next occurrence of the current word under cursor: ``
move to the previous occurrence of the current word: #
move (un)til character: t<char>
move back (un)til character: T<char>
move to found character: f<char>
move back to found character: F<char>
move to match: /<regex>
move back to match: ?<regex>
move to the next occurrence of a match: n
move to the previous occurrence of a match: N

Most keybindings are mnemonic (w - word, e - end) and some of them have regex expression philosophy beyond.

Insert Mode

This mode works the way text editing works throughout the OS. Same shortcuts (cmd+c, cmd+p, etc), same movements (arrow keys, page up/down, ctrl+a, ctrl+e, etc). To exit this mode you need to press escape

There are many movement commands that can result in switching to Insert Mode:

insert before letter under cursor: i
insert after letter under cursor: a
insert at the start of the line: I
insert at the end of the line: A
insert on a new line: o
insert on a new line above: O
substitute: s
change: c

Visual Mode

A mode for creating selections. This mode can be extremely useful for identifying chunks of text to be manipulated (e.g. apply reg expression for selected text).

To enter Visual Mode (starting from Normal Mode):

v to select by character
V to select by line

A Language of Text Editing

I really enjoy mnemonic keybindings, because they are easy to remember. Vim has them! Many keybindings can be conveniently thought of as the "verbs", "nouns" and "prepositions" that make up the "language".

Examples of "verbs":

change (c)
replace (r)
substitute (s)
delete (d)
yank (y)
put (p)

NOTE: 'change', 'replace', AND 'substitute' aren't the same thing!

Change deletes everything in the next movement and puts you in Insert Mode (though with a selection, it behaves like a substitute).
Substitute immediately deletes the current character (or selection) and puts you in Insert Mode.
Replace never enters Insert Mode at all, but just replaces the current character (or every character in a selection) with the provided character.

Examples of "nouns":

word (w)
end (e)
beginning (b)

Examples of "prepositions":

inside (i)
around (a)
(un)til (t) You can combine these parts of the "language" to perform editing tasks:
delete to the end of a word: dw (or de)
delete the current word: diw
yank to the end of word: ye
change inside parentheses: ci) (or ci()
delete around brackets: da] (or da[)

Of course, Vim has more editing and movement commands and I want you to give it a try. I am sure that it can be a life-changer for your workflow!

Afterword

Awesome personal remaps that I think are really helpful

Remap CAPSLOCK to ESC if pressed alone, and to CTRL/CMD if pressed with the key. For me personally, it's easier to reach out.
Remap WIN/OPTION + hjkl to arrow keys
Remap WIN/OPTION + N go to the next word and WIN/OPTION + P go to the previous word

Where I use vim keybindings

Neovim - my main text editor.
Terminal I am using zsh-vi-mode plugin for zsh.
Obsidian for writing notes
Google Chrome I am using Surfingkeys plugin for browsing