DEV Community: Camila Rody

“The “Ideal Professional”: A Reflection on the Job Market”

Camila Rody — Tue, 02 Jun 2026 21:15:49 +0000

In recent years, I’ve noticed a growing pattern across professional networks and the tech industry: the construction of an “ideal professional profile”.

A junior developer who is expected to behave like a mid-level engineer.
A mid-level engineer who is expected to perform like a senior.
A senior engineer who, beyond technical depth, is expected to operate almost like a personal brand.

Alongside this comes an even heavier layer of expectations: hundreds of courses, certifications, side projects, open-source contributions, community involvement, frequent posts, public presence, flawless English, and often a constant performance of technical authority.

The impression is that being “good enough” is no longer about doing your job well — it is about consistently appearing exceptional.

At the same time, there is a clear disconnect between these expectations and the reality inside companies.

Many organizations do not invest in professionals at the same level they expect from them. Most of the working time is spent delivering tasks, meeting deadlines, and dealing with production pressure. The limited remaining time is not always available for study or structured learning — because life outside work also exists, including rest and mental balance.

Yet, continuous evolution is still expected, almost as if it should happen automatically.

This raises an important question: how realistic and healthy are these expectations?

This is not an argument against continuous learning — it is necessary. Nor is it a suggestion that professionals should stop growing — they absolutely should. But there is a difference between sustainable growth and a constant demand for perfection.

Another relevant point is how career levels — junior, mid, and senior — have become increasingly subjective. What one company defines as senior may be considered mid-level in another context, and vice versa.

Still, job descriptions often converge into an idealized profile: full-stack mastery, advanced English, refined soft skills, product thinking, extensive experience, and sometimes even public visibility.

The result is a market that rewards an almost unreachable ideal, while not always accurately measuring real depth of competence.

I’ve seen professionals with hundreds of courses who still struggle with execution. And I’ve also seen individuals with much simpler backgrounds delivering outstanding work. This shows that formal learning and practical proficiency do not always scale together.

Perhaps the key issue is not lowering standards, but rethinking how we evaluate competence.

Companies should absolutely assess candidates carefully. But they should also recognize that real development does not happen only before hiring — it happens inside the company as well, with time, resources, and proper support.

In the end, what we seem to have is a still unresolved balance: professionals trying to meet an ever-expanding ideal, and companies expecting that ideal to already be fully formed without necessarily investing in its construction.

Maybe the healthier path lies somewhere in between — where expectations and investment grow together, and where competence is measured not only by resumes or public presence, but by consistent, real-world delivery.

"Profissional ideal": Uma reflexão sobre o mercado

Camila Rody — Tue, 02 Jun 2026 21:14:34 +0000

Nos últimos anos, tenho percebido um padrão cada vez mais forte nas redes profissionais e no mercado de tecnologia: a construção de uma espécie de “ideal de profissional”.

Um júnior que deveria ter postura de pleno.
Um pleno que já deveria agir como sênior.
Um sênior que, além de tudo, precisa ser quase uma marca pessoal.

E junto disso vem uma camada ainda maior de exigências implícitas: centenas de cursos, certificações, projetos paralelos, contribuições open source, participação em comunidades, posts frequentes, presença pública, inglês impecável e, muitas vezes, até uma performance constante de autoridade técnica.

A impressão que fica é que, para ser considerado “bom o suficiente”, não basta apenas ser um bom profissional no dia a dia. É preciso também parecer excelente o tempo todo.

Ao mesmo tempo, existe uma desconexão importante entre essa expectativa e a realidade das empresas.

Muitas organizações não oferecem o mesmo nível de investimento que exigem. O profissional passa a maior parte do seu tempo executando demandas, entregando prazos, lidando com pressão de produção. O pouco tempo livre que sobra não é, necessariamente, dedicado a estudo — porque existe também a vida fora do trabalho, o descanso, o equilíbrio mental.

E mesmo assim, espera-se que essa evolução aconteça de forma contínua, quase automática.

Isso levanta uma questão importante: até que ponto essa expectativa é saudável e realista?

Não estou dizendo que aprendizado constante não é necessário — ele é. Nem que o profissional não deve buscar evolução — ele deve. Mas existe uma diferença entre crescimento sustentável e uma cobrança contínua por perfeição.

Outro ponto que me chama atenção é como os níveis de carreira — júnior, pleno, sênior — se tornaram conceitos extremamente subjetivos. O que é sênior para uma empresa pode não ser para outra. O que é pleno em um contexto pode ser considerado júnior em outro.

E, ainda assim, muitas vagas tentam condensar tudo isso em uma descrição idealizada de um profissional que domina praticamente tudo: stack completa, inglês avançado, soft skills refinadas, visão de produto, experiência prática, maturidade comportamental e, em alguns casos, até presença pública.

O resultado disso é um mercado que valoriza um ideal difícil de alcançar — e, ao mesmo tempo, nem sempre mede de forma justa a profundidade real da competência.

Já vi profissionais com dezenas de cursos que não conseguem executar bem o básico. E também já vi pessoas com trajetórias mais simples entregando com uma excelência impressionante. Isso mostra que conhecimento formal e proficiência prática nem sempre caminham na mesma proporção.

Talvez o ponto mais importante aqui não seja reduzir exigências ou diminuir o nível do mercado, mas sim repensar como avaliamos competência.

Empresas precisam, sim, avaliar candidatos com critério. Mas também precisam reconhecer que desenvolvimento real não acontece apenas antes da contratação — ele acontece dentro dela. Com tempo, recursos, incentivo e ambiente adequado.

No fim, parece que existe um equilíbrio ainda difícil de alcançar: profissionais tentando atender um ideal cada vez mais amplo, e empresas esperando esse ideal já pronto, sem necessariamente investir na construção dele.

E talvez o caminho mais saudável esteja justamente no meio disso — onde expectativa e investimento caminham juntos, e onde competência não é medida apenas pelo que está no currículo ou no perfil público, mas pelo que é entregue com consistência na prática.

When Software Engineering Meets Real Impact: A UNICEF Collaboration

Camila Rody — Tue, 02 Jun 2026 21:00:29 +0000

There are technology projects that go beyond code. Some demand technical maturity, others demand product vision, and a few require both at the same time—especially when they have a direct impact on real people’s lives.

This was the case of my participation in the development of a child development monitoring platform, built in partnership with UNICEF and applied in a real-world context in the city of Tarumã, São Paulo. The project had direct mentorship from UNICEF professionals, including Justin and other engineers, as well as the Porta Telemedicina team, responsible for integration within the healthcare context.

More than a technical delivery, it was a project guided by product design, impact validation, and architectural decisions made under real constraints of usage, scale, and social responsibility.

Project Context: Technology with Real Impact

The goal of the platform was to support child development monitoring through a structured, organized, and accessible interface for healthcare and social assistance professionals.

The focus was not simply to “build a system,” but to understand:

How the system would be used in the field
Which information truly matters for child development monitoring
How to structure data clearly for decision-making
How to transform clinical and social data into useful visualizations

Throughout the process, there was strong guidance from UNICEF on design thinking and product discovery, where every feature was validated before being implemented.

The Importance of Design and Discovery

Before writing any code, the project went through an intense product definition phase.

During this stage, discussions included:

What should actually exist in the platform
What should be excluded to avoid cognitive overload
How professionals would use the tool in their daily routines
How to make the workflow intuitive, even in low-tech environments

This phase was essential in guiding all subsequent technical decisions.

My Role: Frontend, Architecture, and Technical Decisions

My role in the project was entirely focused on the frontend, with direct responsibility for architecture, code structure, and critical technical decisions within the application.

The tech stack included:

Vue 3
Docker
Google Maps API (with multiple modifiers and customization layers)
Figma-based design system
Modular architecture
Atomic Design
Clean Code applied at real product scale

