DEV Community: Lucas Ribeiro

Minha jornada para criar um SaaS que resolvesse minha dor de criação de conteúdo. part 2

Lucas Ribeiro — Mon, 13 Jul 2026 09:00:00 +0000

~US$ 15 por mês em modelos, uma VPS e um iPad. Como estruturei meus projetos para agentic coding, por que modelos menores resolvem a execução e o que aprendi sobre o custo oculto de revisar código de agentes

Da arquitetura de contexto para o projeto funcional

No final de 2025, um levantamento com 700 engenheiros mostrou que a maioria esmagadora dos líderes relatou aumento no tempo de revisão de código após adoção de IA. Cerca de um terço do dia do desenvolvedor passou a ser consumido revisando código de agente, corrigindo bugs sutis e trocando contexto entre tarefas. Foi esse número que me fez parar e repensar como estava estruturando meus projetos com agentes.

Na Parte 1, mostrei a estrutura de harness engineering que montei: agentes, skills e rules organizados para transbordar meu contexto para qualquer LLM. A pergunta seguinte era inevitável: como transformar essa base em um projeto real, sem que o custo cognitivo de revisar código de agente anulasse a produtividade que ele prometia? A resposta veio com uma estrutura fixa de documentação e um fluxo de desenvolvimento que venho aplicando na prática.

A estrutura fixa de projetos

Para todos os meus projetos, uso a mesma estrutura de arquivos. O motivo é simples: ficar criando prompts brilhantes do zero custa tempo. Tempo que não tenho. Estudos recentes mostram que prompts excessivamente complexos ou com instruções genéricas demais podem, inclusive, piorar o resultado do modelo em tarefas de raciocínio e extração de dados.¹ Nada melhor do que uma estrutura fixa que me permite reaproveitar o que já funcionou.

A estrutura:

description.md: guia qualquer consulta de contexto que agentes ou skills possam precisar conforme o projeto avança. É o ponto de entrada.
ui-ux.md: quando o projeto tem frontend, descrevo páginas, fluxos de navegação, interações do usuário, alertas de erro. Sem isso, agentes de frontend entregam qualquer coisa.
architecture.md: complemento técnico do description.md. Contém peças de infraestrutura, tecnologias, linguagens, frameworks e como funcionam as integrações entre componentes. Com esse arquivo, posso ter agentes e skills mais genéricos, porque as especificações suprem o contexto que faltaria.
Diagrama de alto nível da arquitetura: tem coisas que só se representam bem visualmente. Desenho uma arquitetura simples e mantenho a imagem no repositório.

Alguém pode argumentar que isso trava o projeto, porque cada escopo pede uma estrutura diferente. Mas pense pelo outro lado: ter sempre a mesma estrutura acelera a organização das ideias, porque você tem referências passadas. É otimização de tempo. Sem isso, não chego ao final de nenhum projeto.

Do Spec ao código: planejar com modelo grande, executar com modelo barato

Com a documentação inicial pronta, aplico um fluxo baseado em Spec-Driven Development, uma abordagem que trata a especificação como artefato principal e o código como derivado dela. O termo não tem uma definição única na indústria, e a implementação varia conforme o contexto do time e do projeto.² No meu caso, derivo três arquivos:

spec.md: condensa e adiciona informações técnicas. É o documento-base para tudo que vem depois.
plan.md: estrutura como vou executar e quebrar as atividades. É a ponte entre a especificação e a execução.
task.md: todas as atividades necessárias, quebradas em epics e tasks.

O projeto do Hub de Conteúdo gerou aproximadamente 20 epics e pouco mais de 100 tasks. Cada epic agrupa um conjunto de tasks relacionadas. As atividades são cadastradas no GitHub como issues e sub-issues, organizadas em um project no estilo kanban. Consigo acompanhar o andamento visualmente, mesmo acessando do iPad.

Aqui está o pulo do gato: agrupando tasks dentro de um epic, posso usar o modo de planejamento que a maioria dos agentes e modelos oferece hoje. Na fase de planejamento, uso modelos maiores e melhores, com alto nível de effort. O resultado é um plano de execução bem estruturado. Na fase de execução, mudo para modelos menores e mais baratos.

Isso só funciona porque, em 2026, a diferença entre modelos frontier para programação está na casa dos pontos percentuais, enquanto a diferença de preço está na casa das vezes. Modelos abertos como DeepSeek V4 entregam performance comparável aos modelos fechados mais caros por uma fração do custo.³ Já que o planejamento foi feito com o modelo mais capaz, não há motivo para continuar usando o mais caro para gerar código. Existem inúmeras maneiras de implementar a mesma coisa, mas com fluxos extras de qualidade e segurança rodando depois, a variação na implementação se torna irrelevante.

Modelos chineses, VPS e um iPad

