DEV Community: Pachi 🥑 (she/her)

What is ABMLib and where does it fit in your automation workflow?

Pachi 🥑 (she/her) — Thu, 22 Oct 2026 15:10:29 +0000

If you already use tools like n8n, Zapier, Make or Power Automate, you may be wondering:

Why would I need another platform in my automation workflow?

That is exactly the question ABMLib is trying to answer. ABMLib is not designed to replace your automation platform, it is designed to help with the steps that can happen before execution. Instead of starting every automation from scratch, ABMLib helps you discover, evaluate, test and adapt reusable automation workflows before taking them to the tools you already use.

Where does ABMLib fit?

A typical automation workflow often starts directly inside an execution platform. You open n8n, Make, Zapier or Power Automate and begin building.

ABMLib introduces an earlier step:

Discover → Evaluate → Test → Adapt → Execute

The execution still happens in the automation platform you already use. ABMLib helps you decide what to use, understand how it works and test it before you get there.

1. Discover an existing workflow

Before building something from zero, you can look for an automation that already solves a similar problem.

For example, maybe you need to:

send form submissions to a CRM, notify a team when something happens, move data between systems or automate a repetitive business process.

Instead of starting with an empty canvas, you can begin with an existing structure. In ABMLib, these reusable automation structures are called blueprints.

2. Evaluate before using

Finding a workflow is only useful if you can understand what it does. Before reusing an automation, you may want to know:

What problem does it solve?

What steps are involved?

Which tools or services does it depend on?

Can I adapt it to my context?

Can I trust it?

ABMLib is designed to make that evaluation part of the workflow instead of treating automation reuse as simple copy and paste.

3. Test before production

One of the biggest risks in automation is discovering problems only after connecting real systems, credentials or data. ABMLib includes a Sandbox environment so workflows can be tested with fixture data before being used in production.

The idea is simple:

Understand how the automation behaves before connecting it to your real environment.

Testing becomes part of the reuse process, not something that happens only after deployment.

4. Adapt instead of rebuilding

Reusable does not mean rigid. A workflow created for one context may still need different applications, conditions, steps or configurations for another.

The goal is not to find a perfect workflow that never needs changes, the goal is to avoid rebuilding the parts that do not need to be rebuilt.

5. Take it to the tool you already use

ABMLib works with automation platforms such as:

n8n, Zapier, Make and Power Automate.

The platform uses a platform-agnostic structure that can be translated into native formats for different automation tools. That means the automation logic does not have to remain tied to a single vendor or execution environment. Your execution platform still does what it does best.

ABMLib helps with what happens before that.

ABMLib is not another automation builder

The easiest way to understand the difference is this:

n8n, Zapier, Make and Power Automate help you build and execute automations.

ABMLib helps you discover, evaluate, test and reuse them. That makes ABMLib a possible first step in the automation process, especially when you suspect that the problem you are trying to solve may have already been solved before.

Don’t start from zero by default

Sometimes building from scratch is the right choice, but it should not be the automatic choice. Before creating another workflow, it may be worth asking:

Does something similar already exist, and can I safely adapt it to what I need?

That is the space ABMLib is trying to make easier to navigate.

Discover. Evaluate. Test. Adapt. Then execute.

What is workflow reuse and why does It matter?

Pachi 🥑 (she/her) — Tue, 13 Oct 2026 23:19:40 +0000

Automation is supposed to save time. But there is a common pattern in automation projects: teams repeatedly solve very similar problems from scratch.

A workflow is created for one project, a few months later someone needs something almost identical, but instead of reusing what already exists, they rebuild it.

Different client. Different tool. Different environment. Same problem.

This is where workflow reuse becomes useful.

What is workflow reuse?

Workflow reuse means using an existing automation as a starting point instead of rebuilding the entire process from zero.

That does not necessarily mean copying a workflow exactly as it is.

A reusable workflow can be:

evaluated before use;
adapted to a different context;
tested safely;
documented;
versioned;
moved between tools or environments when possible.

The important idea is simple:

You should not have to solve the same automation problem from scratch every time.

Templates and reusable workflows are not exactly the same thing

Automation platforms already offer templates.

They are useful, but a template alone does not answer every question a developer or team may have.

Before reusing something, you may want to know:

What problem was this workflow designed to solve?
How does it work?
Can I modify it?
Can I trust it?
Can I test it before connecting production systems?
Can I use the same structure with a different automation tool?

Reuse becomes more valuable when the workflow is not just something you can copy, but something you can understand, evaluate and adapt.

Why does workflow reuse matter?

1. Less duplicated work

If a solution already exists, rebuilding it from scratch may not be the best use of engineering time.

Starting from an existing structure allows teams to focus on what is actually different about their use case.

2. Faster experimentation

Reusable workflows make it easier to explore an idea without designing every step before you know whether the approach works.

You can start with something existing, test it and then decide what needs to change.

3. Better knowledge sharing

Automation knowledge often stays with the person who created the workflow.

Reusable and documented workflows make that knowledge easier to share across a team, project or community.

4. More confidence before production

Reuse should not mean blindly trusting someone else's automation.

A useful reuse process should make it possible to inspect, understand and test a workflow before connecting it to real systems and data.

5. More flexibility across tools

Teams do not always work with a single automation platform.

One project may use n8n. Another may use Make, Zapier, Power Automate or a custom stack.

Thinking about the workflow independently from the execution tool can make automation knowledge easier to reuse across different contexts.

Where does ABMLib fit?

ABMLib is exploring a simple idea:

What if you could look for an existing automation before starting from scratch?

The goal is to help people and teams:

Discover → Evaluate → Test → Adapt → Execute

Instead of being another execution platform, ABMLib is designed to help with the steps that can happen before execution.

You can find an automation that solves a similar problem, understand its structure, test it, adapt it to your context and then take it to the tools you already use.

In ABMLib, these reusable automation structures are called blueprints.

Don’t start from scratch

Not every workflow should be reusable.

And not every existing automation will fit a new context.

But before building the same thing again, it is worth asking:

Has someone already solved something similar?

That question is at the center of workflow reuse.

And it is also one of the questions ABMLib is trying to make easier to answer.

Explore reusable automation blueprints in ABMLib and see what you can adapt to your next workflow.

Agente local ou agente na nuvem: qual faz sentido para você?

Pachi 🥑 (she/her) — Mon, 08 Jun 2026 13:02:51 +0000

Você pediu para a IA mexer no seu projeto. Ela leu arquivos, sugeriu mudanças, alterou código e disse que resolveu o problema.
Aí vem a pergunta que muita gente pula:

onde essa IA estava rodando enquanto fazia tudo isso?