From the beginning, the decision was not to treat the frontend as a simple “UI layer,” but as an independent, scalable, and sustainable architectural system.

Frontend Architecture: Modularity and Scalability

One of the main challenges of the project was ensuring the application could grow without becoming a difficult-to-maintain monolith.

For this reason, the architecture was structured around:

Atomic Design

The interface was divided into clear levels:

Atoms (buttons, inputs, labels)
Molecules (simple composed components)
Organisms (complete functional blocks)
Templates (page structure)
Pages (final implementation)

This approach enabled visual consistency and reuse across the entire application.

Domain-based modularization

Instead of organizing code only by file type, the structure was designed around functional domains:

Child development
Patient registration
Vaccination tracking
Geographic mapping
Reports

This reduced coupling and made maintenance easier across different teams.

Vue 3 as a Foundation for Reactivity and Structure

Vue 3 was fundamental in supporting the application’s complexity.

We used concepts such as:

Composition API for reusable logic
Composables to encapsulate frontend business rules
Domain-based state management
Clear separation between logic and presentation

This helped avoid the tight coupling commonly found in older Vue applications based on the Options API.

Google Maps Integration: Data and Interaction Layers

One of the most technical parts of the project was the integration with the Google Maps API.

The application did not use the map only for visualization, but as an interactive data layer.

We implemented:

Dynamic markers based on child development data
Geographic filters by region
Layers of information about child indicators
Contextual interactions based on location

The challenge here was handling multiple API modifiers while maintaining performance in scenarios with large datasets.

Figma-based Design System

Another key component was the implementation of a design system fully aligned with Figma.

The goal was not just to “follow the design,” but to turn it into a system.

This included:

Design tokens (colors, spacing, typography)
Strict componentization aligned with the prototype
Cross-screen consistency
Accessibility and readability considerations

The design system was essential to maintaining consistency across a platform with multiple complex flows.

Vaccination Record as a Table-Based Interface

One of the most interesting challenges was building a digital vaccination record.

It needed to:

Be clear for healthcare professionals
Strictly follow the Figma design
Function as a dynamic table
Allow fast reading of history and status

The implementation required careful attention to:

Responsive table structures
List rendering performance
Visual organization of dense data
UX for fast field usage

This was one of the points where balancing technical decisions with real usability mattered the most.

Docker and Development Environment

To ensure environment consistency, the entire application was containerized using Docker.

This enabled:

Standardized environments across the team
Easier onboarding
Reduced “it works on my machine” issues
Integration with development pipelines

Even though this was a frontend-heavy project, this decision was important for maintaining predictable development workflows.

Technical Responsibility and Individual Decision-Making

One of the most remarkable aspects of this project was the level of individual technical responsibility entrusted to me.

A significant portion of frontend architectural decisions were made by me, including:

Folder structure
Componentization strategy
Domain organization
Code standards
External API integration
Scalability patterns

This required not only technical knowledge, but also maturity to understand the impact of each decision on the final product.

The Impact of the Project

More than a functional system, this project had real social impact in a sensitive context: child development monitoring.

This completely changes the perspective on software engineering.

Every UI component, every UX decision, every data structure was not just code—it was a tool influencing decisions made by healthcare professionals in the field.

This is the kind of experience that reshapes the role of a software engineer.

We are not just building systems.

We are building infrastructure that influences real human decisions.

Conclusion

This project taught me something that goes far beyond technology.

I learned that software architecture is not only about scalability or patterns, but about responsibility.

When your code reaches real environments, with direct impact on people, every technical decision carries a different weight.

Being part of this initiative with UNICEF was one of the most important experiences of my professional journey so far—not only because of the technical complexity, but because of the meaning behind what was built.

And above all, it reinforced that software engineering can truly make a difference in people’s lives.

Desenvolvendo uma Plataforma em Parceria com a UNICEF: Uma Experiência de Engenharia, Impacto Social e Decisões de Arquitetura em Produção Real

Camila Rody — Tue, 02 Jun 2026 20:57:10 +0000

Existem projetos em tecnologia que vão além do código. Alguns exigem maturidade técnica, outros exigem visão de produto, e poucos exigem os dois ao mesmo tempo com um impacto direto na vida de pessoas reais.

Este foi o caso da minha participação no desenvolvimento de uma plataforma de monitoramento do desenvolvimento infantil, construída em parceria com a UNICEF e aplicada em território real, na cidade de Tarumã (São Paulo). O projeto contou com mentoria direta de profissionais da UNICEF, incluindo o Justin e outros engenheiros, além da equipe da Porta Telemedicina, responsável pela integração com o contexto de saúde.

Mais do que uma entrega técnica, foi um projeto guiado por design de produto, validação de impacto e decisões arquiteturais feitas sob restrições reais de uso, escala e responsabilidade social.

Contexto do Projeto: Tecnologia com Impacto Real

O objetivo da plataforma era apoiar o acompanhamento do desenvolvimento infantil através de uma interface estruturada, organizada e acessível para profissionais da saúde e assistência social.

O foco não era apenas “construir um sistema”, mas entender:

Como esse sistema seria usado em campo
Quais informações realmente importam para o acompanhamento infantil
Como estruturar dados de forma clara para tomada de decisão
Como transformar dados clínicos e sociais em visualizações úteis

Durante todo o processo, houve uma forte orientação de design thinking e product discovery junto à UNICEF, onde cada funcionalidade era validada antes de ser implementada.

A Importância do Processo de Design e Descoberta

Antes de escrever qualquer linha de código, o projeto passou por uma etapa intensa de definição de produto.

Nessa fase, foram discutidos pontos como:

O que realmente deveria existir na plataforma
O que não deveria existir para evitar sobrecarga cognitiva
Como profissionais utilizariam a ferramenta no dia a dia
Como tornar o fluxo intuitivo mesmo em ambientes com baixa familiaridade tecnológica

Essa etapa foi essencial para guiar todas as decisões técnicas posteriores.

Minha Atuação: Frontend, Arquitetura e Decisões Técnicas

Minha atuação no projeto foi integralmente no frontend, com responsabilidade direta sobre arquitetura, estruturação do código e decisões técnicas críticas da aplicação.

A stack utilizada envolveu:

Vue 3
Docker
Google Maps API (com múltiplos modificadores e camadas de personalização)
Design System baseado no Figma
Arquitetura modular
Atomic Design
Clean Code aplicado em escala de produto real

Desde o início, a decisão foi não tratar o frontend como “camada de interface”, mas como um sistema arquitetural independente, escalável e sustentável.

Arquitetura Frontend: Modularidade e Escalabilidade

Um dos principais desafios do projeto era garantir que a aplicação pudesse crescer sem se tornar um monólito difícil de manter.

Por isso, a arquitetura foi estruturada com base em:

Atomic Design

A interface foi dividida em níveis bem definidos:

Átomos (botões, inputs, labels)
Moléculas (componentes compostos simples)
Organismos (blocos funcionais completos)
Templates (estrutura de páginas)
Pages (implementação final)

Essa abordagem permitiu consistência visual e reuso em toda a aplicação.

Modularização por domínio

Ao invés de organizar o código apenas por tipo de arquivo, a estrutura foi pensada por domínio funcional:

Desenvolvimento infantil
Cadastro de pacientes
Cartela de vacinação
Mapeamento geográfico
Relatórios

Isso reduziu acoplamento e facilitou manutenção por diferentes times.

Vue 3 como Base de Reatividade e Organização

O Vue 3 foi fundamental para suportar a complexidade da aplicação.

Foram utilizados conceitos como:

Composition API para lógica reutilizável
Composables para encapsular regras de negócio no frontend
State management estruturado por domínio
Separação clara entre lógica e apresentação

Essa escolha ajudou a evitar o acoplamento comum em projetos Vue mais antigos baseados em Options API.