A maior parte do meu uso de LLM é com modelos chineses. Desde a chegada do DeepSeek, fiquei interessado nesses modelos porque eles liberaram informações que as Big Techs ocidentais tratam como caixa preta. Boa parte é open source, permitindo reuso, destilação e fine tuning. É um nível de transparência que não vejo sendo praticado por quem vende soluções fechadas.

Também uso bastante um modelo brasileiro, da Maritaca AI, principalmente quando trabalho com conteúdo 100% nacional. Um modelo treinado nas nuances brasileiras faz diferença, e a empresa mantém contato próximo com a comunidade.

Na prática, meu ambiente de desenvolvimento é uma VPS com vscode-server, opencode, Claude Code e Pi Agent. Isso me permite programar do iPad em horários alternativos. À noite, depois do trabalho, nem sempre tenho cabeça para mais horas na frente do computador. Também quero estar com minha família. A VPS virou a ponte entre o tempo que tenho e os projetos que quero tirar do papel.

O que o código dos agentes cobra de você

Esse não é o único projeto que estou construindo, mas foi o que mais me trouxe maturidade no uso de agentes para programação. Minha função atual é mais estratégica, e a programação deixou de ser minha entrega principal. Uso GenAI para programar, mas também para documentação, análise de dados e validação de hipóteses com deep research.⁴

A maior lição veio de um desconforto específico: em determinados pontos de implementação ou refatoração, dependendo do tamanho do epic, é muito complicado revisar tudo com 100% de segurança. Senti que não tinha certeza absoluta do que havia sido desenvolvido e gastei boas horas revisando.

Estudos recentes confirmam que essa não é uma experiência isolada. Um levantamento com 700 profissionais publicado em 2026 mostrou que 81% dos líderes de engenharia relataram aumento no tempo de revisão de código após adoção de IA. Cerca de 31% do dia do desenvolvedor é consumido revisando código de IA, corrigindo bugs sutis e trocando contexto entre tarefas.⁵ Outro estudo, com rastreamento ocular, revelou que cada sugestão de código de IA introduz uma microinterrupção no fluxo do desenvolvedor. Cerca de 50% das sugestões nem são olhadas, e das que são, mais de 75% são descartadas. O custo cognitivo está na interrupção, não no resultado.⁶

É um projeto pessoal. Por isso trabalho com nível de confiança de 70% a 80%. Em ambiente corporativo, não faria dessa maneira. Precisamos equilibrar o uso da tecnologia. Estamos vendo brechas abertas por uma promessa de produtividade que, olhando os números, não se sustenta.

O saldo até agora

Tem sido enriquecedor construir um projeto do zero com aplicação real para uma dor que eu tenho. O fluxo que encontrei está fazendo sentido, não porque seja perfeito, mas porque aceita o custo cognitivo da revisão como parte do processo, e não como falha.

Consumo entre 10 e 15 dólares por mês com modelos chineses para programação, e cerca de 30 reais com modelos da Maritaca AI para revisões de conteúdo. O custo em dinheiro é baixo. O custo em atenção é real, mas administrável, desde que você saiba que ele existe. Esse é o ponto que a maioria dos posts sobre agentic coding omite.

Na Parte 3, vou detalhar os fluxos de qualidade e segurança que rodam depois da implementação, e como estou fechando o ciclo de publicação automatizada.

Referências

1. Commey, D. When "Better" Prompts Hurt: Evaluation-Driven Iteration for LLM Applications. arXiv, jan. 2026. Mostra que prompts genéricos com regras explícitas reduziram a acurácia de extração de 100% para 90% e a conformidade RAG de 93% para 80% em testes com Llama 3. https://arxiv.org/abs/2601.22025

2. Piskala, V. Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv, jan. 2026. Define níveis de maturidade de SDD e demonstra que a implementação varia conforme o contexto do time, não havendo estratégia fixa. https://arxiv.org/abs/2602.00180

3. Hexaware Technologies. The Closing Window: Open vs Closed AI Models. abr. 2026. Análise comparativa mostra quatro modelos frontier com diferença de até 0.6 pontos percentuais no SWE-Bench Verified, mas com custo de 5 a 18 vezes maior nos modelos fechados. https://hexaware.com/blogs/the-closing-window/

4. Google Research. Accelerating Scientific Discovery with AI-Powered Empirical Research Assistance. set. 2025. Sistema baseado em Gemini que testa milhares de variantes de código para validação de hipóteses científicas, reduzindo exploração de meses para horas. https://research.google/blog/accelerating-scientific-discovery-with-ai-powered-empirical-software/

5. Harness. 2026 State of Engineering Excellence Report. 2026. Apud SD Times: "The Invisible Burden: How AI is Redefining Developer Productivity in 2026." https://sdtimes.com/softwaredev/the-invisible-burden-how-ai-is-redefining-developer-productivity-in-2026/

