Trabalhando com workflows do Kiro

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Working With Kiro workflows · Canal: Kiro · 06:51 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

O vídeo mostra como criar, revisar e executar no Kiro um workflow reutilizável para atualizar dependências. O processo inclui análise do projeto, alterações no código e três verificações paralelas, com correções e novas tentativas caso algo falhe. Cada etapa pode usar um agent, um modelo e um nível de raciocínio diferentes, enquanto o usuário continua interagindo com o Kiro. Em comparação com instruções em skills ou arquivos agent MD, workflows definem explicitamente a ordem das tarefas, as etapas paralelas e as condições para avançar ou repetir o processo.

Pontos-chave

Um workflow pode transformar um processo repetível, como atualizar dependências, em uma sequência reutilizável de etapas.
O fluxo de exemplo analisa o projeto, modifica o código e executa testes, build ou verificação de tipos e revisão semântica em paralelo.
Se uma verificação falhar, o workflow retorna ao agent de código para corrigir o problema e repetir as verificações.
Cada etapa pode ter seu próprio agent, modelo e nível de raciocínio.
Workflows podem ser criados no nível do workspace ou globalmente e revisados em um formato visual ou na definição JSON.
A execução ocorre em segundo plano, e o usuário pode interagir com a sessão principal e com as sessões de cada etapa.
Ao contrário de instruções que deixam decisões de execução a cargo do agent, workflows especificam regras como paralelismo, tentativas e critérios para avançar.
Como workflows são arquivos, podem ser mantidos em controle de versão, revisados e compartilhados com a equipe.

Capítulos

Início	Capítulo	Resumo
00:00	Por que usar workflows	O vídeo apresenta a diferença entre descrever um processo e definir explicitamente como ele será executado.
01:05	Criar e revisar um workflow	O Kiro gera um workflow reutilizável, que pode ser configurado, inspecionado e editado.
03:14	Executar o workflow de atualização	O processo analisa as dependências, aplica mudanças e executa verificações paralelas, repetindo as etapas quando necessário.
05:48	Workflows em comparação com instruções	O vídeo explica como workflows oferecem controle explícito e podem ser versionados e compartilhados com a equipe.

Citações

Se alguma dessas verificações falhar, ele volta, corrige o problema e executa todas elas novamente. — 00:31

Iniciar um workflow não bloqueia a conversa. — 03:14

Todas as três verificações precisam passar para que o workflow avance. — 04:47

Com um workflow, essas regras de execução são definidas explicitamente. — 06:19

Você pode mantê-lo no controle de versão, revisar as alterações e compartilhar o mesmo workflow com o restante da equipe. — 06:51

Conceitos e entidades

Kiro (ferramenta): Ferramenta de desenvolvimento com agentes usada para gerar, revisar e executar workflows.
Kiro IDE (ferramenta): Interface do Kiro usada na demonstração para criar e executar o workflow.
workflow (conceito): Definição reutilizável que especifica etapas, paralelismo, tentativas e configurações de execução.
Claude 3.5 (modelo): Modelo usado na etapa de análise, que exige bastante raciocínio.
CLI (ferramenta): Interface mencionada como uma das opções, além do Kiro IDE e do Kiro web, que oferecem suporte a workflows.
Kiro web (ferramenta): Interface web do Kiro que também oferece suporte a workflows.
recipes (conceito): Painel do Kiro onde os workflows ficam disponíveis, incluindo receitas integradas para padrões comuns.
skills (conceito): Instruções que podem descrever um processo para um agent, mas não definem necessariamente suas regras de execução.
AGENTS.md (conceito): Arquivo de instruções para agents, citado como alternativa para descrever um processo.

Tradução completa (pt-BR)

00:00 Hoje, um agent de programação inteligente consegue lidar com trabalhos bastante complexos. Você pode dar um prompt ao Kiro ou colocar o processo da sua equipe em um arquivo de steering ou agent MD, e o agent pode seguir essas instruções. Mas, às vezes, você não quer apenas descrever como o processo deve ser. Você quer definir exatamente como ele será executado. É aí que entram os fluxos de trabalho. Vamos criar um fluxo de trabalho reutilizável para atualizações de dependências. Digamos que precisamos atualizar dependências em diferentes projetos e queremos seguir o mesmo processo todas as vezes. E aqui está o