Integração com Google Maps: Camadas de Dados e Interação

Um dos pontos mais técnicos do projeto foi a integração com a Google Maps API.

A aplicação não utilizava o mapa apenas como visualização, mas como camada de dados interativa.

Foram implementados:

Marcadores dinâmicos baseados em dados de desenvolvimento
Filtros geográficos por região
Camadas de informação sobre indicadores infantis
Interações contextuais baseadas em localização

O desafio aqui foi lidar com múltiplos modificadores da API e garantir performance em cenários com muitos dados simultâneos.

Design System Baseado em Figma

Outro ponto fundamental foi a implementação de um design system fiel ao Figma.

A proposta não era apenas “seguir o layout”, mas transformar o design em sistema.

Isso envolveu:

Tokens de design (cores, espaçamentos, tipografia)
Componentização fiel ao protótipo
Consistência entre telas
Garantia de acessibilidade e legibilidade

O design system foi essencial para manter consistência em uma plataforma com múltiplos fluxos complexos.

Cartilha de Vacinação em Formato de Tabela

Um dos desafios mais interessantes do projeto foi a criação de uma cartilha de vacinação digital.

Ela precisava:

Ser clara para profissionais de saúde
Seguir fielmente o design do Figma
Funcionar como tabela dinâmica
Permitir leitura rápida de histórico e status

A implementação exigiu cuidado com:

Estrutura de tabelas responsivas
Performance em renderização de listas
Organização visual de dados densos
UX para leitura rápida em campo

Esse foi um dos pontos onde mais precisei equilibrar técnica com usabilidade real.

Docker e Ambiente de Desenvolvimento

Para garantir consistência entre ambientes, toda a aplicação foi containerizada com Docker.

Isso permitiu:

Padronização de ambientes entre equipe
Facilidade de onboarding
Redução de problemas de “funciona na minha máquina”
Integração com pipelines de desenvolvimento

Mesmo sendo frontend, essa decisão foi importante para garantir previsibilidade no fluxo de desenvolvimento.

Responsabilidade Técnica e Decisões Individuais

Um dos aspectos mais marcantes desse projeto foi o nível de responsabilidade técnica individual que me foi confiado.

Grande parte das decisões de arquitetura do frontend foram tomadas por mim, incluindo:

Estrutura de pastas
Estratégia de componentização
Organização de domínios
Padronização de código
Integração com APIs externas
Definição de padrões de escalabilidade

Isso exigiu não apenas conhecimento técnico, mas maturidade para entender impacto de cada decisão no produto final.

O Impacto do Projeto

Mais do que um sistema funcional, este projeto teve impacto real em um contexto social sensível: o acompanhamento do desenvolvimento infantil.

Isso muda completamente a perspectiva sobre engenharia de software.

Cada componente de interface, cada decisão de UX, cada estrutura de dados não era apenas código — era uma ferramenta que influenciava decisões tomadas por profissionais de saúde em campo.

Esse é o tipo de experiência que redefine o papel do engenheiro de software.

Não estamos apenas construindo sistemas.

Estamos construindo infraestrutura que influencia decisões humanas reais.

Conclusão

Este projeto me ensinou algo que vai muito além de tecnologia.

Aprendi que arquitetura de software não é apenas sobre escalabilidade ou padrões, mas sobre responsabilidade.

Quando seu código chega em ambientes reais, com impacto direto em pessoas, cada decisão técnica ganha um peso diferente.

Participar dessa iniciativa com a UNICEF foi uma das experiências mais importantes da minha trajetória profissional até aqui — não apenas pela complexidade técnica, mas pelo significado do que foi construído.

E, acima de tudo, por entender que engenharia de software pode literalmente fazer diferença na vida das pessoas.
posts relacionados: https://www.linkedin.com/feed/update/urn:li:activity:7195849763097837569/
https://www.linkedin.com/feed/update/urn:li:activity:7467679303888134144/

Como desenvolvi meu TCC: um vaso inteligente para monitoramento e irrigação automática de plantas

Camila Rody — Tue, 02 Jun 2026 20:46:55 +0000

Como Desenvolvi Meu TCC de Sistemas de Informação: Um Vaso Inteligente para Monitoramento e Irrigação Automática de Plantas

Durante minha graduação em Sistemas de Informação, tive a oportunidade de desenvolver um projeto que uniu algumas das áreas que mais gosto dentro da tecnologia: desenvolvimento web, arquitetura de software, Internet das Coisas (IoT), automação e experiência do usuário.

O resultado foi o E-CO Vaso Inteligente, uma solução capaz de monitorar a umidade do solo, controlar automaticamente a irrigação de plantas, registrar históricos, capturar imagens e disponibilizar todas essas informações através de uma aplicação web acessível pelo usuário. O projeto foi desenvolvido como Trabalho de Conclusão de Curso e envolveu desde a modelagem dos dados até a construção do hardware.

Neste artigo quero compartilhar não apenas os resultados, mas também o passo a passo utilizado para desenvolver a solução e os principais aprendizados adquiridos durante a construção.

https://docs.google.com/document/d/1lu6QJOUfjkW7H4vYd9bw7RpI84cVGMF6/edit?usp=drive_link&ouid=114766962307329124788&rtpof=true&sd=true

O Problema

Muitas pessoas possuem plantas em casa, mas nem sempre conseguem manter uma rotina adequada de irrigação.

O excesso de água pode ser tão prejudicial quanto a falta dela.

Além disso, viagens, rotina de trabalho e falta de conhecimento sobre cuidados específicos acabam impactando diretamente a saúde das plantas.

A proposta do projeto era criar um sistema capaz de:

Monitorar a umidade do solo
Automatizar a irrigação
Registrar histórico de atividades
Permitir controle remoto
Capturar imagens da planta
Notificar o usuário sobre eventos importantes

Arquitetura Geral da Solução

O sistema foi dividido em quatro grandes camadas:

Hardware

Responsável pela coleta de informações e acionamento dos componentes físicos.

Principais componentes:

NodeMCU ESP8266
Sensor de umidade
Bomba d'água
Válvula solenóide
Raspberry Pi para captura de imagens
Fonte de alimentação

O NodeMCU realiza a leitura constante dos sensores e envia os dados para o backend.

Backend

O backend foi desenvolvido utilizando Laravel.

Sua responsabilidade era:

Receber dados dos sensores
Processar regras de negócio
Armazenar informações
Gerenciar irrigação
Expor APIs para o frontend

Uma das partes mais interessantes da arquitetura foi a criação de um processo responsável por verificar periodicamente a umidade e tomar decisões automáticas sobre a irrigação das plantas.

Banco de Dados

Foi utilizado MariaDB, embora qualquer banco relacional compatível com SQL pudesse atender aos requisitos do projeto.

A escolha foi motivada pela aderência aos princípios ACID, garantindo consistência dos dados mesmo diante de múltiplas operações simultâneas.

As principais entidades modeladas foram:

Usuário
Planta
Indicadores
Logs
Imagens
Irrigação

Toda a modelagem foi documentada através de UML e diagramas entidade-relacionamento.

Construindo o Frontend

O frontend foi desenvolvido com Vue.js.

A ideia era criar uma aplicação desacoplada do backend para facilitar manutenção e evolução futura.

A stack utilizada foi:

Vue.js
TailwindCSS
Axios
Yarn

O Vue foi responsável pela camada reativa da interface.

O TailwindCSS permitiu construir layouts responsivos e manter consistência visual.

Já o Axios foi utilizado para consumir as APIs disponibilizadas pelo backend.

Construindo o Dashboard

O dashboard era o principal ponto de interação do usuário.

Nele eram exibidos:

Umidade atual
Histórico da planta
Gráficos de acompanhamento
Controle da bomba d'água
Controle da válvula solenóide
Configuração de horários de irrigação