6. ICSE 2026. An Eye for AI: Eye-Tracking the Micro-Interruptions of GenAI Code Suggestions. Artifact Award Winner. Estudo com 35 profissionais usando rastreamento ocular para medir interrupções cognitivas causadas por sugestões de código de IA. https://conf.researchr.org/details/icse-2026/icse-2026-research-track/90/An-Eye-for-AI-Eye-Tracking-the-Micro-Interruptions-of-GenAI-Code-Suggestions

Generalista ou especialista? Nenhum dos dois.

Lucas Ribeiro — Fri, 10 Jul 2026 09:00:00 +0000

Como desenvolver uma visão periférica pode transformar sua carreira em tecnologia

Por algumas das empresas pelas quais passei, sempre que tive oportunidade de mentorar pessoas, tanto no mesmo momento de carreira que eu quanto pessoas que buscavam evoluir para um nível acima, sempre tinha um questionamento que rondava essas mentorias: devo focar em ser generalista ou me especializar em algum tema?

É um questionamento muito válido. Mas acredito que pode ser bem limitante para a carreira de qualquer pessoa. As justificativas para seguir um caminho mais generalista envolvem poder atuar em várias áreas dentro da tecnologia ou até mesmo alcançar um leque maior de possibilidades.¹ Ao mesmo tempo, ser especialista, dependendo da área, pode trazer muitos benefícios: algumas empresas possuem sistemas tão críticos que é necessário contar com profissionais bem especializados em tais tecnologias, profissionais que frequentemente precisam de certificações e pós-graduações.²

Os limites da falsa dicotomia

Antes de apresentar o terceiro caminho, preciso mostrar por que os dois primeiros são mais limitados do que parecem. É aí que a visão periférica começa a fazer sentido.

Ainda assim, na minha opinião, continua sendo uma visão limitante em relação a todas as oportunidades que uma pessoa pode ter, principalmente dentro da área de tecnologia e da longevidade que as carreiras possuem hoje em dia.

Poderíamos expandir para outras profissões, mas como não tenho tanto conhecimento do que seria um especialista ou generalista dentro da advocacia ou da medicina, vou me limitar a falar de tecnologia.

Outro ponto que pode limitar ainda mais essa perspectiva: muitas pessoas acreditam que ser generalista significa estudar várias tecnologias de maneira isolada, aprender 10 linguagens de programação e encher o GitHub com projetos de skills técnicas diferentes. Por outro lado, muitos pensam que ser especialista é estudar uma tecnologia e suas stacks periféricas por anos, tirar todas as certificações e se especializar em frameworks. Dentro do mundo Java, por exemplo, é comum as pessoas tirarem certificações e se tornarem especialistas em frameworks como Spring, Hibernate e por aí vai.

Perceba que, de uma maneira ou de outra, as duas direções te limitam a olhar para dentro. Quando digo "olhar para dentro", quero dizer que você continua restrito ao campo de visão da área de tecnologia. E, definitivamente, não foi isso que me ajudou a evoluir na minha carreira.

Visão periférica: um terceiro caminho

Proponho um conceito que particularmente nunca vi ninguém falando por aí: desenvolva uma carreira com visão periférica.

Não estou falando de ser generalista, que pode ser o que as pessoas interpretem ao ler "visão periférica". O generalista acumula conhecimento em múltiplas áreas técnicas. A visão periférica que proponho é diferente: é se interessar pelo que está além da tecnologia, principalmente por pontos mais estratégicos do negócio.

Existe um limiar que todos, independente do caminho que sigam, vão enfrentar com o mesmo questionamento: o que fazer agora que cheguei nesse ponto da carreira? Tenho um nível técnico bom. Já tirei certificações. Participei de projetos relevantes. Como posso evoluir além disso? Respondo da maneira mais simples possível: agora é a hora de ser estratégico.³

Mas como uma pessoa de tecnologia pode começar a gerar impacto estratégico dentro das empresas? Só tem um caminho: precisa começar a ter mais visão de negócio, desenvolver uma boa comunicação,⁴ puxar iniciativas que impactam a empresa em diversas áreas, gerenciar pessoas (nesse ponto não estou falando em se tornar um gerente, até porque hoje existem muitas possibilidades de evolução em um caminho altamente técnico) e, por fim, mentorar outros profissionais.⁵

O caminho mais simples para iniciar essa jornada é começar a se interessar por outras áreas dentro da própria empresa onde você atua. E aqui não estou falando de outras frentes de tecnologia, mas de áreas como produto, negócio, design e suporte ao cliente. Esse último é um caminho excelente para evoluir: ter contato com o cliente fará você desenvolver uma visão da percepção do cliente sobre o negócio e, ao mesmo tempo, desenvolver a comunicação.