00:31 fluxo de trabalho que vamos criar. Primeiro, queremos que o Kiro analise o projeto que precisamos atualizar e descubra o que precisa mudar. Em seguida, ele faz as alterações no código. Depois disso, três verificações são executadas em paralelo. A primeira executa os testes. A segunda executa o build. E a terceira revisa as alterações em busca de possíveis problemas de compatibilidade. Se alguma dessas verificações falhar, o fluxo volta, corrige o problema e executa todas as verificações novamente. Quando tudo passar, ele prepara um pull request. Em vez de descrever todo esse processo

01:05 repetidamente em diferentes projetos, vamos pedir ao Kiro que transforme isso em um fluxo de trabalho reutilizável. Vamos começar. Neste vídeo, usaremos o Kiro IDE, mas os fluxos de trabalho também são compatíveis com outras interfaces, como o CLI e o Kiro web. Para gerar um fluxo de trabalho, estou usando um modelo mais avançado, com esforço de raciocínio extra alto. O Kiro permite escolher entre modelos de diferentes provedores, para que você possa adequar a inteligência do modelo à tarefa. Aqui, quero mais raciocínio desde o início, para que

01:36 o Kiro possa decidir como estruturar o fluxo de trabalho, o que deve ser executado em paralelo, quando deve tentar novamente e qual modelo e esforço de raciocínio cada etapa deve usar. Enviei este prompt, que descreve em alto nível o fluxo de trabalho que expliquei antes. E preste atenção à última parte: deixar o Kiro escolher o modelo adequado e a quantidade certa de raciocínio para cada etapa. Espero que, com um modelo inteligente e o esforço de raciocínio adequado, o Kiro perceba que verificações simples podem continuar leves, enquanto

02:06 planejamentos ou revisões mais difíceis podem usar um modelo mais avançado e mais esforço de raciocínio. O Kiro então gera o fluxo de trabalho levando em conta todos os arquivos de steering e regras de agent que você talvez já tenha configurado. Depois que o fluxo de trabalho é criado, ele aparece no painel de fluxos de trabalho, em receitas. Neste caso, criei meu fluxo de trabalho no nível do workspace, então ele fica junto com este projeto. Você também pode criar fluxos de trabalho no nível global quando quiser reutilizá-los em diferentes projetos. Você também verá que o Kiro vem com uma lista de receitas integradas no nível global, que

02:40 ajudam você a começar a usar fluxos de trabalho para padrões comuns. A partir daqui, você pode abrir seus fluxos de trabalho e revisá-los em um formato mais fácil de ler, incluindo a visão geral, as etapas individuais, o que vem primeiro, o que vem depois, o que é executado em paralelo e onde o fluxo de trabalho volta a uma etapa anterior, entre outras coisas. Se quiser alterar algo, você pode clicar em Editar. Isso abre a definição subjacente do fluxo de trabalho, onde você pode ver o JSON propriamente dito, incluindo as entradas obrigatórias, cada etapa, qual agent as executa, qual modelo e esforço de raciocínio ela usa e o prompt dessa etapa. Agora que revisamos o fluxo de trabalho, vamos

03:14 simplesmente pedir ao Kiro que execute o fluxo de trabalho e preencha as entradas obrigatórias com base no seu projeto. Agora o fluxo de trabalho está em execução. Observe que nossa sessão principal do Kiro continua disponível. Iniciar um fluxo de trabalho não bloqueia a conversa, então você pode continuar fazendo perguntas ou trabalhando com o Kiro enquanto o fluxo de trabalho é executado em segundo plano. E cada etapa do fluxo de trabalho é uma sessão de agent própria. Se eu abrir uma das etapas, posso ver exatamente o que aquele agent estava fazendo e falar diretamente com ele. Posso orientá-lo enquanto trabalha ou até voltar

03:44 depois que a etapa terminar e fazer perguntas adicionais sobre o que ele fez. Assim, os fluxos de trabalho oferecem uma orquestração estruturada sem tirar a possibilidade de interagir com agents individuais. >> Enquanto o fluxo de trabalho está em execução, vamos observar mais de perto o que cada etapa está fazendo. A primeira coisa que o Kiro faz é analisar a atualização. Esta etapa usa Claude 3.5 com esforço de raciocínio extra alto, porque envolve bastante raciocínio. O Kiro precisa entender a mudança de versão, pesquisar as orientações de migração,