Além disso, o sistema também integrava dados climáticos utilizando geolocalização para complementar as informações apresentadas ao usuário.

Funcionalidades Implementadas

Ao longo do desenvolvimento foram implementadas funcionalidades como:

Ativação do vaso

O usuário informava um código de ativação presente no dispositivo físico para associá-lo à aplicação.

Histórico de atividades

Todas as ações realizadas pelo hardware eram registradas.

Exemplos:

Leituras de umidade
Temperatura
Acionamentos da bomba
Alterações de configuração

Galeria de imagens

As imagens capturadas pelo Raspberry Pi eram armazenadas e disponibilizadas ao usuário através da aplicação web.

Configuração de irrigação

O usuário podia personalizar horários, quantidade de água e comportamento geral da automação.

Notificações

O sistema monitorava constantemente o nível de água e notificava o usuário quando necessário.

Modelando Antes de Programar

Um dos maiores aprendizados durante o desenvolvimento foi perceber o valor da modelagem.

Antes de escrever boa parte do código, foram construídos:

Casos de uso
Diagramas de classes
Diagramas de estado
Modelo entidade-relacionamento

Essa etapa ajudou a reduzir retrabalho e permitiu visualizar melhor as interações entre hardware, backend e frontend.

Hoje, trabalhando profissionalmente com desenvolvimento de software, continuo aplicando muitos desses conceitos aprendidos durante o TCC.

Principais Desafios

Nem tudo funcionou na primeira tentativa.

Um dos desafios mais interessantes ocorreu durante a construção do hardware.

Inicialmente foi utilizada uma abordagem baseada em relés para controlar os componentes eletrônicos, porém limitações relacionadas à alimentação e arquitetura do circuito levaram à busca de alternativas.

Posteriormente foram realizados testes utilizando transistores, o que permitiu um controle mais eficiente dos componentes e trouxe novas possibilidades para o projeto.

Esses experimentos acabaram gerando um aprendizado muito maior sobre eletrônica embarcada do que eu imaginava quando iniciei o trabalho.

O Que Eu Aprendi Com Esse Projeto

Este TCC me ensinou algo que levo até hoje para minha carreira:

Software raramente existe sozinho.

Projetos reais envolvem integração entre múltiplos sistemas, dispositivos, protocolos, bancos de dados, APIs e usuários.

Construir uma solução completa, desde o hardware até a interface final, mudou completamente minha visão sobre arquitetura de software e desenvolvimento de produtos.

Mais do que um projeto acadêmico, esse trabalho foi minha primeira experiência desenvolvendo um ecossistema tecnológico completo.

TCC Completo

Para quem quiser explorar a modelagem, arquitetura, diagramas, fluxos, testes realizados e toda a documentação acadêmica:

https://docs.google.com/document/d/1lu6QJOUfjkW7H4vYd9bw7RpI84cVGMF6/edit?usp=drive_link&ouid=114766962307329124788&rtpof=true&sd=true

Migrando uma aplicação Vue 2 legada de Webpack 2 para Vite: Um guia prático baseado em problemas reais

Camila Rody — Tue, 02 Jun 2026 20:29:31 +0000

Quando falamos sobre migração para Vite, a maioria dos artigos parte de um cenário ideal: projetos relativamente modernos, dependências atualizadas, versões recentes do Node e uma arquitetura preparada para evoluir. Na prática, porém, muitas empresas ainda mantêm aplicações Vue 2 que surgiram anos atrás, construídas sobre Webpack 2, carregando uma grande quantidade de bibliotecas descontinuadas, loaders obsoletos e configurações que foram sendo adaptadas por diferentes equipes ao longo do tempo.

Foi exatamente esse cenário que encontrei. O objetivo não era migrar para Vue 3, reescrever a aplicação ou modernizar toda a stack de uma vez. O desafio era muito mais delicado: substituir o Webpack 2 por Vite mantendo a aplicação funcionando, preservando compatibilidade com bibliotecas legadas e sem interromper o desenvolvimento do produto.

Ao longo desse processo, ficou evidente que a maior dificuldade não estava na configuração do Vite em si. O verdadeiro desafio era descobrir tudo aquilo que o Webpack estava fazendo silenciosamente há anos e garantir que esse comportamento fosse reproduzido no novo ambiente.

Antes de Instalar o Vite, Entenda o Que o Webpack Faz Pelo Seu Projeto

Um erro bastante comum é iniciar a migração instalando o Vite e tentando fazer a aplicação subir imediatamente. Em aplicações pequenas isso pode funcionar. Em sistemas legados, normalmente gera uma sequência interminável de erros difíceis de rastrear.

Antes de qualquer alteração, é fundamental mapear as responsabilidades atuais do Webpack. Em muitos projetos ele não atua apenas como bundler. Frequentemente também é responsável por resolver aliases, processar imagens, transpilar JavaScript, injetar variáveis de ambiente, tratar arquivos Sass, gerar chunks dinâmicos e fornecer polyfills para APIs que os navegadores não implementam nativamente.

Por isso, o primeiro passo deve ser uma auditoria da configuração existente.

Analise cuidadosamente arquivos como:

webpack.config.js
webpack.dev.js
webpack.prod.js
.babelrc
package.json

Durante essa análise, documente:

Aliases utilizados
Loaders instalados
Plugins do Webpack
Configurações do Babel
Variáveis de ambiente
Polyfills
Estratégias de code splitting
Tratamento de assets

Essa documentação servirá como roteiro para toda a migração.

Estabilize a Versão do Node Antes de Trocar o Bundler

Em projetos antigos, é comum encontrar versões do Node extremamente defasadas. Muitas vezes o sistema foi desenvolvido utilizando Node 8, Node 10 ou Node 12, e diversas dependências foram escritas considerando limitações dessas versões.

Tentar atualizar Node e substituir Webpack ao mesmo tempo costuma gerar um problema clássico: quando algo quebra, torna-se difícil descobrir a causa.

Por isso, recomendo separar completamente essas etapas.

Primeiro, valide até qual versão do Node a aplicação consegue evoluir sem alterações significativas. Durante essa fase você provavelmente encontrará dependências problemáticas como:

node-sass
extract-text-webpack-plugin
uglify-js
babel-preset-es2015

Em muitos casos, a melhor decisão não é atualizar essas bibliotecas, mas congelá-las temporariamente para reduzir riscos.

O objetivo inicial não é modernizar tudo. É criar um ambiente estável sobre o qual a migração poderá acontecer.

Instale o Vite Sem Remover o Webpack

Uma das decisões mais importantes durante minha migração foi evitar uma substituição imediata.

Em vez de remover o Webpack, o Vite foi introduzido paralelamente.

A instalação básica para Vue 2 é relativamente simples:

npm install vite vite-plugin-vue2 --save-dev

Depois disso, crie um arquivo vite.config.js:

import { defineConfig } from 'vite'
import { createVuePlugin } from 'vite-plugin-vue2'

export default defineConfig({
  plugins: [
    createVuePlugin()
  ]
})

Nesse momento o Webpack continua existindo normalmente.

Os scripts passam a coexistir:

{
  "scripts": {
    "dev": "webpack-dev-server",
    "dev:vite": "vite",
    "build": "webpack",
    "build:vite": "vite build"
  }
}

Essa abordagem permite comparar comportamentos, validar funcionalidades e criar um plano de rollback caso algo inesperado aconteça.

Migrando os Aliases

Quase toda aplicação Vue 2 de médio ou grande porte utiliza aliases para evitar imports relativos extensos.

Um exemplo comum no Webpack:

resolve: {
  alias: {
    '@': path.resolve(__dirname, 'src'),
    '@components': path.resolve(__dirname, 'src/components')
  }
}

Esses aliases precisam ser reproduzidos no Vite.

import path from 'path'

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
      '@components': path.resolve(__dirname, './src/components')
    }
  }
})