Não basta apenas prestar atenção em como esses profissionais agem. O ponto central é entender como eles tomam decisões. Profissionais ligados diretamente ao negócio muitas vezes utilizam dados do cliente ou do projeto para tomada de decisão. Pessoas de design utilizam percepções de psicologia e comportamento do cliente. Pessoas que trabalham com customer success precisam de boa comunicação para lidar com as necessidades mais urgentes dos clientes, além de muitas vezes coordenar diferentes núcleos de atuação para resolver problemas.

A partir do momento em que você começa a entender mais a fundo o motivo de algumas decisões,⁶ tudo muda. Quando estamos iniciando na área, ficamos muito focados em programar, eliminar tasks do backlog, resolver bugs e refatorar ou migrar projetos. Essa é a diversão para nós, pessoas técnicas. Até certo ponto faz sentido criar uma casca técnica, porque o nosso tempo é limitado e, quando somos iniciantes, pode ser difícil lidar com tudo ao mesmo tempo: evoluir tecnicamente e ainda desenvolver essa visão periférica.

Só que chegará um ponto em que desenvolver essa visão periférica será a sua prioridade. Depois que você consegue consolidar seus conhecimentos técnicos e desenvolver uma boa base teórica, fica mais simples evoluir ainda mais tecnicamente.

O que mudou na prática

Viu como focar em ser generalista ou especialista não te fará dar o próximo passo?

O que virou a minha chavinha foi começar a me interessar por outros perfis dentro, principalmente, das próprias squads pelas quais passei. Até certo ponto, comecei a ler livros, acessar comunidades específicas e, quando disponíveis, até mesmo cursos. Não com o objetivo de migrar de área, mas sim de expandir a minha visão sobre negócio.

Com isso, minha comunicação melhorou bastante. Quando digo comunicação, não é simplesmente perder o medo de se comunicar. É também saber o que não precisa ser comunicado, ser direto e entender que a maneira como você apresenta determinados assuntos exige estratégias diferentes. Com um time técnico, posso fazer um deep dive maior ao apresentar uma solução. Mas com perfis do nível de gerência para cima, preciso decidir o que não é relevante naquele momento e ainda assim conseguir passar uma mensagem relevante para aquela pessoa.

Para onde olhar agora

Deixo essa reflexão para todos que estão em dúvida sobre essas definições. Uma carreira pode ser extremamente impactante e, ao mesmo tempo, você dedicará um tempo importante da sua vida a ela. Não faz sentido ficar preso a terminologias que limitam sua visão sobre o que é possível.

Finalizo com a seguinte pergunta: o que você poderia estar fazendo agora que geraria um impacto maior do ponto de vista estratégico? Você tem se colocado na pele de outros profissionais? Tem procurado entender quais são os pontos importantes para que eles tomem suas decisões?

Compartilhe nos comentários se você já tinha essa perspectiva sobre carreira e se a minha experiência pode ter ajudado de alguma maneira.

Referências

1. Tech Guide — Alura. Projeto open-source de mapeamento de carreiras em tecnologia no modelo T-shaped.

2. Especialista vs Generalista — Oliveira, R. LinkedIn, 8 set. 2023.

3. Como você pode criar impacto em sua carreira? — Comunidade LinkedIn. LinkedIn.

4. Como desenvolver e comunicar uma visão estratégica para sua área ou equipe — Bot, nIA; Moraes, L. Exame, 22 abr. 2025.

5. O Papel do Mentor: Inspirando o Crescimento e a Autonomia — PUCRS. Blog PUCRS Online.

6. Como tomar decisões estratégicas para a sua empresa? — Great Place To Work®. GPTW, 2 jun. 2026.

Minha jornada para criar um SaaS que resolvesse minha dor de criação de conteúdo: Parte 1

Lucas Ribeiro — Fri, 10 Jul 2026 09:00:00 +0000

Mapeei US$ 300 em assinaturas que posso substituir com agentic coding. O segredo está na estrutura de contexto que você dá para os modelos.

O ponto de partida

Voltei a criar conteúdo e as dúvidas de sempre ressurgiram: posto em uma plataforma fixa? Compartilho em múltiplas redes? Hospedo um blog em VPS própria? Decidi focar no Substack. Ouço muita gente falar da capacidade de distribuição da plataforma e, de fato, tem uma comunidade interessante. Além disso, não preciso me limitar a conteúdo técnico.

No LinkedIn, por exemplo, acabei restringindo os temas ao meu dia a dia de Staff Software Engineer / Solution Architect. A plataforma tem uma aversão conhecida a qualquer politização de conteúdo, como se fosse possível descolar política, filosofia, sociologia e economia do ambiente de trabalho. Na verdade, é o lugar onde esses assuntos mais caberiam. Mas enfim, desisti de dar murro em ponta de faca.