04:15 encontrar alterações incompatíveis, relacionar tudo isso à base de código e descobrir como este repo deve ser testado e compilado. Em seguida, ele salva todo esse planejamento e as descobertas em um plano de atualização, que será usado pelo restante do fluxo de trabalho. Depois, o agent de programação pega esse plano e entra no ciclo de atualização. Na primeira rodada, ele atualiza as dependências e aplica todas as migrações. Em seguida, o fluxo de trabalho se divide em três verificações executadas em paralelo. Uma executa os testes, outra executa o build ou a verificação de tipos, e a terceira faz uma

04:47 revisão semântica mais aprofundada para encontrar APIs incompatíveis, dependências incompatíveis ou problemas de migração que talvez tenhamos deixado passar. As duas primeiras são bastante diretas, então usam menos esforço de raciocínio, enquanto a revisão de alterações incompatíveis exige mais discernimento. Por isso, ela recebe um modelo mais avançado e mais tempo de raciocínio. Quando as três verificações terminam, o fluxo de trabalho reúne os resultados. Uma etapa leve lê os relatórios e produz um veredito final. As três verificações precisam passar antes que o fluxo de trabalho possa avançar. E se

05:18 algo falhar, o fluxo de trabalho volta ao agent de programação com as observações, e o agent de programação as corrige; então, as mesmas verificações são executadas novamente até que tudo passe ou o limite de iterações seja alcançado. Neste fluxo de trabalho, esse limite está definido em seis tentativas. E, por sorte, neste fluxo de trabalho, chegamos à marca verde de aprovação já na primeira tentativa. Por fim, quando tudo passa, o fluxo de trabalho sai do ciclo. A etapa final envia o branch de atualização e prepara um pull request com os resumos das migrações, os resultados das validações e

05:48 tudo o que ainda possa merecer nossa atenção. Agora que executamos o fluxo de trabalho gerado pelo Kiro, talvez você esteja se perguntando, especialmente se conhece conceitos como skills ou agent MD, por que não simplesmente descrever esse processo ali? E a resposta é: sim, você pode. Você pode, sem dúvida, descrever o processo para o agent e pedir que ele o siga. Mas a diferença é que essas instruções ainda deixam parte da execução a cargo do agent. Os agents decidem como ordenar o trabalho, o que será executado em paralelo e como

06:19 as novas tentativas devem acontecer. Além disso, normalmente você executa a tarefa com um modelo e uma configuração de esforço de raciocínio para toda a interação. Mas, com um fluxo de trabalho, essas regras de execução são definidas explicitamente. Você pode especificar o que será executado em paralelo, quando voltar a uma etapa anterior, o que precisa passar antes de avançar e qual modelo e esforço de raciocínio cada etapa deve usar. Esse nível de controle garante um processo repetível sempre que você executar esse fluxo de trabalho em diferentes projetos. E, assim como skills e agent MD, um fluxo de trabalho é apenas um arquivo. Você pode mantê-lo

06:51 sob controle de versão, revisar as alterações feitas nele e compartilhar o mesmo fluxo de trabalho com o restante da sua equipe. Para recapitular, trabalhar com fluxos de trabalho no Kiro é super, super, super fácil. Tudo o que você precisa fazer é pedir ao Kiro que gere o fluxo de trabalho, depois revisá-lo e personalizá-lo e, então, executá-lo sempre que precisar. Agora você viu o que é um fluxo de trabalho, como funciona e como criar, revisar e executar um no Kiro. Desafio você a tentar criar um fluxo de trabalho em torno de um processo repetível que você já tenha hoje.

Transcrição original

[00:00] Intelligent coding agent today can handle pretty complex work. You can give Kiro a prompt or put your team’s process into a scale or agent empty file, and the agent can follow those instructions. But sometimes, you don’t just want to describe what the process should look like. You want to define exactly how it runs. That’s where workflows comes in. Let’s build a reusable workflow for dependency upgrades. Let’s say we need to upgrade dependencies across different project and want to follow the same process each time. And here is the

[00:31] workflow we’re going to build. First, we want Kiro to analyze the project that we need to upgrade and figure out what needs to change. Then, it makes the code changes. After that, three verification checks run in parallel. The first one runs the tests. The second one runs the build. And the third one reviews the changes for any breaking issues. If any of these checks fail, it goes back, fixes the issue, and runs all these checks again. Once everything passes, it prepares a pull request. Instead of describing all this process

[01:05] again and again across different projects, we will ask Kiro to turn this into a reusable workflow. Let’s get started. We will be using Kiro IDE in this video, but workflows are also supported in other interfaces, such as the CLI and Kiro web. To generate a workflow, I’m using a stronger model with extra high thinking effort. Kiro let you choose from models across different providers, so you can match the model intelligence to the task. Here, I want more reasoning up front, so