Pode parecer um detalhe pequeno, mas em aplicações grandes isso afeta centenas ou milhares de imports.

Por isso, essa costuma ser uma das primeiras configurações que implemento durante a migração.

Corrigindo Imports Dinâmicos Que Funcionavam Apenas no Webpack

Uma das incompatibilidades mais frequentes está relacionada aos famosos require() dinâmicos.

Durante anos o Webpack permitiu padrões como:

const component = require('./pages/' + pageName)

const service = require(path)

O problema é que o Vite utiliza análise estática para resolver módulos e não consegue interpretar caminhos gerados dinamicamente em tempo de execução.

Nesses casos é necessário utilizar import.meta.glob().

Antes:

const component = require(`./pages/${pageName}.vue`)

Depois:

const pages = import.meta.glob('./pages/*.vue')

const component = pages[`./pages/${pageName}.vue`]

Em projetos legados, essa costuma ser uma das etapas mais trabalhosas da migração, pois exige revisão de arquitetura em diversos pontos da aplicação.

Migrando Variáveis de Ambiente

Outro ajuste obrigatório envolve as variáveis de ambiente.

Projetos baseados em Webpack normalmente utilizam:

process.env.API_URL

No Vite o padrão é diferente.

Antes:

const apiUrl = process.env.API_URL

Depois:

const apiUrl = import.meta.env.VITE_API_URL

Além disso, o arquivo .env precisa ser adaptado:

VITE_API_URL=https://api.minhaempresa.com

Um detalhe importante é que o Vite só expõe para o frontend variáveis prefixadas com:

VITE_

Ignorar esse detalhe pode gerar erros difíceis de identificar em ambientes de homologação e produção.

Lidando com Bibliotecas CommonJS e Dependências Abandonadas

Uma das maiores preocupações em sistemas legados é a quantidade de bibliotecas que não acompanham mais a evolução do ecossistema JavaScript.

Muitas delas ainda utilizam:

module.exports = library

exports.default = library

Embora o Vite possua mecanismos de compatibilidade, alguns pacotes exigem otimizações explícitas:

export default defineConfig({
  optimizeDeps: {
    include: [
      'legacy-library',
      'old-plugin'
    ]
  }
})

Quando isso não é suficiente, uma alternativa eficiente é criar wrappers de compatibilidade para isolar o problema e evitar alterações massivas no código.

Essa abordagem reduz significativamente o impacto da migração.

Polyfills: O Problema Que Geralmente Só Aparece Depois

Durante anos o Webpack forneceu diversos polyfills automaticamente.

Quando migramos para Vite, muitos deles desaparecem.

É comum encontrar erros como:

Buffer is not defined

process is not defined

global is not defined

Um exemplo de correção para Buffer:

import { Buffer } from 'buffer'

window.Buffer = Buffer

Esses problemas normalmente surgem apenas durante testes mais profundos, por isso é importante validar cuidadosamente todas as funcionalidades críticas da aplicação.

Revisando Loaders e Assets

Grande parte da complexidade de projetos Webpack antigos está concentrada nos loaders.

É comum encontrar configurações envolvendo:

file-loader
url-loader
raw-loader
svg-loader
font-loader

A boa notícia é que muitos desses recursos são tratados nativamente pelo Vite.

Entretanto, não assuma que todos os comportamentos serão reproduzidos automaticamente.

Sempre valide:

SVGs inline
Fontes customizadas
Arquivos estáticos
Assets importados dinamicamente
Recursos utilizados por bibliotecas de terceiros

Muitos bugs de produção surgem exatamente nessa etapa.

Validando a Build de Produção

Fazer a aplicação funcionar em desenvolvimento não significa que a migração terminou.

Na verdade, a parte mais importante começa depois.

Uma validação completa deve incluir:

Navegação entre rotas
Lazy loading
Autenticação
Upload de arquivos
Integrações externas
Variáveis de ambiente
Source maps
Geração de bundles

Além disso, recomendo comparar o comportamento da aplicação construída pelo Webpack e pelo Vite simultaneamente durante algum tempo.

Essa estratégia facilita a identificação de regressões e reduz significativamente os riscos da implantação.

Conclusão

Depois de concluir essa migração, uma percepção ficou muito clara para mim: trocar Webpack por Vite é a parte fácil.

O trabalho real está em compreender todas as decisões arquiteturais acumuladas ao longo dos anos e identificar quais delas dependem diretamente do comportamento do Webpack.

Aliases, imports dinâmicos, polyfills, bibliotecas CommonJS, loaders antigos e configurações herdadas raramente aparecem na documentação do projeto. Muitas vezes, só descobrimos sua importância quando algo deixa de funcionar.

Por isso, a melhor estratégia não é migrar rápido. É migrar de forma controlada, mantendo Webpack e Vite coexistindo durante o processo, validando cada etapa e reduzindo ao máximo a quantidade de variáveis envolvidas.

Em aplicações Vue 2 legadas, o sucesso da migração não está em instalar uma ferramenta nova. Está em conseguir modernizar a infraestrutura sem alterar o comportamento que o sistema construiu ao longo dos anos.

Migrating a Legacy Vue 2 Application from Webpack 2 to Vite: A Practical Step-by-Step Guide

Camila Rody — Tue, 02 Jun 2026 20:27:44 +0000

Most migration guides assume a relatively modern codebase. They start with Vue CLI 5, recent Node versions, maintained dependencies, and a straightforward path toward Vite.

That was not my reality.

The project I inherited was a legacy Vue 2 application built on Webpack 2. The ecosystem contained deprecated loaders, abandoned plugins, outdated Babel configurations, CommonJS packages, custom aliases, and years of accumulated technical debt. Rewriting the application was not an option, and upgrading every dependency simultaneously would have introduced an unacceptable amount of risk.

The objective was simple: replace Webpack 2 with Vite while preserving the existing application architecture and maintaining compatibility with legacy dependencies.

This article focuses on the technical process itself. Rather than discussing modernization from a high level, I will walk through the exact migration strategy, the compatibility issues encountered, and the solutions that allowed the project to continue operating without a complete rewrite.

Understanding What Webpack Is Actually Doing

Before installing Vite, it is essential to understand that Webpack is not merely bundling JavaScript. In most Vue 2 applications that have existed for several years, Webpack is responsible for resolving aliases, transpiling code, injecting environment variables, loading assets, compiling stylesheets, handling code splitting, and often compensating for browser incompatibilities.

A common mistake is attempting to install Vite and immediately delete the existing Webpack configuration.

Instead, start by mapping every responsibility currently performed by Webpack.

Analyze files such as:

webpack.config.js
webpack.prod.js
webpack.dev.js
.babelrc
package.json

Document:

Aliases
Loaders
Plugins
Environment variables
Babel presets
Polyfills
Dynamic imports
Asset handling
Sass/Less configurations

Only after understanding these responsibilities should the migration begin.

Establishing a Stable Node Environment

Legacy Vue 2 projects often depend on old Node versions.

Before introducing Vite, identify the highest Node version capable of running the project without breaking dependencies.

A typical scenario looks like this:

{
  "engines": {
    "node": "8.x"
  }
}

Attempting to jump directly from Node 8 to Node 22 while simultaneously replacing Webpack introduces too many variables.

Instead:

Upgrade Node incrementally.
Verify build stability.
Resolve dependency incompatibilities.
Only then introduce Vite.

Many failures blamed on Vite are actually caused by outdated dependencies that cannot execute in modern Node environments.

Installing Vite Without Removing Webpack

The safest migration strategy is running both build systems simultaneously.

Install Vite and Vue 2 support:

npm install vite vite-plugin-vue2 --save-dev

Create a dedicated Vite configuration:

import { defineConfig } from 'vite'
import { createVuePlugin } from 'vite-plugin-vue2'