Meu objetivo era claro: criar uma aplicação para gerenciar meus conteúdos, centralizar meus agentes de revisão e automatizar a postagem em múltiplas plataformas. O que não imaginava é que a parte técnica seria o menor dos problemas.

Construir o próprio SaaS: menos é mais

Teve uma fala do Fiasco, um Tech Creator que acompanho, que mudou minha perspectiva. Ele comentou em um dos stories que, com o avanço da IA generativa, virou corrida do ouro: todo mundo tentando construir um SaaS para ficar milionário. Só que ele trouxe um ângulo diferente, que já vi outras pessoas mencionarem, mas sem o recorte técnico (e financeiro) que ele deu.

Pare e analise quantos softwares, SaaS e aplicativos você usa no dia a dia. Quantos deles poderiam ser reconstruídos sob medida para o que você realmente precisa? No meu post anterior¹, citei uma métrica do CHAOS Report: cerca de 45% das funcionalidades de uma aplicação nunca são usadas pelos usuários e 19% raramente são tocadas. Você paga por um software inteiro para usar duas ou três funções. Em muitos casos, o problema se resolveria com uma planilha. A diferença é que agora, com agentic coding, você pode construir uma mini aplicação própria e cortar custos de assinatura.

Mapeei cerca de 300 dólares mensais em assinaturas que pretendo reduzir. Algumas não vou conseguir substituir, claro. Este projeto que vou dissecar aqui é justamente sobre isso: a jornada para construir meu ambiente de contexto, como organizo e documento os projetos, os resultados alcançados e os próximos passos.

O gargalo não é código, é tempo

O maior desafio para construir uma solução como essa não é técnico. O técnico deixou de ser limitação muito tempo atrás na minha carreira e, com a GenAI, virou commodity. Meu complicador real é o tempo e não falo isso por drama.

Tenho quase 17 anos de carreira, apesar dos meus 33. Comecei a programar aos 10 anos (quem faz parte da tropa dos que começaram com blog no WordPress deixa o like, rsss). Com família, destino a maior parte possível do meu tempo para minha esposa e minha filha. Além delas, meus pais, minha irmã e minha avó.

O que sobra dedico a interesses fora da tecnologia: ilustração, leitura e, principalmente, o ócio de pensar em vários nadas. Não me refiro ao ócio criativo do Domenico De Masi, mas ao ócio puro, sem finalidade produtiva.²

Com essa rotina, ficou claro que para levar o objetivo até o fim e sair do outro lado com um projeto funcional precisava ser o mais objetivo possível. Objetivo nas especificações, na arquitetura, no harness engineering³ e, principalmente, no tempo disponível para cada tarefa. Ao longo desta minissérie de artigos, vou destrinchar essa jornada, os desafios que existem e podem ser potencializados pelo uso massivo de GenAI e, por fim, o que interessa: o resultado.

Content/Harness Engineering: a arquitetura do contexto

Antes de começar, precisava decidir como usar a IA generativa de forma eficiente. Tenho um mantra pessoal alinhado ao propósito original da área de tecnologia: eficiência e redução de custos. Com a chegada da GenAI e, agora, do tokenmaxxing⁴, esse princípio meio que se perdeu. Mas estando no Brasil, com o dólar sempre desproporcional aos nossos ganhos, presto muita atenção nesses pontos.

O content engineering (ou harness engineering) foi a base de tudo, desde a criação da documentação até a implementação. Montei a seguinte estrutura:

Agentes

Arquitetura de soluções — Construção de especificações técnicas e decomposição em atividades
Backend — Implementação de funcionalidades baseada em SOLID
Frontend — Desenvolvimento visual com Tailwind para ganhar velocidade
QA — Testes de backend e frontend
Dados — Demandas de Data Scientist ou DBA, orientadas por skills
AI Engineer — Integração com modelos de LLM (na prática, um backend com experiência em APIs de IA)

Skills

Criação de issue — Padronização de tarefas, usada em conjunto com o agente de arquitetura
Implementação de tarefas — Instruções para execução de epics
Padrão de commit — Rastreabilidade do fluxo agentivo
Descrição de PR — Padronização de pull requests
Revisão de PR — Verificação de completude, qualidade, testes e segurança
Padrão SOLID — Garantia de boas práticas de código

Rules

Arquivos de configuração — Regras para Claude Code (CLAUDE.md), OpenCode (AGENTS.md) e Pi Agent
Revisão de conteúdo — Padrões de público-alvo e manipulação de conteúdo

Sobre o agente de AI Engineer: não gosto muito dessa nomenclatura porque, na maior parte das vezes, a função é simplesmente um backend que já teve experiência com integrações de LLMs. Poderia ser uma skill do agente de backend tranquilamente.

Estou utilizando git (com github cli), docker e make com skills simples que informam as instruções de uso de cada ferramenta. Isso agiliza a implementação e a depuração das funcionalidades.