[01:36] Kiro can decide how to structure the workflow, what should run in parallel, when it should retry, and what model and thinking effort each step should use. I was sending over this prompt, which describe at a very high level the workflow I walked you through earlier. And pay attention to the last part. Um letting Kiro choose the right model and right amount of reasoning for each step. My expectation is that with an intelligent model and right reasoning effort, Kiro will realize that simple checks can stay lightweight, while

[02:06] harder planning or reviews can use a stronger model and a more thinking effort. Kiro then generate the workflow while taking into account all the steering files and agent rules you might already have in place. Once the workflow is created, it will show up in the workflows panel under recipes. In this case, I created my workflow at the workspace level, so it stays with this project. You can also create workflows at global level when you want to reuse them across project. You will also see Kiro comes with a list of built-in recipes under global, which

[02:40] get you ready to use workflows for common patterns. From here, you can open your workflows and uh review it in a more readable format, including the overview, the individual steps, what comes first, what comes next, what runs in parallel, and where the workflow loops back, things like that. If you want to change anything, you can click edit. This opens up the underlying workflow definition, where you can see the actual JSON, including the required inputs, each step, which agent runs them, which model and thinking effort it uses, and the prompt for that step. Now that we’ve reviewed the workflow, let’s

[03:14] simply ask Kiro to run the workflow and fill in the required inputs based on your project. Now the workflow is running. Notice that our main Kiro session is still available. Starting a workflow doesn’t block the conversation, so you can keep asking questions or work with Kiro while the workflow runs in the background. And each workflow step is its own agent session. If I open one of the steps, I can see exactly what that agent was doing and talk to it directly. I can steer it while it’s working or even come

[03:44] back after the step is finished and ask follow-up questions about what it did. So, workflows give you a structured orchestration without taking away the ability to interact with individual agents. >> As the workflow is running, let’s take a closer look at what each step is doing. The first thing Kiro does is to analyze the upgrade. This step uses Claude 3.5 with extra high thinking effort because there is quite a lot of reasoning involved. Kiro needs to understand the version change, research the migration

[04:15] guidance, find breaking changes, and connect all those back to the code base, and figure out how this repo should be tested and built. It then saves all that planning and findings into an upgrade plan for the rest of the workflow to consume. Next, the coding agent takes that plan and enter the upgrade loop. On the first round, it upgrades the dependencies and apply all the migrations. Then the workflow fans out into three checks that runs in parallel. One runs the tests, one runs the build or type check, and the third one does a

[04:47] deeper semantic review for breaking APIs, incompatible dependencies, or migration issues we might have missed. The first two are quite straightforward, so they use lower thinking effort, while the breaking change review needs more judgment. So, that’s why it gets a stronger model and more thinking time. When all three checks finish, the workflow brings the result back together. A lightweight step reads the reports and produce a final verdict. All three checks have to pass before the workflow can move forward. And if

[05:18] something fails, the workflow loops back to the coding agent with the observations, and the coding agent will fix them, then the same checks run again until everything passes or the iteration limit is reached. In this workflow, that limit is set to six attempts. And luckily for this workflow, we reached that green check mark on our first attempt. Finally, once everything passes, the workflow exit the loop. The final step pushes the upgrade branch and prepares a a request with the migration summaries, validation results, and

[05:48] everything that might still deserve our attention. Now that we have run the workflow Kiro generated for us, you might be wondering, especially if you are familiar with concepts such as skills or agents MD, why not just describe this process there? And the answer is, yes, you can. You can absolutely describe the process to the agent and ask it to follow. But the difference is that those instructions still leave some of execution up to the agent. The agents do decide how to order the work, what runs in parallel, and how

[06:19] retries should happen. You will also typically run the task with one model and one thinking effort setting for the whole interaction. But with a workflow, those execution rules are explicitly defined. You can specify what runs in parallel, when to loop back, what has to pass before moving on, and which model and thinking effort each step should use. This level of control ensures a repeatable process every time you run this workflow across different projects. And similar to skills and agent MD, a workflow is just a file. You can keep it

[06:51] in version control, review changes to it, and share the same workflow with the rest of your team. To recap, working with Kiro workflows is super super super easy. All you need to do is to ask Kiro to generate the workflow, then you review and customize it, then you run it whenever you need it. Now you have seen what a workflow is, how it works, and how to build, review, and run one in Kiro. I will challenge you to try and build one workflow around a repeatable process you already have today.