export default defineConfig({
  plugins: [
    createVuePlugin()
  ]
})

At this stage, Webpack remains untouched.

The objective is creating a parallel build environment rather than replacing the existing one immediately.

Your scripts may temporarily look like:

{
  "scripts": {
    "dev": "webpack-dev-server",
    "dev:vite": "vite",
    "build": "webpack",
    "build:vite": "vite build"
  }
}

This allows side-by-side validation throughout the migration process.

Migrating Aliases

Most large Vue 2 applications rely heavily on aliases.

A typical Webpack configuration might contain:

resolve: {
  alias: {
    '@': path.resolve(__dirname, 'src'),
    '@components': path.resolve(__dirname, 'src/components'),
    '@services': path.resolve(__dirname, 'src/services')
  }
}

These aliases must be replicated within Vite:

import path from 'path'

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
      '@components': path.resolve(__dirname, './src/components'),
      '@services': path.resolve(__dirname, './src/services')
    }
  }
})

Failure to mirror aliases correctly usually produces hundreds of import resolution errors.

This should be one of the first migration tasks completed.

Replacing Webpack-Specific Environment Variables

Webpack projects frequently depend on:

process.env.API_URL

Vite uses a different model based on native ESM.

Before:

const apiUrl = process.env.API_URL

After:

const apiUrl = import.meta.env.VITE_API_URL

Environment files must also be updated:

VITE_API_URL=https://api.company.com

One important detail is that Vite only exposes variables prefixed with:

VITE_

Variables without this prefix will not be available in client-side code.

Refactoring Dynamic Require Statements

One of the largest migration blockers in legacy Vue applications is the extensive use of runtime require statements.

Webpack tolerated patterns like:

const page = require('./pages/' + pageName)

const component = require(path)

Vite cannot statically analyze these imports.

The modern replacement is:

const pages = import.meta.glob('./pages/*.vue')

Usage:

const page = pages[`./pages/${pageName}.vue`]

This change is often unavoidable.

Projects with extensive dynamic loading mechanisms usually require dedicated refactoring during migration.

Migrating Asset Imports

Webpack loaders often hide complexity.

Examples include:

import logo from './logo.png'
import icon from './icon.svg'

Fortunately, most static assets work immediately in Vite.

However, custom loaders require investigation.

Common examples include:

file-loader
url-loader
svg-inline-loader
raw-loader

Many become unnecessary because Vite provides native handling.

When custom behavior exists, identify whether it can be replaced through:

Vite plugins
Native imports
Asset URL transformations

Never assume loader behavior automatically transfers to Vite.

Handling CommonJS Dependencies

Legacy Vue 2 projects often depend on libraries published years before ES Modules became standard.

Examples:

module.exports = library

exports.default = library

Vite can optimize many CommonJS packages automatically.

When issues occur:

export default defineConfig({
  optimizeDeps: {
    include: [
      'legacy-library',
      'old-plugin'
    ]
  }
})

For problematic packages:

import library from 'legacy-library'

export default library

Creating compatibility wrappers often avoids widespread refactoring.

Fixing Global Variables and Polyfills

Webpack silently injected several browser polyfills.

Vite does not.

Typical migration errors include:

process is not defined

Buffer is not defined

global is not defined

Solutions vary depending on usage.

For Buffer:

import { Buffer } from 'buffer'

window.Buffer = Buffer

For process:

npm install process

import process from 'process'

window.process = process

Polyfills should be added intentionally rather than globally whenever possible.

Reviewing Babel Requirements

Many Vue 2 applications contain complex Babel configurations inherited from older browser support requirements.

Example:

{
  "presets": [
    ["env", {
      "modules": false
    }]
  ]
}

Before migrating, determine whether Babel is still necessary.

In many cases:

Legacy IE support has been dropped.
Modern browsers are sufficient.
Several transformations become unnecessary.

Reducing Babel complexity often simplifies the migration significantly.

Converting Development Workflows

One of the most visible differences after migration is the development experience.

Webpack:

npm run dev

may require 20–60 seconds before changes appear.

Vite:

npm run dev:vite

typically starts almost instantly because dependencies are pre-bundled and source files are served as native ES modules.

The perceived performance improvement is often the first confirmation that the migration is succeeding.

Production Validation

A successful development server means very little.

The final phase should focus on production validation.

Review:

Routing
Authentication
API communication
File uploads
Lazy loading
Asset generation
Source maps
Environment variables

Compare generated bundles.

Analyze network requests.

Verify route-level code splitting.

Inspect console warnings.

Most migration issues appear during production builds rather than development execution.

Final Thoughts

The hardest part of migrating a Vue 2 application from Webpack 2 to Vite is not configuring Vite itself. The real challenge lies in uncovering years of implicit assumptions hidden within a mature codebase.

Webpack frequently compensates for architectural decisions that developers no longer remember making. Dynamic imports, CommonJS dependencies, deprecated loaders, implicit polyfills, and custom build behavior all become visible once the abstraction layer changes.

A successful migration is rarely a matter of replacing one bundler with another. It is an exercise in understanding the architecture deeply enough to preserve existing behavior while modernizing the tooling around it.

If I had to summarize the process into a single recommendation, it would be this: run Webpack and Vite side by side for as long as necessary. The ability to compare outputs, isolate regressions, and maintain a rollback path is often the difference between a smooth migration and weeks of production issues.

Refactoring is beyond the code and structure issues...

Camila Rody — Tue, 02 Jun 2026 20:11:38 +0000

When we talk about refactoring, we usually think about reducing complexity, eliminating duplication, improving naming, or applying design patterns. All of these are important parts of the process, but over the years I've come to realize that the best refactoring efforts rarely start with code. They start with understanding.

There's a natural tendency to look at an existing system and judge it based on what we know today. We open a massive component, a complicated business rule, or an architecture that feels outdated and immediately think, "I would do this differently." And perhaps we would. The problem is that this perspective often ignores a fundamental reality: every software system is a reflection of the circumstances in which it was built.

Code does not emerge in a vacuum. It is shaped by deadlines, technical constraints, business priorities, budget limitations, organizational pressures, and the experience level of the people involved. A decision that appears questionable today may have been the most rational choice available at the time. Perhaps the team was racing to validate a product, responding to a critical business need, or operating with far fewer resources than we have now. Maybe the technologies, frameworks, or patterns we take for granted today simply didn't exist when those decisions were made.

This is why good refactoring requires much more than identifying technical flaws. It requires understanding why certain decisions were made in the first place. Before changing a system, it's important to understand the problems it was designed to solve, the constraints that influenced its design, and the business goals it was expected to support. Without that context, we risk confusing evolution with error.

In many cases, the code itself isn't the problem. What has changed is everything around it. The business has evolved. Requirements have shifted. The team has grown. Technology has advanced. The scale of the application has increased. A solution that worked perfectly for hundreds of users may no longer be suitable for millions. An architecture that was ideal for a startup may struggle within a mature enterprise. In these situations, the original implementation wasn't necessarily wrong—it was simply built for a different reality.

That's why I increasingly see refactoring as an exercise in investigation. Before changing anything, I want to understand the story behind the system. What challenges was it trying to solve? What compromises were made? What assumptions guided its design? What constraints influenced its architecture? The answers to those questions are often far more valuable than any design pattern or technical framework.

Another aspect that is often overlooked is that refactoring isn't just about improving technical quality. It's also about preserving knowledge. Every codebase contains years of accumulated decisions, lessons learned, production incidents, business discoveries, and engineering trade-offs. Much of that knowledge never makes it into documentation, tickets, or commit messages. Instead, it becomes embedded in the structure of the system itself.

When we ignore that history, we risk removing far more than code. We may unintentionally discard valuable business knowledge, hard-earned operational experience, and solutions that exist for reasons no longer immediately visible. A mature refactoring effort doesn't simply ask what should change. It also asks what should be preserved.