Eu não tinha parado para pensar nisso até esses dias. Mas, estudando o tema, descobri que essa diferença importa.
Um agente local trabalha na sua máquina, perto do seu ambiente real de desenvolvimento. Já um agente na nuvem trabalha fora dela, geralmente em um ambiente isolado.
Os dois podem ajudar bastante, mas eles não têm os mesmos riscos, os mesmos limites nem o mesmo tipo de contexto.

O que é um agente de IA para programação?

Antes de falar sobre local e nuvem, vale alinhar o que estamos chamando de agente.

Quando muita gente pensa em IA para programação, ainda imagina apenas um chat respondendo perguntas ou uma ferramenta que completa código enquanto você digita, e isso continua existindo, claro. Mas os agentes vão um pouco além.

Um agente de IA para programação pode analisar arquivos, entender partes de um projeto, propor mudanças, editar código, rodar comandos, criar testes e, dependendo da ferramenta, até abrir uma proposta de alteração para revisão.

A diferença é que ele não está apenas respondendo “como eu faria isso?”. Ele pode, de fato, executar parte do trabalho.
E é justamente por isso que entender onde esse agente roda começa a importar.

Quando a IA só responde uma pergunta conceitual, o risco é menor. Mas quando ela lê seu projeto, altera arquivos e executa comandos, você precisa entender melhor o ambiente em que isso está acontecendo.

O que é um agente local?

Um agente local é aquele que roda na sua própria máquina.
Na prática, ele trabalha perto do seu ambiente real de desenvolvimento. Ele pode acessar os arquivos do projeto, navegar pela estrutura de pastas, ler dependências, executar comandos no terminal, rodar testes e modificar arquivos.

É como se você chamasse a IA para sentar ao seu lado enquanto você programa, com acesso ao mesmo projeto que você está vendo.
Esse tipo de agente costuma ser útil quando a tarefa depende muito do contexto local. Por exemplo, quando você quer investigar um bug, entender por que um teste está falhando, refatorar vários arquivos relacionados ou validar se uma mudança realmente funciona no seu ambiente.

A principal vantagem é essa proximidade com o projeto real.

Em vez de analisar um trecho solto de código, o agente local consegue olhar para o conjunto. Ele pode perceber que uma função é chamada em outro arquivo, que existe um padrão de testes no projeto, que determinado comando está no package.json ou que uma alteração precisa respeitar uma estrutura já existente.
Isso torna o trabalho mais contextual, mas também torna o cuidado mais necessário.

Um agente local pode mexer em arquivos importantes. Pode executar comandos. Pode instalar dependências. Pode fazer alterações que parecem boas no primeiro momento, mas quebram algo em outra parte do sistema.
Por isso, agente local não deve ser tratado como botão mágico de “resolver projeto” (talvez eu já tenha feito isso algumas vezes hehe >.<).

Ele é um colaborador rápido e um colaborador rápido também erra rápido.

O que é um agente na nuvem?

Um agente na nuvem roda fora da sua máquina.
Ele geralmente trabalha em um ambiente externo, como um container, uma sandbox ou uma infraestrutura controlada pela ferramenta que você está usando. Em vez de executar tudo diretamente no seu computador, ele recebe uma tarefa e trabalha nesse ambiente remoto.

Esse modelo aparece em ferramentas que conseguem receber uma issue, uma descrição de tarefa ou uma solicitação de mudança e gerar uma proposta de solução. Em alguns casos, o agente pode criar um pull request para você revisar depois.

A vantagem é a praticidade.

Você pode delegar uma tarefa bem definida sem precisar ocupar sua máquina. Também pode ser útil para trabalhar em paralelo, testar pequenas mudanças, gerar propostas iniciais ou lidar com tarefas mais isoladas.

Imagine uma issue simples: ajustar uma mensagem de erro, adicionar uma validação, atualizar uma documentação ou criar testes para um comportamento já existente. Um agente na nuvem pode ser uma boa opção para esse tipo de trabalho, desde que a tarefa esteja bem explicada.

Mas a nuvem também exige cuidado: Quando o agente roda fora da sua máquina, você precisa pensar em quais informações ele pode acessar. Código privado, dados sensíveis, credenciais, variáveis de ambiente e detalhes internos de negócio precisam ser tratados com atenção.

Também existe uma diferença importante de controle, em um agente local, você está mais perto do processo enquanto em um agente na nuvem, muitas vezes você acompanha o resultado depois que ele já executou boa parte da tarefa. Isso não é necessariamente ruim, mas muda a forma como você revisa.

A diferença não é só onde roda

A diferença entre agente local e agente na nuvem parece, à primeira vista, uma questão de infraestrutura. Mas ela é mais do que isso.

A diferença está no tipo de contexto que o agente consegue acessar, no nível de controle que você tem durante a execução e nos riscos envolvidos.

Um agente local tende a ter mais contato com o ambiente real do projeto. Ele consegue rodar os mesmos comandos que você rodaria, acessar os mesmos arquivos e validar mudanças no mesmo contexto em que você trabalha. Isso pode ser muito poderoso para tarefas de investigação, debugging e refatoração.

Já um agente na nuvem tende a funcionar melhor quando a tarefa está bem delimitada. Ele não precisa necessariamente entender todos os detalhes do seu ambiente local se a tarefa for clara, pequena e validável depois.

O problema começa quando a gente usa uma ferramenta como se ela fosse a outra.

Pedir para um agente na nuvem resolver uma tarefa vaga em uma base de código complexa pode gerar uma solução desalinhada. Ao mesmo tempo, deixar um agente local executar mudanças grandes sem supervisão pode virar bagunça em alta velocidade.

A pergunta não é “qual é melhor?” e sim qual faz mais sentido para o tipo de tarefa que você quer resolver agora?

Quando faz sentido usar um agente local?

Um agente local costuma fazer mais sentido quando você precisa de proximidade com o projeto.

Se a tarefa envolve rodar testes, reproduzir bugs, navegar por vários arquivos, entender dependências locais ou executar comandos específicos, o agente local tende a ser uma boa escolha.

Ele também é útil quando você quer acompanhar o processo mais de perto. Você pode pedir para ele primeiro analisar o problema, explicar o plano e só depois alterar arquivos. Esse tipo de cuidado faz diferença.

Uma boa prática é começar com uma instrução como:

“Antes de modificar qualquer arquivo, analise o problema e me diga o que você pretende alterar.”

Isso muda bastante a dinâmica.

Em vez de simplesmente deixar a IA sair editando, você força uma etapa de planejamento. Você continua no controle e consegue avaliar se o caminho proposto faz sentido.

Também vale usar controle de versão com disciplina. Antes de pedir mudanças maiores para um agente local, tenha certeza de que seu projeto está versionado e que você consegue desfazer alterações com segurança.