Meu intuito foi construir uma estrutura portátil. Trabalho na linha de submodules para reaproveitar em vários projetos diferentes, podendo modificar e distribuir em todos os repositórios. Nos momentos em que precisei de código, usei pseudocódigo. A ideia foi abstrair ao máximo qualquer dependência de linguagem ou framework. E vem funcionando.

O que funcionou e o que ainda precisa melhorar

Depois de estressar várias estruturas diferentes, cheguei a esse conjunto que ficou flexível o suficiente para usar em projetos variados. Não prendi nada a exemplos específicos de código, linguagem ou framework.

Dito isso, essa estrutura é viva. Temos que estar preparados para admitir que algo que julgamos bem planejado ainda tem espaço para melhorar. Se montar uma nova estrutura daqui a seis meses e ela for completamente diferente, azar: o que importa é se está funcionando agora.

Outro ponto que trago como alerta: os modelos avançaram muito, mas me arrisco a dizer que a maior parte dos avanços até o final do ano passado foi incremental. Muita ação especializada, muita capacidade nova, mas nada que causasse ruptura. Por isso, não existe a possibilidade de criar algo usando agentes como auxiliares sem uma estrutura que consiga transbordar seu contexto para os modelos. Sem harness engineering, os agentes patinam.

Por onde começar

Neste primeiro relato, meu objetivo foi desmistificar o harness engineering. Vejo muita gente falando sobre o tema, quase sempre usando fluxogramas genéricos para exemplificar como deveria ser uma estrutura de contexto. Mas, no fim, só você, sua equipe ou sua empresa podem construir esses dados da melhor maneira possível.

Dois conselhos que posso deixar:

Antes de decidir sobre modelo ou ferramenta, mapeie o que você já tem de contexto reaproveitável e o que seria necessário para direcionar o melhor resultado do modelo.
Existem vários lugares onde você pode compartilhar e baixar skills e agentes prontos. Para aprendizado, funciona. Mas acreditar que contexto criado por outras pessoas e para cenários específicos vai funcionar no seu caso é arriscado. Sempre prefira criar os seus.

Nas próximas partes, vou detalhar como dividi as atividades em epics e como foi a implementação prática dessa estrutura.

Referências

1. The Standish Group International. CHAOS Report (2002). Dados indicam que 45% das funcionalidades nunca são utilizadas e 19% raramente. https://standishgroup.com

2. O Ócio Criativo — De Masi, D. Sextante, 2000. Publicado originalmente como L'Ozio Creativo em 1995.

3. Harness engineering: conheça o termo que está cada vez mais em alta — Bonas, M. TI Inside Online, 19 mai. 2026.

4. Taurion, C. Tokenmaxxing e o custo oculto de medir produtividade da IA por tokens. Coletivo Tech, 3 jun. 2026. https://coletivo.tech/artigos/cezar-taurion-tokenmaxxing-metrica-produtividade-ia/

Aumente o Desempenho das suas Aplicações Web com o Poder do Code Splitting!

Lucas Ribeiro — Wed, 24 May 2023 17:33:39 +0000

Introdução

Nos últimos anos, a criação de aplicações web cada vez mais complexas se tornou comum. Com essa complexidade crescente, é importante garantir aplicações cada vez mais otimizadas e uma experiência de usuário fluida.

Uma abordagem eficaz para alcançar esses objetivos é o code splitting (divisão de código), uma técnica que permite carregar partes específicas do código de forma assíncrona sob demanda.

Neste artigo, exploraremos o code splitting, discutindo suas dificuldades de implementação e os benefícios de desempenho que essa abordagem oferece.

O que é “Code Splitting”?

O code splitting é uma técnica que divide o código de uma aplicação em pacotes menores, permitindo que sejam carregados apenas quando necessários. Em vez de carregar todo o código da aplicação de uma vez só, o code splitting permite que os pacotes sejam carregados de forma assíncrona, conforme o usuário navega pela aplicação.

Dificuldades de Implementação

Embora o code splitting traga benefícios significativos para o desempenho de uma aplicação, a sua implementação pode apresentar alguns desafios. Abaixo, destacamos algumas dificuldades comuns:

Identificação de pontos de divisão: Identificar os pontos no código em que a divisão pode ocorrer é um desafio inicial. É necessário analisar e entender a estrutura da aplicação para determinar quais componentes ou rotas podem ser separados em pacotes distintos.
Gerenciamento de estado compartilhado: Ao dividir o código, é fundamental garantir que o estado compartilhado entre os pacotes seja gerenciado corretamente. O uso de gerenciadores de estado, pode ajudar a lidar com esse desafio, permitindo que o estado seja compartilhado de maneira eficiente entre os diferentes pacotes.
Manutenção da estrutura de rotas: É necessário garantir que a estrutura de rotas seja preservada. É importante que cada rota corresponda ao pacote de código apropriado, garantindo que apenas os componentes necessários sejam carregados em cada página.