Ultimately, refactoring is far less about rewriting code and far more about understanding decisions. It requires context, empathy, and a long-term perspective. Before building the next version of a system, we need to understand why the current version exists.

Because at its core, refactoring is the practice of understanding the past in order to build a better future.

Frameworks Change. JavaScript Remains.

Camila Rody — Tue, 02 Jun 2026 19:47:55 +0000

The more I study React and Vue, the more I realize that developers often spend more time debating frameworks than understanding the fundamentals that make those frameworks possible.

Discussions about performance, developer experience, ecosystem maturity, and new features are everywhere. While these conversations are valuable, they often overlook a simple reality: React and Vue are ultimately abstractions built on top of JavaScript.

When we look beneath the APIs we use every day, we find the same underlying concepts repeatedly appearing in different forms.

Take useMemo in React and computed() in Vue, for example. Although their implementations differ, both rely on the same fundamental ideas: caching, dependency tracking, and closures. The framework provides a convenient abstraction, but the underlying principles remain unchanged.

The same is true for useCallback. Many developers treat it as a magical optimization tool, when in reality it is primarily a mechanism for preserving function references across renders. To fully understand its behavior, you need to understand closures, memory references, and dependency comparisons.

Similarly, Vue's watch() and React's useEffect() may look different on the surface, but both depend on concepts such as dependency tracking, scheduling, and the Event Loop.

State management follows the same pattern. Whether you're using React's useState or Vue's ref and reactive, you're still working with the same underlying concepts: state, observability, controlled mutations, and reactivity.

Even modern asynchronous programming is built on foundations that haven't changed.

Promises and async/await dramatically improved developer experience, but they didn't replace the mechanisms that power asynchronous execution. Behind every asynchronous operation, concepts such as the Call Stack, Event Loop, Callback Queue, Microtasks, and Macrotasks continue to govern application behavior.

Frameworks evolve.

APIs evolve.

But the fundamentals remain.

And that's one of the reasons I have mixed feelings about the current wave of AI adoption in software development.

Don't get me wrong—I use AI every day.

For coding, architecture discussions, debugging, research, documentation, and learning. It has become an incredibly valuable part of my workflow.

However, I've noticed an increasingly common pattern.

Many developers are becoming highly productive without necessarily becoming more knowledgeable.

AI can generate React components, Vue composables, tests, documentation, and even architectural suggestions in seconds. The output is often impressive.

The problem is that productivity and understanding are not the same thing.

More and more, I see developers working with React, Vue, AI-assisted coding tools, and even agentic systems without fully understanding concepts such as closures, lexical scope, prototypes, hoisting, memory management, garbage collection, reference semantics, or the Event Loop.

And this concern extends far beyond JavaScript.

The same thing can happen with software architecture, design patterns, SOLID principles, system design, separation of concerns, engineering methodologies, and technical decision-making.

The immediate impact is rarely visible.

The application still works.

The feature still ships.

The sprint still ends successfully.

But over time, something important starts to erode.

The ability to reason deeply about a problem.

The ability to challenge a proposed solution.

The ability to identify architectural weaknesses before they become expensive.

The ability to understand not only how something works, but why it works.

AI is an extraordinary tool for accelerating development.

But outsourced knowledge is not acquired knowledge.

If we stop exercising our fundamentals, we gradually lose the ability to evaluate, adapt, and improve the solutions we receive.

Ironically, I believe the best way to use AI is not as a replacement for learning, but as a catalyst for it.

Ask why a solution works.

Ask about trade-offs.

Ask for alternative approaches.

Ask for deeper explanations.

Use AI as a teacher, not just as a generator.

Because the engineers who will thrive in the coming years won't simply be the ones who use AI the most.

They'll be the ones who combine strong fundamentals with powerful tools.

Frameworks will change.

Tools will change.

AI models will change.

But JavaScript fundamentals, software engineering principles, and critical thinking remain the foundation upon which everything else is built.

And that foundation is still worth investing in.

Frameworks mudam. JavaScript continua.

Camila Rody — Tue, 02 Jun 2026 19:47:00 +0000

Quanto mais estudo React e Vue, mais percebo que a discussão entre frameworks costuma receber muito mais atenção do que os fundamentos que realmente sustentam essas ferramentas.

É comum encontrar debates sobre qual framework possui melhor performance, qual oferece a melhor experiência para desenvolvedores ou qual ecossistema é mais completo. Embora essas discussões sejam relevantes, elas frequentemente ignoram um fato importante: React e Vue são apenas abstrações construídas sobre JavaScript.

Quando observamos as APIs que utilizamos diariamente, percebemos que grande parte delas existe para encapsular conceitos fundamentais da linguagem.

Quando utilizamos useMemo no React ou computed no Vue, estamos lidando com mecanismos de cache, rastreamento de dependências e retenção de estado através de closures. O framework oferece uma interface amigável, mas os princípios continuam sendo os mesmos.

Da mesma forma, useCallback não realiza nenhuma otimização mágica. Ele existe para preservar referências de funções entre renderizações. Para compreender seu comportamento, é necessário entender closures, referências em memória e comparação de dependências.

O mesmo raciocínio se aplica a watch no Vue e useEffect no React. Apesar das diferenças de implementação, ambos dependem de conceitos como dependency tracking, agendamento de execução e funcionamento do Event Loop.

Até mesmo os mecanismos de gerenciamento de estado seguem essa lógica. APIs como useState, ref e reactive mudam a forma como interagimos com o estado, mas continuam fundamentadas em conceitos como observabilidade, reatividade, mutabilidade controlada e sincronização de dados.

Quando saímos do universo dos frameworks e observamos o comportamento assíncrono das aplicações, a situação é semelhante.

Promises e async/await tornaram a programação assíncrona mais intuitiva, mas continuam dependendo dos mesmos mecanismos que sempre existiram: Call Stack, Event Loop, Callback Queue, Microtasks e Macrotasks.

Os frameworks evoluem.

As APIs mudam.

Mas os fundamentos permanecem.

E é justamente por isso que me preocupa a forma como muitos desenvolvedores estão se relacionando com a Inteligência Artificial.

A IA trouxe ganhos extraordinários de produtividade. Hoje conseguimos gerar componentes, hooks, composables, testes, documentações e até arquiteturas completas em poucos segundos. Isso é algo impressionante e extremamente valioso.

O problema surge quando a velocidade passa a substituir o entendimento.

Vejo cada vez mais desenvolvedores utilizando React, Vue, ferramentas de IA e até sistemas baseados em agentes sem compreender os conceitos fundamentais que sustentam essas tecnologias.

Conceitos como closures, escopo léxico, Event Loop, hoisting, prototypes, gerenciamento de memória, garbage collection e diferenças entre passagem por valor e passagem por referência acabam ficando em segundo plano.

E essa questão não se limita ao JavaScript.

Também percebo uma perda gradual de interesse por temas como arquitetura de software, boas práticas, padrões de projeto, princípios SOLID, separação de responsabilidades e tomada de decisão técnica.

A consequência não aparece imediatamente.

As aplicações continuam funcionando.

As tarefas continuam sendo entregues.

Mas, ao longo do tempo, torna-se mais difícil questionar soluções, identificar problemas arquiteturais, compreender gargalos de performance ou adaptar sistemas para novos cenários.

A IA pode acelerar a implementação.

Pode sugerir soluções.

Pode explicar conceitos.

Mas ela não substitui o processo de construção do conhecimento.

Conhecimento terceirizado não é conhecimento adquirido.

Por isso acredito que a melhor forma de utilizar IA não é apenas pedir respostas, mas utilizá-la como uma ferramenta de aprendizado. Questionar decisões, explorar alternativas, entender trade-offs e aprofundar conceitos continua sendo fundamental para qualquer engenheiro de software.