Parece básico, mas é o tipo de básico que salva vidas (ou pelo menos salva tardes inteiras de retrabalho.

Quando faz sentido usar um agente na nuvem?

Um agente na nuvem costuma funcionar melhor quando a tarefa é bem definida.

Quanto mais clara for a descrição, melhor. Ele precisa saber o que mudar, onde mexer, quais comportamentos preservar e como o resultado será validado.

Por isso, agentes na nuvem combinam muito bem com issues bem escritas, bugs pequenos, tarefas de documentação, criação de testes e melhorias com escopo controlado.

A nuvem também pode ajudar quando você quer paralelizar trabalho, enquanto você continua focada em uma parte mais estratégica ou complexa, o agente pode preparar uma proposta inicial para algo mais delimitado.

Mas aqui existe uma regra importante: pull request gerado por IA não é pra ser visto como entrega pronta e sim como proposta. Você ainda precisa revisar o código, entender a mudança, rodar testes quando necessário e avaliar se aquilo realmente resolve o problema sem criar outro.

A IA pode acelerar a abertura de uma solução, mas não elimina o julgamento técnico.

O risco da confiança automática

Um dos maiores perigos ao usar agentes de IA é confundir velocidade com qualidade. Quando uma ferramenta altera arquivos, escreve explicações convincentes e diz que resolveu o problema, dá vontade de acreditar. Afinal, parece organizado. Parece técnico. Parece certo. Mas parecer certo não é a mesma coisa que estar certo.

Agentes podem criar código que passa em alguns testes, mas falha em casos importantes. Podem usar APIs inexistentes, podem ignorar padrões do projeto, podem resolver o sintoma e não a causa, podem introduzir uma falha de segurança sem que isso fique óbvio na primeira leitura.

Esse cuidado vale tanto para agentes locais quanto para agentes na nuvem. A diferença é que os riscos aparecem de formas diferentes.

No agente local, o risco está muito ligado ao poder de mexer diretamente no seu ambiente. No agente na nuvem, o risco está mais ligado ao acesso a informações, à distância do ambiente real e à tentação de aceitar uma proposta sem revisar direito.

Nos dois casos, a pessoa desenvolvedora continua sendo responsável pela decisão final.

O que muda no papel de quem programa?

Usar agentes de IA muda um pouco o nosso papel no processo de desenvolvimento. A gente não deixa de programar. Mas passa a programar também por meio de instruções, contexto, revisão e validação.

Isso exige outras habilidades.

Você precisa saber explicar bem o problema, precisa decompor tarefas grandes em partes menores, precisa dar contexto suficiente, precisa revisar o que foi gerado, precisa identificar quando a IA está ajudando e quando está só produzindo uma solução bonita, mas errada. Enfim, ainda tem bastante trabalho pra gente.

Pachi Parra

A Practical Intro to Spec-Driven Development (SDD)

Pachi 🥑 (she/her) — Mon, 08 Jun 2026 12:46:13 +0000

When we build something complex—whether it’s a skyscraper, a gourmet meal, or a piece of software—we usually start with a plan. In software development, however, it’s easy to skip that step. We often jump straight into implementation, focusing on how to write the code instead of the intent behind it. Over time, this leads to rework, confusion, and systems that don't quite match our original goals.

Spec-Driven Development (SDD) is an approach that shifts the focus back to the plan. Instead of starting with code, you start with a Specification: a clear, structured description of what the software should do. You then use an AI coding agent as a high-speed collaborator to help turn that specification into working code.

🔍 What is a “Spec”?

A Specification (or “Spec”) is a written contract between your intention and the final product. It isn't a 50-page manual; it's a living document that defines:

What the system should do.
How it should behave in different scenarios.
Which constraints and rules it must follow.

From Prompts to Specifications

There is a massive difference between a vague prompt and a structured spec. Loose prompts often lead to inconsistent results and "hallucinations," whereas clear specifications give the AI a much better target to hit.

Bad Prompt: > “Build me a login system.”

Good Spec:
A good spec provides the clarity an AI (or a human) needs to succeed. You don’t need a 10-page document to benefit from specs; you need clarity, not length.

🛠️ Example Spec: Login Endpoint

Overview

Allow users to log in using email and password.

Endpoint

POST /api/login

Request

{
  "email": "user@example.com",
  "password": "string"
}

Behavior

Success: If email and password are correct → return a token and user info.
Invalid Credentials: If credentials don't match → return INVALID_CREDENTIALS.
Invalid Input: If fields are empty or the email format is wrong → return INVALID_INPUT.

Rules

Passwords must be stored hashed (e.g., bcrypt).
Token expires in 24 hours.
Security: Do not reveal whether it was the email or the password that was incorrect.

Edge Case

Rate Limiting: After 5 failed attempts → lock the account for 15 minutes.

💡 The Three Practical Benefits of SDD

Based on frameworks developed by industry leaders like JetBrains and DeepLearning.AI, there are three major reasons to adopt this approach:

1. Centralizing Change

In traditional projects, changing a feature means hunting through multiple files. In SDD, you update the spec first. The coding agent then adjusts the implementation to match. This allows you to control code with small changes to the spec.

2. Reducing Context Loss

Projects often suffer from "spaghetti code" because original decisions weren't documented. A well-maintained spec eliminates context decay by acting as the permanent memory of why a feature exists.

3. Improving Intent Fidelity

One of the biggest challenges with AI is misinterpretation. A structured spec improves intent fidelity, ensuring the output matches what you actually meant. You aren't just giving instructions; you are defining expectations.

🏗️ Architect vs. Builder: A Reality Check

SDD is often described as a shift in roles: you move from being the Builder (writing every line of code) to the Architect (defining the system). While this framing helps, it’s important to remember that the AI is not a perfect builder; it is a fast collaborator that still needs guidance.

As the architect, you are still responsible for:

Validating behavior and reviewing generated code.
Handling complex architectural edge cases.
Ensuring the spec stays up-to-date as requirements evolve.

🚀 Where SDD Works Best (and Where It Struggles)

Use it for:

Prototyping: Rapidly iterating when requirements are clearly defined.
Technical Education: Helping developers understand logic before syntax.
Onboarding: Reducing reliance on "tribal knowledge" through shared documentation.

Be careful when:

Vague Requirements: A bad spec leads to bad code, just faster.
High Complexity: In heavily coupled legacy systems, agents may struggle to navigate the codebase even with a good spec.

🎓 Ready to Learn More?

If you want to dive deeper into this methodology and see how to apply it with real tools, I highly recommend the free short course: Spec-Driven Development with Coding Agents.

Created by JetBrains in partnership with DeepLearning.AI, this course provides practical insights into how to guide AI agents using structured specifications to build more robust and maintainable software.

Final Thoughts

Spec-Driven Development isn’t about replacing coding; it’s about making your intent explicit. The clearer your thinking, the better your software. By investing time in the "Spec," you aren't just building faster—you're building smarter.

O Paradoxo dos 70/30: A aceleração da IA aliada à experiência humana

Pachi 🥑 (she/her) — Tue, 02 Jun 2026 15:55:18 +0000

Tenho aproveitado meu tempo sem trabalhar pra estudar, enfim a vida de quem trabalha com tecnologia né? E um dos meus maiores focos tem sido IA, seus usos, como ela entra e pode ser aplicada em áreas diferentes, e todas as novidades que saem todos os dias. Hoje vim compartilhar uma coisa bem legal que aprendi no curso AI-Native Engineering Foundations do Addy Osmani, o problema dos 70%.

Existe um padrão claro que tenho observado na prática ao acompanhar dezenas de equipes de engenharia: a Inteligência Artificial resolve com impressionante eficiência 70% de quase qualquer tarefa técnica.

Falo daquela camada previsível, repetitiva e baseada em padrões exaustivamente documentados na internet. Coisas como código boilerplate, arquivos de configuração, implementações de CRUDs simples, conversão de sintaxe entre linguagens e a escrita de testes unitários básicos. A IA já "viu" milhões de exemplos disso em repositórios públicos e consegue reproduzir o padrão em segundos. Para essa fatia do trabalho, ela é uma aceleradora fantástica.

O grande problema, e o motivo pelo qual muitos projetos com IA começam bem mas falham no meio, é que os outros 30% são justamente os que sustentam o software.

É nesses 30% que entram as decisões que inteligência nenhuma consegue tomar sozinha:

Contexto de Negócio: A IA não sabe por que aquela feature está sendo construída ou como ela impacta o usuário final.
Arquitetura e Manutenibilidade: Escrever código que funciona hoje é fácil; escrever código que outra pessoa consegue alterar daqui a seis meses sem quebrar o sistema é outra história.
Casos de Borda e Segurança: A IA tende a gerar o "caminho feliz". Tratar falhas de concorrência, vazamento de memória e vulnerabilidades específicas do seu ecossistema exige malícia técnica.

Essas questões não se resolvem apenas digitando linhas de código, elas exigem contexto, experiência, histórico de dores passadas e, acima de tudo, julgamento humano. E é exatamente aqui que a IA ainda não entrega.

O Paradoxo da Experiência: IA ajuda mais quem menos precisa dela

Dessa dinâmica dos 70/30 nasce um paradoxo importante no mercado atual: a IA entrega mais valor para quem já tem experiência.

Uma pessoa desenvolvedora experiente usa a ferramenta com um olhar altamente crítico, ela atua como um editor ou um revisor rigoroso: olha o código gerado, identifica um padrão de arquitetura ruim, uma vulnerabilidade de segurança e sabe exatamente como guiar o prompt para corrigir a rota. Para ela, a IA é um ganho enorme de produtividade porque ela domina os 30%.

Por outro lado, quem está começando na carreira corre um risco enorme. Diante de uma tela que cospe código pronto e aparentemente funcional em segundos, a tendência natural de quem tem menos experiência é aceitar a resposta "porque ela parece certa" e o código "rodou".

O resultado disso no médio prazo é a criação de sistemas frágeis, construídos sobre uma base de código que o próprio autor não entende totalmente. Além disso, cria-se uma falsa sensação de proficiência: o profissional acelera a entrega, mas estagna o aprendizado.

O código é commodity. O diferencial mudou de lugar.

Se a IA consegue automatizar a parte mecânica da escrita de código, a necessidade de aprender os fundamentos da computação e da engenharia de software não diminuiu , ela se tornou ainda mais crucial.

Se você não sabe como a memória funciona, como os dados trafegam na rede ou como os padrões de projeto se aplicam, você se torna refém da ferramenta. Você não manda no desenvolvimento; você apenas aceita sugestões.

Para não cair nessa armadilha, o segredo está em mudar a forma como interagimos com a tecnologia no dia a dia. Uma recomendação prática que sempre faço é a seguinte:
O resultado disso no médio prazo é a criação de sistemas frágeis, construídos sobre uma base de código que o próprio autor não entende totalmente. Além disso, cria-se uma falsa sensação de proficiência: o profissional acelera a entrega, mas estagna o aprendizado.

O código é commodity. O diferencial mudou de lugar.

Para não cair nessa armadilha, o segredo está em mudar a forma como interagimos com a tecnologia no dia a dia. Uma recomendação prática que sempre faço é a seguinte:

Sempre que a IA gerar um trecho de código para você, faça a si mesmo
uma pergunta: “Se eu fosse chamado para revisar esse código em uma
Code Review eu conseguiria explicar cada linha e justificar essa
escolha de design?”

Se a resposta for sim: Use a IA como sua copilota e aproveite a velocidade.
Se a resposta for não: Pare. Não dê merge. Use esse exato momento para estudar o que foi gerado, entender o porquê daquela solução e pesquisar os fundamentos por trás dela antes de confiar cegamente.

A IA pode ser a maior ferramenta de aprendizado que já tivemos, desde que você assuma o papel de estudante ativo, e não de mero copiador de prompts.

Redirecionando o tempo ganho

No fim das contas, a automação dos 70% padronizados do nosso trabalho é uma excelente notícia, ela nos livra do trabalho puramente "braçal" e repetitivo que consumia horas do nosso dia. O erro está em achar que o trabalho acaba quando esses 70% são entregues.

O verdadeiro diferencial humano, o que define uma pessoa engenheira de software de alto nível, mora justamente na nossa capacidade de navegar pelos 30% complexos. Use o tempo que a IA te deu de presente na base do código para pensar melhor na arquitetura, na segurança, na experiência do usuário e no impacto real do que você está construindo.

Pachi Parra

3 Competências essenciais para programar com IA em 2026

Pachi 🥑 (she/her) — Mon, 08 Dec 2025 14:36:27 +0000

A gente sempre fala sobre como a tecnologia e as linguagens de programação estão sempre mudando né? Mas dessa vez estamos vivendo uma virada histórica, e é obvio que eu estou falando dela mesma, a IA!.

Nos próximos anos, IAs vão gerar grande parte do código chato e repetitivo (95% nos próximos 5 anos segundo o GitHub). Parece assustador? Só à primeira vista. Na prática, isso abre espaço para um tipo de trabalho muito mais estratégico e interessante.

Máquinas são velozes e impecáveis na sintaxe, mas continuam péssimas em criatividade, contexto e visão sistêmica. E é exatamente aí que você pode brilhar. ✨

Estamos migrando de um modelo baseado em digitar código para um modelo centrado em orquestrar soluções. Não importa quantas linhas você escreve em um dia. Importa se você entende o problema, desenha boas arquiteturas e sabe guiar as ferramentas de IA como uma regente experiente (artístico né? haha).

Para chegar lá, vou deixar aqui três habilidades vão te colocar na frente agora, não só no futuro (até porque né, quem sabe do futuro?).

Habilidade 1: Domine a engenharia de prompt (contexto!)

IA não lê mentes. Ainda bem, né? Mas isso significa que, se você der contexto pela metade, vai receber código genérico ou alucinado, então mais importante do que pedir, é como você pede.

Ferramentas como GitHub Copilot Spaces vieram justamente para resolver esse problema. Em vez de tratar cada pergunta como se fosse a primeira vez, você cria ambientes onde a IA entende seu projeto, seu estilo e suas regras.

Como aplicar hoje:

Crie espaços de contexto dedicados para cada projeto.
Alimente a IA com tudo que importa: documentação, arquivos reais, padrões internos.
Peça com precisão. Não é “crie uma query SQL”, é “crie uma query SQL usando o esquema que anexei, filtrando usuários ativos”.
Compartilhe esse contexto com sua equipe. Ensinar a IA não precisa ser um trabalho solitário.

Habilidade 2: Exercite o julgamento crítico

Já que a IA consegue gerar sintaxe com facilidade, o que mais importa agora é a sua capacidade de avaliar, rejeitar, adaptar e alinhar as soluções.

A IA pode revisar seu PR e apontar problemas óbvios, mas a decisão final é sua, você é a pessoa que conhece a arquitetura, o cliente, a realidade da equipe e o futuro do produto.

Como fortalecer esse olhar:

Use IA como par de revisão antes de envolver humanos.
Questione sempre. A IA sugere padrões, mas raramente entende as exceções que quebram tudo amanhã.
Personalize regras no projeto. Um simples arquivo copilot-instructions.md pode transformar a qualidade das sugestões.

Habilidade 3: Aprenda para Sempre

A vida útil das skills técnicas encurtou. Hoje você domina um framework; amanhã ele vira um meme. No mundo assistido por IA, o conhecimento estático vale menos do que a capacidade de aprender rápido.

Para se manter relevante:

Reforce fundamentos de IA. Se ainda não domina Python, comece daí (Autocrítica: Pachi de 2026, aprenda Python). Entenda o básico de frameworks de ML e o que rola por trás dos modelos que você usa.
Aprenda NLP e princípios de LLMs. Quanto mais você entende, melhores ficam seus prompts.
Crie prova social. Contribua em open source, escreva, mostre seu processo. Aprender em público te destaca.
Tire certificações em ferramentas de IA. Não pelos diplomas, mas pelo pra mostrar que você está se atualizando de verdade.

O futuro é promissor para quem se move agora

Inspirador esse subtitulo né? Até parece que foi o GPT que escreveu haha Mas fui eu, eu sou inspiradora.

Programação assistida por IA não elimina o humano (ainda rs) mas aumenta a importância de quem pensa bem, sabe se comunicar e enxerga o todo. O mercado vai continuar mudando rápido, mas quem combina IA com criatividade, contexto e aprendizado contínuo acompanha e se mantém relevante.

O código continua importante, mas a sua visão estratégica vale muito mais do que qualquer linha escrita às pressas por uma máquina.

Quer dar o próximo passo?

Se você quer realmente se preparar para esse novo cenário da programação, tem uma oportunidade perfeita rolando agora: o Bootcamp GitHub Copilot - Código na Prática, da DIO em parceria com o GitHub. É gratuito, já está com inscrições abertas.

É a chance de aprender, na prática, como desenvolver com IA ao seu lado: criar APIs, refatorar código com segurança, gerar testes automatizados e construir projetos reais que aumentam sua produtividade de verdade.

Bora garantir sua vaga enquanto ainda tem?

🚀 Novidades GitHub Universe 2025

Pachi 🥑 (she/her) — Fri, 07 Nov 2025 17:37:48 +0000

O GitHub Universe é a conferência global anual onde o GitHub anuncia as principais inovações e as ferramentas moldarão o futuro do desenvolvimento de software. A edição de 2025 marcou uma transição definitiva para a era da inteligência artificial, com um foco claro na experiência das pessoas desenvolvedoras e na capacitação das equipes.

Com a missão de "Explorar as mais recentes ferramentas do GitHub que moldam o software agente e a escolha das pessoas desenvolvedoras", a conferência estabeleceu um novo marco, anunciando desde um centro de controle unificado para agentes até integrações profundas no fluxo de trabalho.

E no post de hoje, vi trazer as novidades mais importantes anunciadas no evento:

🤖 A Nova Era dos Agentes: Apresentando o Agent HQ

(Novidades em Breve)

O anúncio mais impactante é o Agent HQ, que promete ser um centro de comando unificado para orquestrar qualquer agente de código, de qualquer lugar. Esta nova evolução trará recursos cruciais para a gestão de tarefas complexas:

Introdução ao Agent HQ- Leia o Blog
Centro de Controle e Missões: Uma visão unificada para atribuir, guiar, rastrear e revisar tarefas complexas executadas por agentes em todo o ecossistema GitHub.Leia o Changelog
Agentes Customizados: Capacidade de personalizar agentes com prompts, ferramentas e contextos específicos para tarefas de desenvolvimento e compartilhamento entre equipes. Leia o Changelog

🌐 Fluxos de Trabalho Inteligentes com Copilot Integrado

(Disponível Agora)

O GitHub Copilot está se expandindo para se tornar um assistente de fluxo de trabalho ainda mais integrado.

Conecte o Copilot ao seu Fluxo de Trabalho - Explore o Copilot
Copilot Designável: Agora é possível atribuir tarefas ao Copilot diretamente em ferramentas populares de gerenciamento, como Slack, Microsoft Teams, Linear e Azure Boards.
Explore as Integrações do Copilot
Revisão de Código Agente: O Copilot aprimora suas revisões de código combinando a inteligência do modelo com a ferramenta CodeQL. Leia o Changelog

💻 Experiência de Código Aprimorada no VS Code

_
(Disponível Agora)_

O Visual Studio Code, ambiente de desenvolvimento essencial, recebe atualizações focadas em planejamento e conformidade.

Modo de Planejamento (Plan Mode): As pessoas desenvolvedoras podem usar o Plan Mode para criar um plano passo a passo antes de escrever o código. Leia o Changelog
Seus Agentes, Suas Regras: Defina diretrizes de projeto no arquivo AGENTS.md para que cada agente siga os padrões da equipe. Leia a Documentação
Integração MCP Simplificada: Acesse e instale servidores MCP (Model Control Plane) diretamente do GitHub MCP Registry dentro do VS Code. Explore o Suporte ao MCP

💼 Governança e Visibilidade para Empresas

(Disponível Agora)

Para o ambiente Enterprise, o foco é em governança, segurança e métricas de adoção de IA.

GitHub Code Quality: Oferece visibilidade e relatórios em toda a organização para melhorar a qualidade do código. Leia o Changelog
Painel de Métricas do Copilot: Dashboard e API com um quadro completo de uso do Copilot, incluindo métricas de usuários ativos e adoção. Leia o Changelog
Governança de Fluxos de Agentes: Permite que as empresas centralizem o gerenciamento de agentes, definam políticas de segurança e configurem acessos. Leia o Changelog

📊 O Estado do Octoverse em 2025

(Disponível Agora)

O relatório anual do Octoverse também foi lançado, revelando as principais tendências da comunidade.

Relatório Octoverse - Leia o Relatório Completo

Em resumo...

O GitHub Universe 2025 não apenas apresentou ferramentas; ele delineou o mapa para o futuro do desenvolvimento.
Com o Agent HQ e a expansão do Copilot, o GitHub está garantindo que as pessoas desenvolvedoras mantenham o controle, a visibilidade e a capacidade de escolha, mesmo enquanto a IA assume tarefas mais complexas.
Essas inovações solidificam a visão do GitHub: transformar desafios em soluções automatizadas e permitir que as pessoas desenvolvedoras se concentrem no que fazem de melhor: inovar e criar.

Explore os links acima para mergulhar na nova era do desenvolvimento agente! ✨

Oi :3

Pachi 🥑 (she/her) — Thu, 30 Oct 2025 21:08:54 +0000

O Que É DevRel? Entenda Developer Relations no Brasil

Pachi 🥑 (she/her) — Wed, 01 Oct 2025 20:54:00 +0000

Olá, pessoas! Eu sou a Pachi Parra, e como Developer Advocate no GitHub, mergulho diariamente no universo de Developer Relations (DevRel). Essa área é uma paixão para mim, e percebo o quanto falta conteúdo em português sobre ela. É por isso que estou aqui, começando essa série do Abacate DevRel, para preencher esse vazio e compartilhar minha experiência (de startups a empresas grandes como o GitHub!).

Este artigo é baseado no nosso primeiro vídeo, onde vamos desvendar: o que é DevRel? E por que essa área é tão importante? Vamos lá!

1. DevRel: A Ponte de Mão Dupla entre Empresa e Comunidade Dev

O termo DevRel vem do inglês "Developer Relations", que em português se traduz como "Relações com Pessoas Desenvolvedoras". Basicamente, DevRel é a ponte que une a empresa e a comunidade de desenvolvedores.

Mas atenção: essa ponte é de mão dupla! Isso significa que o profissional de DevRel não apenas leva a empresa, seus produtos e tecnologias para a comunidade, mas também traz o feedback, as dores e as necessidades da comunidade de volta para a empresa. Nossa função é ser essa interface neutra, representando ambos os lados para garantir uma comunicação eficaz e aprimoramento contínuo.

2. Por Que DevRel é Importante? Benefícios para Empresas e Devs

DevRel não é apenas um "extra"; é uma área crucial com benefícios tangíveis tanto para as empresas quanto para a própria comunidade de desenvolvedores.

2.1. Para as Empresas de Tecnologia:

Existem vários motivos pelos quais as empresas precisam de DevRel. Selecionei alguns:

Adoção e Feedback (Melhoria do Produto): Um dos pilares do DevRel é garantir a adoção do produto ou tecnologia pela comunidade tech. Para isso, estamos sempre focados em coletar o feedback. Não se trata apenas de seguir um roadmap pré-definido, mas de ouvir quem realmente usa o produto. A gente avalia esse feedback para ver se faz sentido e como podemos melhorar. Isso garante que o produto evolua escutando o usuário final, o que é fundamental para a sua aceitação no mercado.
Comunidade e Confiança (Lealdade à Marca): Construir uma comunidade engajada ao redor do produto ou da marca é importante. Pessoas que usam o nosso produto, que estão abertas a dar feedback, geram confiança e lealdade. Essa confiança se estende à marca empregadora. A comunidade Dev é bem unida e se conversa. Se a sua marca é conhecida por se importar com as pessoas desenvolvedoras, por ter um produto de qualidade e por ouvir o feedback, ela vai ter uma boa reputação com a comunidade.
Atração de Talentos: Pessoas Desenvolvedoras querem trabalhar em lugares onde se sentem valorizadas e entendidas, uma reputação positiva construída pelo DevRel atrai os melhores talentos para a empresa.

2.2. Para a Comunidade Dev

E para quem está na comunidade dev, por que o DevRel importa?

Suporte e Recursos Acessíveis: Uma empresa com um time de DevRel não oferece apenas documentação. Oferecemos vídeos educacionais, fazemos lives, compartilhamos cases de uso e criamos exemplos de código. Isso significa mais suporte e recursos para você aprender e usar a tecnologia.
Voz Ativa e Influência no Produto: O feedback que a comunidade dá não é ignorado. Seja sobre bugs, novas funcionalidades ou melhorias, o DevRel garante que essa voz chegue à empresa e seja considerada no desenvolvimento do produto. Você consegue influenciar diretamente no que está sendo criado.
Networking e Aprendizado Contínuo: Muitas empresas com foco em DevRel criam conteúdo educacional de alta qualidade e organizam eventos (online e presenciais). Isso contribui diretamente para o seu crescimento pessoal e profissional como pessoa desenvolvedora.

3. DevRel NÃO é Marketing: Entenda a Diferença Fundamental

Essa é uma confusão comum, mas importante de esclarecer: DevRel não é marketing.

Trabalhamos muito com marketing, produto e engenharia, mas nossa essência é diferente.

Foco em Relacionamento e Valor (Não Venda Direta): Enquanto o marketing tradicional geralmente tem um foco de venda (trazer pessoas para um funil para converter em clientes), o DevRel foca em construir relacionamento e entregar valor. Meu trabalho é te educar, te ajudar a ver o valor do meu produto. Se, no fim, meu produto não for o ideal para você, tudo bem. Minha obrigação é ser essa ponte de conhecimento e apoio.
Credibilidade e Autenticidade (Não Apenas Promoção): Não fazemos promoção cega. Claro que, trabalhando no GitHub, eu produzo artigos sobre o uso do GitHub. Mas o objetivo principal é que você aprenda a usar a ferramenta, não apenas promovê-la. E, se minha ferramenta não for a melhor para a sua necessidade específica, minha obrigação é ser honesta e, talvez, até sugerir uma alternativa. Minha responsabilidade é representar a comunidade e seus interesses.

4. O Cenário DevRel no Brasil: Potencial e Realidade Atual

DevRel é muito mais conhecido fora do Brasil, mas a área está se desenvolvendo por aqui. Tenho trabalhado com DevRel no Brasil há três anos e vejo um crescimento constante, mas gradual. Principalmente neste ano, notei algumas novas vagas surgindo.

No Brasil, percebo um foco maior em DevRel interno. Isso significa que muitas empresas estão priorizando otimizar a experiência do desenvolvedor que já está dentro da própria organização.

Apesar do crescimento ser mais lento e com um foco específico, o DevRel no Brasil tem muito potencial que ainda não está sendo explorado. Há um vasto campo para empresas que desejam investir nessa área de conexão e engajamento com a comunidade dev.

Sua Jornada em DevRel Começa Aqui!

Espero que este artigo tenha te dado uma visão clara e objetiva sobre o que é DevRel e a sua importância. Essa é apenas a primeira etapa de uma jornada de aprendizado que vamos fazer juntos aqui no Abacate DevRel.

O Valor de uma Comunidade: Seis pilares tangíveis para o crescimento da sua empresa

Pachi 🥑 (she/her) — Wed, 01 Oct 2025 20:52:33 +0000

Olá!
Sei que, como líder de negócios, você está constantemente buscando maneiras de fazer a sua empresa crescer, otimizar custos e encantar clientes. Eu também! E, sabe, ao longo da minha carreira, percebi que muitas empresas investem rios de dinheiro para atrair novos clientes, mas acabam esquecendo de um tesouro que já está ali: aquelas pessoas que já escolheram a sua marca.

O que aconteceria se a gente desse a elas um espaço para se conectar, aprender e até mesmo defender o seu negócio? Acredite, o potencial é imenso! Não estou falando de mais uma ferramenta ou de uma estratégia mirabolante. Estou falando de comunidade. E, neste artigo, quero te convidar a ir além do que o mercado dita e desvendar o valor inestimável de uma comunidade bem estruturada, mostrando como ela não é apenas um "extra", mas um pilar fundamental para os resultados do seu negócio.

1. Otimização de custos com suporte e atendimento

Imagine suas próprias clientes e clientes auxiliando uns aos outros, resolvendo dúvidas e compartilhando soluções. Isso não é ficção, é a realidade de uma comunidade ativa. Este é, talvez, o benefício mais direto e, paradoxalmente, um dos mais subestimados. Ao empoderar suas clientes e clientes, a sua empresa se beneficia de um poderoso sistema de call deflection, onde dúvidas comuns são resolvidas pelos próprios pares.

Isso reduz significativamente o volume de chamados para a sua equipe de suporte, liberando seus especialistas para focarem em questões complexas e de maior valor. Estudos da TSIA (Technology & Services Industry Association) mostram que o custo de uma interação de suporte via autoatendimento (comunidade ou FAQ) pode ser até 10 vezes menor do que uma interação via call center. Empresas como a Salesforce, com sua Trailblazer Community, e a Atlassian, com seus fóruns de usuários, são exemplos clássicos de como o suporte peer-to-peer gera economia milionária anualmente e aumenta a satisfação do cliente. As respostas permanecem publicamente acessíveis, construindo uma base de conhecimento colaborativa que se enriquece a cada interação, se tornando um recurso valioso para todos.

2. Geração contínua de insights e feedback para produto

Uma comunidade vibrante atua como um canal de escuta ativa e profunda, oferecendo insights orgânicos e em tempo real que as pesquisas tradicionais raramente captam. Ela é um termômetro preciso e dinâmico para:

Pontos de fricção e usabilidade: Entenda exatamente onde suas clientes e clientes enfrentam dificuldades, diretamente da fonte.
Necessidades não atendidas e oportunidades de melhoria: Descubra o que elas e eles realmente desejam e ainda não encontraram em sua oferta.
Priorização de bugs e funcionalidades urgentes: Tome decisões de roadmap baseadas na voz autêntica de quem usa seu produto.

Essa inteligência não vem de formulários estáticos ou pesquisas padronizadas. Ela emerge de conversas genuínas, contextos ricos e nuances que as equipes de produto frequentemente não captam sozinhas. A CMX, uma das maiores comunidades globais de profissionais de comunidade, aponta que empresas com comunidades ativas reportam um ciclo de desenvolvimento de produto mais rápido e alinhado às necessidades do cliente, resultando em menor retrabalho e maior aceitação de novas funcionalidades. Esse fluxo constante de feedback qualificado é um atalho para a inovação relevante.

3. Aumento da retenção e lealdade de clientes

A longevidade da cliente e do cliente não se baseia apenas em funcionalidades ou preço. As pessoas permanecem engajadas porque se sentem parte de algo maior. Quando uma cliente ou um cliente é acolhida(o), aprende com seus pares e sente que sua voz tem peso dentro da sua marca, os resultados são claros:

Maior tempo de permanência e engajamento com a marca.
Aumento do gasto médio e exploração de outros produtos/serviços.
Defesa orgânica da marca em ambientes públicos e privados.

Um estudo da Higher Logic revelou que clientes engajados em comunidades têm uma taxa de retenção significativamente maior, chegando a 15-20% acima daqueles que não participam. Além disso, tendem a fazer compras repetidas e a ter um LTV (Lifetime Value) mais elevado. A comunidade se torna o elo emocional indispensável entre a empresa e a cliente/cliente, construindo uma lealdade que vai muito além da transação. É a base para um relacionamento duradouro e lucrativo.

4. Aquisição de novos clientes e dedução do CAC

Comunidades são potentes canais de aquisição, mas com uma distinção crucial: o fluxo é de dentro para fora. Clientes satisfeitas e satisfeitos, que tiveram experiências positivas e se sentem parte da sua marca, naturalmente se tornam advogados e promotores. Elas e eles compartilham suas histórias, recomendam seus produtos e serviços e validam sua marca para novos prospects de forma autêntica.

Pesquisas da Nielsen consistentemente mostram que as recomendações de amigos e familiares são a forma mais confiável de publicidade. Uma comunidade bem-sucedida amplifica essa confiança, transformando membros em verdadeiros defensores que endossam sua marca de forma espontânea. Isso pode reduzir o CAC (Custo de Aquisição de Cliente) em até 30%, como visto em algumas empresas com fortes programas de referência baseados em comunidade. Quando uma potencial cliente ou um potencial cliente interage com a comunidade antes mesmo de se tornar uma compradora ou um comprador, ela/ele se conecta com narrativas autênticas e validações de pares, resultando em maior confiança na decisão de compra e um ciclo de vendas mais sustentável e eficiente.

5. Inteligência de mercado e monteúdo para marketing e vendas

Uma comunidade ativa é um repositório inestimável de inteligência competitiva e insights para suas estratégias de mercado. Ela revela:

Quais temas e conteúdos geram maior tração e ressonância com o seu público.
Quais objeções de vendas são mais frequentes, permitindo que suas equipes se preparem melhor.
Quais mensagens de marketing ressoam com o seu público-alvo, otimizando suas campanhas.

Plataformas como a Reddit (para insights de nicho e tendências) ou comunidades específicas de software (para entender dores e soluções do setor) são minas de ouro para equipes de marketing e vendas. A própria Google, por exemplo, utiliza suas comunidades de desenvolvedores e usuários para captar tendências e refinar suas estratégias de comunicação e vendas. Isso permite que as equipes de marketing e vendas parem de operar com suposições e passem a se basear em dados qualitativos aprofundados, provenientes da fonte mais confiável: suas próprias clientes e clientes.

6. Construção de um diferencial inimitável

Preço, tecnologia, campanhas de marketing — tudo isso pode, em maior ou menor grau, ser replicado por concorrentes. No entanto, a cultura de uma comunidade vibrante, a profundidade das conexões entre as pessoas e a confiança que se constrói dentro dela são intrínsecas e inimaginavelmente difíceis de copiar.

Como Peter Thiel, cofundador do PayPal, argumenta, o "fosso" de uma empresa é seu diferencial competitivo que impede a cópia. A comunidade é um dos "fossos" mais poderosos e sustentáveis que uma empresa pode construir, pois é baseada em conexões humanas e lealdade emocional, algo que algoritmos e orçamentos de marketing simplesmente não conseguem replicar. É esse diferencial que transforma uma cliente ou um cliente em fã apaixonada(o) e, consequentemente, em uma embaixadora ou um embaixador ardente da sua marca.

Ative o potencial da sua comunidade

Se a sua empresa busca uma diferenciação real, um crescimento sustentável e um vínculo inquebrável com suas clientes e clientes, a resposta pode não estar em mais uma campanha de marketing ou em uma nova tecnologia. Ela reside nas pessoas que já confiam em você — e que apenas necessitam de um ambiente propício para cocriar, colaborar e prosperar em conjunto com a sua marca.

A sua comunidade já existe. A diferença fundamental reside em ignorar esse ativo valioso ou ativá-lo estrategicamente para desbloquear um novo patamar de sucesso e rentabilidade.

Como a IA Entende a Linguagem

Pachi 🥑 (she/her) — Tue, 30 Sep 2025 17:56:25 +0000

Fala galera!
Nos últimos posts vimos como a IA funciona e como ela aprende. Mas talvez a parte mais mágica pra gente que programa seja: como ela entende a nossa linguagem.

Afinal, pedir em português “me sugere um nome melhor pra essa função” e receber algo útil em segundos as vezes ainda me parece mágica haha. 🧙‍♀️✨

Pra explicar, vamos falar de três conceitos chave: NLP, LLMs e Contexto (e de quebra, um probleminha comum: as alucinações).

NLP (Processamento de Linguagem Natural)

É a área da IA que permite que as máquinas entendam e gerem linguagem humana.

Graças ao NLP, um modelo consegue interpretar comandos, traduzir frases e até responder perguntas.

💡 Exemplo: quando você pede “me explica esse erro em palavras simples” e o modelo traduz a mensagem do compilador pra algo compreensível.

LLM (Large Language Model)

Os LLMs são modelos gigantes de linguagem treinados com toneladas de textos.

Eles são capazes de escrever, traduzir, resumir e até gerar código de forma muito fluida.

ChatGPT, Gemini e LLaMA são exemplos de LLMs.

Contexto

Os modelos não têm “memória infinita”. Eles entendem o que você diz olhando para a janela de contexto, que é a quantidade de tokens que conseguem analisar de uma vez.

Quanto maior o contexto, mais fácil pra IA manter a conversa coerente.

Alucinação

Às vezes, o modelo erra bonito: inventa fatos, bibliotecas que não existem ou dados sem sentido.

Isso é o que chamamos de alucinação.

A resposta parece real, mas não é confiável, por isso sempre confira antes de usar no código. 😉

E agora?

Agora você já sabe o que permite que a IA entenda o que a gente escreve e responda de volta de forma útil.

Na Parte 4, vamos falar sobre como pessoas programadoras podem trabalhar lado a lado com a IA: code completion, code review e pair programming com IA.

XOXO

Pachi 🥑

Como a IA Aprende

Pachi 🥑 (she/her) — Wed, 17 Sep 2025 19:35:18 +0000

No primeiro post a gente viu os termos básicos: IA, Machine Learning, Deep Learning e Redes Neurais. Mas como essa mágica acontece de verdade? Como a IA aprende a gerar código, sugerir soluções ou detectar fraudes?

Hoje vamos falar de quatro conceitos que são a base desse aprendizado: modelo, dados de treinamento, tokens e tipos de aprendizado.

A ideia dessa série de artigos é trazer alguns termos por vez para facilitar no fixação do aprendizado. Eu até podia trazer tudo de uma vez, mas o artigo ia ficar grande e meio confuso, então decidi separar por partes.
Bora? 🚀

Modelo

Pensa no modelo como o cérebro da IA.
Ele é o “produto final” de todo o treinamento, quem realmente vai executar a tarefa. Mas ele não é criado sabendo, precisa aprender com exemplos.

💡 Exemplo: o GitHub Copilot é um modelo treinado para completar e sugerir código, então ele é treinado especificamente com dados de código.

Dados de Treinamento

Se o modelo é o cérebro, os dados de treinamento são a escola.
Quanto melhores e mais diversos os dados, mais inteligente e preciso o modelo fica.
🐈‍⬛ Exemplo: se você treinar um modelo só com fotos de gatos brancos, ele pode falhar na hora de reconhecer um gato preto. (Provavelmente por isso a gente ainda vê tanto bias em IA quando vamos criar imagens).

Tokens

Quando a IA trabalha com texto, ela não lê palavra por palavra. O texto é quebrado em tokens, que são pedaços menores (podem ser sílabas, partes de palavras ou palavras inteiras).

Assim, o modelo aprende a prever qual token vem a seguir.
Exemplo: a frase “Eu amo programar” pode virar Eu | amo | pro | gramar.

O ponto principal é: o modelo não pensa em palavras, mas em tokens. E tokens podem ser palavras inteiras ou pedaços delas.

Tipos de Aprendizado

Nem todo aprendizado de máquina funciona igual. Os dois principais são:

Supervisionado

Quando damos os exemplos já com as respostas corretas. Ex: ensinar um modelo a identificar spam mostrando e-mails já classificados como “spam” ou “não spam”.

Não supervisionado

Quando entregamos os dados sem respostas e o modelo precisa achar padrões sozinho. Ex: agrupar músicas por estilo sem dizer previamente o gênero de cada uma.

Agora você já sabe o que é um modelo, como ele aprende com dados, como tokens funcionam e os principais tipos de aprendizado.
Na Parte 3, vamos mergulhar em como as máquinas entendem a linguagem: LLMs, NLP e contexto.

Obrigada por ler,
Pachi 🥑