Resultados

Para os meus primeiros testes, decidi seguir duas estratégias, por ROTAS e pelos COMPONENTES maiores e com maior número de dependências, assim poderia diminuir o “Circular Dependencies” para itens que não precisariam serem carregados, essa simples estratégia quase me rendeu 1 segundo de carregamento.

Resultados adquiridos sem Spliting

Resultados adquiridos com Code Spliting

Aqui vocês podem notar a diferença de um “build” feito com e sem “Code-Splitting”.

Build sem Code Spliting

Build com Code Spliting

No mundo web sabemos que sistemas que demoram mais 5 segundos para seu primeiro carregamento, são drasticamente penalizados pelos indexadores de conteúdos, fiquei muito feliz com resultado, outras estratégias devem ser aliadas para melhorar esses resultados.

Fica minha dica para as pessoas que não estudaram essa técnica, pode ser um bom ponto de partida para melhorias de desempenhos dos seus sistemas.

Benefícios alcançados

A adoção do code splitting traz diversos benefícios de desempenho.

Vejamos alguns deles:

Carregamento mais rápido: Ao dividir o código em pacotes menores, é possível reduzir o tamanho do pacote inicial que precisa ser carregado pelo navegador. Isso resulta em tempos de carregamento mais curtos, o que é especialmente crucial para usuários em conexões de internet mais lentas ou dispositivos com recursos limitados.
Melhor experiência do usuário: Ao carregar apenas o código necessário para cada rota, a experiência do usuário melhora significativamente. As transições entre páginas se tornam mais rápidas e suaves, aumentando a satisfação do usuário e diminuindo a taxa de rejeição.
Otimização de recursos: Com o code splitting, apenas o código necessário é carregado, evitando o carregamento desnecessário de componentes ou bibliotecas em páginas que não os utilizam. Isso resulta em uma utilização mais eficiente dos recursos do navegador, como memória e CPU.

Conclusão

O code splitting é uma abordagem poderosa para otimizar o desempenho de aplicações. Embora a implementação possa apresentar desafios, os benefícios obtidos são significativos. Ao dividir o código em pacotes menores e carregá-los de forma assíncrona sob demanda, podemos melhorar o tempo de carregamento das aplicações, proporcionar uma experiência do usuário mais fluida e otimizar o uso dos recursos do navegador. Ao considerar o code splitting em seus projetos, é importante entender os benefícios em relação às dificuldades de implementação, buscando alcançar um equilíbrio ideal entre desempenho e complexidade.

Referências

Transforme seus componentes Angular com variáveis CSS

Lucas Ribeiro — Sat, 20 May 2023 03:41:14 +0000

Introdução

Como engenheiros de software sabemos que existem inúmeras maneiras de resolvermos um problema. Sabemos também que existem boas ou não tão boas soluções e que elas podem ser impactadas por diversos fatores como falta de tempo, baixo conhecimento da tecnologia utilizada no projeto, falta de documentação técnica e de negócio.

Compartilho com vocês uma solução que pode não ser a melhor, mas foi, a solução que atendeu bem a demanda impactada pela perda de conhecimento técnico e de negócio da jornada que precisava do desenvolvimento de uma funcionalidade bem pontual.

Funcionalidade

A funcionalidade em si era bem tranquila, precisávamos alterar algumas cores dos componentes de uma jornada do nosso sistema, com base em uma informação do usuário.

Após efetuarmos uma análise mais aprofundada nos projetos, identificamos que seria muito complicado implementarmos uma lógica que permitisse alterar de forma dinâmica os componentes.

Escolhemos trazer a responsabilidade da mudança dos componentes para o projeto principal. Começamos a desenhar algumas soluções, como a jornada foi desenvolvida em Angular, inicialmente consideramos criar vários arquivos de SCSS específicos para serem carregados, sempre que o usuário, com a informação necessária para troca dos componentes, efetuasse login em nosso sistema.

Uma pequena observação sobre essa jornada: ela faz parte de um projeto em uma arquitetura de “micro-frontend”, logo, essa abordagem foi desenvolvimento levando essa ponto em consideração.

Implementando Service

O dado que precisamos é disponibilizado via um BFF (Backend for Frontend) desenvolvido para essa jornada, implementamos um novo endpoint, que retorna se o cliente contém ou não a informação que precisamos para efetuarmos as alterações no componente.

Com endpoint implementado, o próximo passo foi desenvolver o service, que tem a responsabilidade de chamar o serviço sempre que fosse necessário.

@Injectable({ providedIn: 'root' })
export class ComponentService {
  constructor(
    private http: HttpClient,
  ) {}