React é uma excelente ferramenta.

Vue também.

A Inteligência Artificial certamente é uma das maiores revoluções da nossa área.

Mas nenhuma dessas tecnologias elimina a necessidade de compreender os fundamentos.

Porque, no final das contas, frameworks mudam.

Ferramentas mudam.

Modelos de IA mudam.

Mas os princípios que sustentam a engenharia de software continuam sendo a base sobre a qual tudo é construído.

Using AI in daily work goes far beyond copying and pasting prompts

Camila Rody — Tue, 02 Jun 2026 19:42:49 +0000

When most people talk about Artificial Intelligence, the conversation usually revolves around prompts. Which prompt produces better results? Which template generates better outputs? How can we write more detailed instructions to improve responses?

While these discussions are useful, they only scratch the surface of what it actually means to build systems powered by AI.

In my day-to-day work as a Front-End and Full-Stack developer, I've realized that the difference between casually using AI and engineering AI-driven solutions lies in understanding that the model itself is only one piece of the system.

One of the most overlooked concepts in AI is that context has a cost.

Every time we send documentation, business rules, examples, previous conversations, or requirements to an LLM, we are consuming tokens. The larger the context, the greater the computational cost, latency, and operational expense.

For that reason, building intelligent systems is not simply about writing bigger or more sophisticated prompts.

In fact, as applications grow, oversized prompts often become part of the problem rather than the solution.

The challenge shifts from "How do I fit everything into the prompt?" to "How do I provide only the information that is actually needed?"

This is where concepts such as agents, skills, harnesses, memory, and retrieval become essential.
Agents allow responsibilities to be separated into specialized units instead of relying on a single model to handle everything. Different agents can focus on planning, execution, validation, research, or decision-making, creating systems that are more predictable and easier to maintain.
Skills (or tools) give those agents capabilities beyond text generation. They can query APIs, access databases, execute code, generate documents, perform calculations, or interact with external systems. In mature architectures, the LLM is not expected to know everything—it is expected to know when and how to use the right tools.
Harnesses, in my opinion, are one of the most important and least discussed parts of modern AI systems.
A harness acts as the orchestration layer. It manages context, routes requests, enforces business rules, coordinates agents, validates outputs, handles retries, and ensures consistency across workflows. Many AI projects fail not because of the model they chose, but because they lack a robust orchestration strategy.

Context management is another critical piece.

One of the biggest misconceptions in AI development is believing that more context automatically leads to better results. In reality, mature systems retrieve information on demand rather than keeping everything permanently inside the context window.
This approach reduces costs, improves performance, minimizes context pollution, and allows models to focus on the information that actually matters.

Observability and evaluation are equally important.

How do you measure quality?

How do you detect failures?

How do you ensure consistency across thousands of interactions?

How do you validate outputs before they impact end users?

These questions are engineering challenges, not prompt engineering challenges.

And that distinction matters.
I believe we are entering a new phase of AI adoption.
For a while, the competitive advantage came from Prompt Engineering.
Today, the focus is increasingly shifting toward Context Engineering, Agent Engineering, and AI Systems Architecture.
The conversation is no longer just about interacting with models.
It is about designing systems around them.
The LLM remains an incredibly important component, but it is no longer the entire product.
The real advantage comes from how effectively you orchestrate context, memory, tools, agents, evaluation layers, and specialized models into a cohesive system.
The engineers who will stand out over the next few years won't simply be the ones who know how to write better prompts.
They will be the ones who understand how to design intelligent, scalable, and sustainable AI systems.

The future of AI is not bigger prompts.

It's better architecture.

Usar IA no dia a dia vai muito além de copiar e colar prompts

Camila Rody — Tue, 02 Jun 2026 19:39:27 +0000

Quando a maioria das pessoas fala sobre Inteligência Artificial, a conversa costuma girar em torno de prompts. Qual prompt gera melhores respostas? Qual template produz melhores resultados? Como escrever instruções mais detalhadas para obter saídas mais precisas?

Embora essas discussões tenham seu valor, elas representam apenas uma pequena parte do que realmente significa construir soluções baseadas em IA.

No meu dia a dia como desenvolvedora Front-end e Full Stack, percebo que a diferença entre usar IA de forma básica e utilizar IA como uma ferramenta de engenharia está justamente em entender que o modelo é apenas uma peça do sistema.

Um dos conceitos mais negligenciados por quem está começando nessa área é que contexto possui custo.

Toda vez que enviamos documentação, regras de negócio, exemplos, conversas anteriores ou requisitos para uma LLM, estamos consumindo recursos. Quanto maior o contexto, maior a quantidade de tokens processados. Isso impacta diretamente custo, latência e escalabilidade.

Por esse motivo, arquitetar sistemas inteligentes não significa simplesmente criar prompts cada vez maiores.

Na verdade, em muitos casos, o excesso de contexto se torna parte do problema.

Conforme uma aplicação cresce, surge a necessidade de controlar quais informações realmente precisam estar disponíveis para o modelo em determinado momento. Nem tudo deve permanecer permanentemente dentro da janela de contexto.

É nesse ponto que conceitos como agentes, skills, harnesses, memória e recuperação de contexto passam a ter um papel fundamental.

Os agentes representam entidades responsáveis por executar tarefas específicas. Em vez de um único modelo tentando resolver tudo, diferentes agentes podem atuar com responsabilidades bem definidas, tornando o sistema mais previsível e organizado.

As skills funcionam como capacidades especializadas que esses agentes podem utilizar. Consultar APIs, acessar bancos de dados, gerar documentos, executar análises ou recuperar informações são exemplos de comportamentos que não precisam ser resolvidos exclusivamente pela LLM.

Já os harnesses são responsáveis por algo que considero uma das partes mais importantes da arquitetura: a orquestração.

Eles controlam o fluxo de execução, gerenciam contexto, aplicam regras de negócio, definem quais ferramentas devem ser utilizadas, validam respostas e garantem que o comportamento do sistema permaneça consistente.

Muitas vezes, quando um projeto baseado em IA apresenta problemas, a causa não está no modelo utilizado, mas na ausência de uma camada sólida de orquestração.

Outro aspecto que considero essencial é o gerenciamento de contexto.

Uma das maiores evoluções dos sistemas modernos de IA não está em aumentar indefinidamente a quantidade de informações enviadas para o modelo, mas em recuperar apenas o contexto necessário no momento adequado.

Isso reduz custos, melhora desempenho e evita que informações irrelevantes disputem atenção dentro da janela de contexto.

Da mesma forma, observabilidade e avaliação vêm se tornando componentes cada vez mais importantes.

Como medir qualidade?

Como identificar falhas?

Como garantir consistência?

Como validar respostas antes que elas impactem usuários finais?

Essas perguntas fazem parte do trabalho de engenharia e não podem ser resolvidas apenas com prompts melhores.

Por isso acredito que estamos entrando em uma nova fase da adoção de IA.

Durante algum tempo, o diferencial estava em Prompt Engineering.

Hoje, cada vez mais, o valor está em Context Engineering, Agent Engineering e AI Systems Architecture.

A conversa deixou de ser apenas sobre como interagir com modelos e passou a ser sobre como construir sistemas completos ao redor deles.

A LLM continua sendo extremamente importante, mas ela não é mais o produto inteiro.

A verdadeira vantagem competitiva está na capacidade de orquestrar contexto, memória, ferramentas, agentes e processos de avaliação de forma eficiente, escalável e sustentável.

Quem está estudando essa nova camada de engenharia provavelmente não está apenas aprendendo a usar IA.

Está aprendendo a construir a próxima geração de sistemas de software.

E vocês?

Já trabalham com agentes, skills, harnesses e gerenciamento de contexto, ou ainda utilizam IA principalmente através de prompts tradicionais?