  getComponentInfo(): Observable<ComponentModel> {
    return this.http.get<ComponentModel>('url do BFF');
  }
}

Implementando Guard

No nosso “micro-forntend” implementamos um guard, que fica responsável por solicitar ao BFF a informação do cliente, sempre que o usuário acessa uma rota específica em nosso sistema.

@Injectable({
  providedIn: 'root',
})
export default class ComponentGuard implements CanActive {
  constructor(
    private readonly componentService: ComponentService,
  ) { }

  canActive(route: ActivatedRouteSnapshot, state: RouterStateSnapshot):
    boolean | UrlTree | Observable<boolean | UrlTree> | Promise<boolean | UrlTree> {
    const keyName = localStorage.getItem('keyName');
    if (!keyName) {
      this.componentService.getItem().subscribe((componentType: boolean) => {
        localStorage.setItem('keyName', componentType.keyName);
        styleProperties.map((style: IStyleProperties) => {
          document.documentElement.style.setProperty(
            `--${style.nameProperty}`,
            `${componentType.type ? style.newValueProperty : style.defaultValueProperty}`
          );
        });
      });
    } else {
      styleProperties.map((style: IStyleProperties) => {
        document.documentElement.style.setProperty(
          `--${style.nameProperty}`,
          `${keyName ? style.newValueProperty : style.defaultValueProperty}`
        );
      });
    }
    return true;
  }
}

Agora entraremos um pouco mais em detalhes da implementação.

Detalhes do Guard

Verificamos que o dado não está armazenado no localStorage, efetuamos uma nova chamada para BFF, para saber se o usuário possui ou não a informação que precisamos.

this.componentService.getItem().subscribe((componentType: boolean) => {});

Depois, adicionamos novamente no localStorage.

localStorage.setItem('keyName', componentType.keyName);

Criamos um arquivo de type bem simples, que contém informações de tipagem dos objetos que usamos para criação das variáveis de forma dinâmica.

export type IStyleProperties = {
  nameProperty: string,
  newValueProperty: string,
  defaultValueProperty: string,
}

Também, criamos um arquivo que contém todos os dados que precisamos para efetuar a customização na nossa jornada.

import { IStyleProperties } from 'IStyleProperties';

export const styleProperties: IStyleProperties[] = [
  {
    nameProperty: 'component-class',
    componentMain: '#000',
    componentDefault: '#fff'
  },
  ...
];

Partimos agora para o trecho código do nosso guard, responsável por adicionar as variáveis de CSS. Usando a função [map](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Array/map), pegamos todos os dados do arquivo de propriedades e criamos todas as variáveis necessárias para customização dos componentes.

styleProperties.map((style: IStyleProperties) => {
  document.documentElement.style.setProperty(
    `--${style.nameProperty}`,
    `${componentType.type ? style.newValueProperty : style.defaultValueProperty}`
  );
});

O document.documentElement retorna o [Elemento](https://developer.mozilla.org/pt-BR/docs/Web/API/Element) que é o elemento raiz do [documento](https://developer.mozilla.org/pt-BR/docs/Web/API/Document) (por exemplo, o elemento <html> para documentos HTML).

O [setProperty()](https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration/setProperty) define um novo valor para uma propriedade em um objeto de declaração de estilo CSS.

No arquivo app.component.scss recuperamos os valores das variáveis e alteramos o que precisamos dos componentes, para esse exemplo alteramos as fontes, background e algumas cores.

:host ::ng-deep component-selector .component-class {
  background-color: var(--component-class-background-color);
  color: var(--component-class-color);
  font-size: var(--component-class-font-size)
}

:host ::ng-deep other-component-selector .other-component-class {
  border-radius: var(--other-component-class-border-radius)
}

O seletor [:host](https://developer.mozilla.org/en-US/docs/Web/CSS/:host_function), seleciona o nódulo raiz do shadow DOM, que no caso pode ser representado por <gui-lher-me>`. No exemplo ele é responsável por mudar a cor do fundo.

A aplicação da pseudoclasse [::dg-deep](https://angular.io/guide/component-styles) a qualquer regra CSS desativa completamente o encapsulamento de exibição dessa regra. Qualquer estilo com ::dg-deep aplicado torna-se um estilo global.

Por fim, implementamos o método localStorage.removeItem('keyName'); para limparmos o localStorage sempre que o usuário desloga do sistema.

Conclusão

Meu objetivo em trazer esse case é mostrar que muitas vezes pensamos sempre em entregar a melhor solução possível, para área de negócio e os usuários finais, porém, algumas dessas vezes por questões tecnológicas e por falta de conhecimento do projeto, precisamos entregar a melhor solução naquele contexto que estamos inseridos.

Espero que gostem do conteúdo, deixem o seu like, comentem e compartilhem a opinião de vocês, com dicas e sugestões de melhorias.

~> LinkedIn