DEV Community: João Moraes

IA, transformação digital e engenharia de software

João Moraes — Tue, 22 Sep 2026 22:01:18 +0000

Faz muito tempo que estou calado sobre Inteligência Artificial.

Mas não cheguei nesse assunto ontem.

Codifico desde 2015 e, em 2018, já trabalhava com IA na HOP, quando Inteligência Artificial ainda estava muito longe do hype que vemos hoje. Naquela época, nosso trabalho chegou a ser reconhecido com uma premiação da IBM.

Foram vários projetos, grandes empresas, multinacionais, mas também projetos menores. De lá pra cá, vi muita coisa mudar.

Cloud amadureceu. Microsserviços viraram tendência. DevOps se consolidou. APIs passaram a conectar praticamente tudo. Containers, Kubernetes, CI/CD, observabilidade e arquiteturas distribuídas entraram de vez no mundo corporativo.

Já tínhamos aplicações com Machine Learning, Deep Learning, Visão computacional...

E agora chegou a explosão da IA generativa. ChatGPT,Gemini, LLMs, RAG, agentes, copilotos, automações e, mais recentemente, o chamado “vibe coding”.

Tudo isso é incrível.

Mas também estou vendo muito hype e muito charlatanismo.

Gente vendendo IA como solução mágica.

Gente prometendo substituir equipes inteiras de desenvolvimento.

Gente construindo uma aplicação em algumas horas e confundindo isso com engenharia de software.

E talvez esteja na hora de falar mais sobre isso.

Porque fazer funcionar é apenas o começo.

Engenharia de software também é segurança, arquitetura, qualidade, testes, escalabilidade, observabilidade, disponibilidade, performance, manutenção e corretude.

É entender que tecnologia não é religião.

Não existe linguagem perfeita.

Existe linguagem adequada para determinado problema.

Java e C#, por exemplo, possuem tipagem estática, ecossistemas extremamente maduros e são muito utilizados em ambientes corporativos. Em sistemas grandes, domínios complexos, aplicações críticas, sensíveis e projetos mantidos durante anos por grandes equipes, contratos mais explícitos e ferramentas consolidadas podem trazer vantagens importantes.

Mas isso não significa que uma startup começando hoje precise necessariamente dessa mesma estrutura.

Node.js, Ruby e outras tecnologias podem proporcionar enorme produtividade, menor cerimônia e ciclos rápidos de desenvolvimento.

Para uma startup tentando descobrir se alguém realmente quer comprar seu produto, velocidade pode ser muito mais importante do que construir antecipadamente uma arquitetura preparada para milhões de usuários que talvez nunca existam.

Engenharia é contexto e trade-off.

E isso vale para praticamente tudo.

SQL ou NoSQL?

Monólito ou microsserviços?

AWS, Azure, Google Cloud ou infraestrutura própria?

REST, eventos ou mensageria?

Java, C#, Node.js, Python, Ruby, Go?

PostgreSQL, SQL Server, MongoDB, Redis?

Não existe uma resposta universal.

Um monólito bem construído pode ser muito melhor do que uma arquitetura de microsserviços criada apenas porque microsserviços estão na moda. Ainda mais se seu time for pequeno e você precisa correr pra lançar.

Assim como uma arquitetura extremamente sofisticada pode ser um enorme desperdício para uma empresa que ainda nem validou seu produto.

E agora estamos cometendo o mesmo erro com Inteligência Artificial.

A primeira pergunta virou:

“Dá para colocar IA nisso?”

Quando deveria existir uma série de perguntas antes e depois dela.

Qual problema estamos tentando resolver?

Os dados podem ser enviados para um modelo externo?

Existem dados pessoais ou sensíveis envolvidos?

Como LGPD, privacidade e governança estão sendo tratadas?

Onde esses dados ficam armazenados?

Quem possui acesso?

O modelo pode alucinar?

Qual é o impacto se ele entregar uma resposta errada?

Precisamos de RAG?

Precisamos realmente de um agente ou uma automação tradicional resolveria melhor?

Como avaliamos a qualidade das respostas?

Existe human-in-the-loop quando necessário?

Existe auditoria?

Logs?

Métricas?

Tracing?

Monitoramento?

Fallback?

Controle de acesso?

Testes?

Como fazemos deploy?

Como fazemos rollback?

Como sabemos que a versão nova ficou melhor e não simplesmente diferente?

E quando milhares de pessoas começarem a utilizar isso simultaneamente?

Quanto vai custar?

Porque uma POC funcionar no notebook de um desenvolvedor não significa que existe um produto pronto para produção.

Esse é outro ponto que o boom da IA está deixando de lado: código é apenas uma parte de um sistema.

Software sério precisa de engenharia ao redor dele.

Precisa de testes automatizados.

Pipeline de CI/CD.

Versionamento.

Revisão de código.

Gestão de secrets.

Controle de permissões.

Observabilidade.

Backup.

Recuperação de desastre.

Monitoramento.

Gestão de dependências.

Políticas de segurança.

Documentação.

E pessoas capazes de entender o que acontece quando alguma coisa dá errado.

IA também mudou profundamente a maneira como programamos.

Hoje um desenvolvedor consegue produzir em horas aquilo que alguns anos atrás poderia levar dias.

Isso é uma evolução extraordinária.

Eu uso IA e acredito profundamente no potencial dela.

Mas existe uma diferença enorme entre utilizar IA para acelerar engenharia e utilizar IA para substituir conhecimento de engenharia.

Esse talvez seja um dos maiores riscos do chamado “vibe coding”.

Você descreve o que quer.

A IA gera.

Você executa.

Funcionou.

Ótimo.

Mas quem entende aquele código?

Quem sabe quais dependências foram adicionadas?

Quem percebe uma vulnerabilidade?

Quem identifica uma query que funcionará com 500 registros, mas destruirá o banco quando existirem 50 milhões?

Quem percebe um problema de concorrência?

Quem entende por que aquela arquitetura não escala?

Quem verifica se existe uma falha de autorização expondo dados de outro usuário?

Quem assume quando a IA gerou algo aparentemente correto, mas conceitualmente errado?

Código que compila não é necessariamente código correto. Ele pode ter efeitos colaterais ainda assim.

E código correto hoje não é necessariamente um sistema sustentável amanhã.

É aí que entra algo que nenhuma ferramenta deveria substituir: fundamento técnico e capacidade de decisão.

Saber programar não é decorar sintaxe.

É entender estruturas de dados, algoritmos, bancos de dados, redes, concorrência, segurança, arquitetura, sistemas distribuídos e, principalmente, saber analisar problemas.

As ferramentas mudam.

Os frameworks mudam.

As linguagens mudam.

A infraestrutura muda.

Agora até a maneira como escrevemos código está mudando.

Mas os fundamentos continuam extremamente importantes.

E existe ainda outro problema silencioso: débito técnico.

IA consegue gerar código em uma velocidade absurda.

Consequentemente, também consegue gerar dívida técnica em uma velocidade absurda.

Uma empresa pode acreditar que está economizando porque entregou algo em três semanas em vez de três meses.

Até descobrir, meses depois, que ninguém consegue evoluir o sistema sem quebrar alguma coisa.

Velocidade sem arquitetura pode virar retrabalho.

Escalabilidade sem necessidade pode virar custo.

Segurança tratada depois pode virar incidente.

IA sem governança pode virar risco.

E transformação digital sem engenharia pode virar apenas uma demonstração bonita.

Por isso decidi começar a falar mais sobre esses assuntos.

Depois de anos trabalhando com software e acompanhando IA desde muito antes dessa explosão recente, quero compartilhar conhecimento sobre Inteligência Artificial, desenvolvimento, arquitetura, cloud, segurança, dados e transformação digital.

Sem demonizar tecnologia nova.

Sem defender tecnologia antiga apenas porque é antiga.

E principalmente sem vender mágica.

Estou disposto a ajudar desenvolvedores, gestores e empresas a entenderem onde IA realmente gera valor e onde estão apenas colocando IA porque alguém disse que precisam colocar.

Porque acredito muito no que está acontecendo.

A IA vai transformar profundamente a maneira como construímos software e como empresas operam.

Só que transformação digital séria precisa ser construída com segurança, qualidade, escalabilidade, governança e corretude.

A IA está tornando cada vez mais fácil criar software.

E isso é fantástico.

Mas talvez justamente por isso nunca tenha sido tão importante entender a diferença entre:

gerar código

fazer engenharia de software.

What you need to know to get started with Serverless Databases

João Moraes — Sat, 04 Nov 2023 16:16:33 +0000

Serverless databases: what they are, where they are, and examples

Serverless databases are a new way to store data in the cloud. They are fully managed by the cloud provider, which means that developers do not need to worry about infrastructure tasks such as provisioning, scaling, and maintenance.

Basic concepts

Serverless databases are based on the infrastructure as a service (IaaS) model. This means that the cloud provider provides all the infrastructure needed to run the database, including servers, storage, and networking. The developer simply connects to the database and starts using it.

Where are they?

Serverless databases are run in the cloud. They can be located in any region of the world, which makes them ideal for global applications.

Examples

Some examples of serverless databases include:

CosmosDB (Microsoft): a flexible schema NoSQL database that is automatically scaled.
Cloud Firestore (Google): a document-based NoSQL database that is ideal for mobile and web applications.
DynamoDB (AWS): a key-value NoSQL database that is ideal for high-performance applications.
Advantages and disadvantages

Serverless databases offer a number of advantages, including:

Simplicity: Developers do not need to worry about infrastructure tasks, which can save time and money.
Scalability: Serverless databases are automatically scaled, which means that developers do not need to worry about scaling.
Cost savings: Serverless databases are charged based on usage, which can lead to savings compared to traditional databases.
However, serverless databases also have some disadvantages, including:

Performance limitations: Serverless databases may have performance limitations for applications with large volumes of data or transactions.
Reduced control: Developers have less control over database resources than in a traditional database.
Conclusion

Serverless databases are an attractive option for developers who are looking for a simple, scalable, and economical data storage solution. However, it is important to carefully evaluate the advantages and disadvantages before choosing a serverless database.

Assessment of examples

CosmosDB

CosmosDB is a flexible schema NoSQL database that is automatically scaled. It supports multiple data models, including documents, graphs, key-value, and columns. CosmosDB is a good option for applications that need horizontal scalability and data flexibility.

Advantages:

Scalability: CosmosDB is automatically scaled, which means that developers do not need to worry about scaling.
Flexibility: CosmosDB supports multiple data models, which makes it a good option for applications with different data requirements.
Global availability: CosmosDB is available in multiple regions around the world, which makes it a good option for global applications.
Disadvantages:

Cost: CosmosDB can be expensive for applications with large volumes of data.
Complexity: CosmosDB can be complex to use, especially for developers who are not familiar with NoSQL databases.
Cloud Firestore

Cloud Firestore is a document-based NoSQL database that is ideal for mobile and web applications. It is based on the Google Cloud Platform and supports a variety of features, including offline synchronization, enterprise-level security, and integration with other Google Cloud services.

Advantages:

Ease of use: Cloud Firestore is easy to use, even for developers with little database experience.
Integrity: Cloud Firestore supports a variety of security features, including authentication and authorization.
Global availability: Cloud Firestore is available in multiple regions around the world, which makes it a good option for global applications.
Disadvantages:

Performance limitations: Cloud Firestore may have performance limitations for applications with large volumes of data or transactions.
Reduced control: Developers have less control over database resources than in a traditional database.

Remote Work

João Moraes — Sun, 22 Jan 2023 22:27:51 +0000

REMOTE WORK: What do you think about ?

The truth is that today's world allows us to work remotely! We have fast internet, several means of communication that allow us to keep in touch in real time and if we need to travel to visit clients, for example, we also have many options. In addition, work in most companies today is results-oriented. You don't need to be physically there at the company to show that you're working.

Remote work: work from anywhere in the world!
Home office: Requires you to work from home.

OK, but how are companies positioning themselves in relation to all this?
There are those that are known as remote-first, that is, in that company, working remotely is the standard. These companies have less "paperwork" and more electronic material, the employees' schedules are public to facilitate communication and they do not need to have a physical headquarters.
On the other hand, there are remote-friendly companies that accept the employee to work remotely. They may even open remote work vacancies, but their default is Onsite Work. In these companies, meetings happen in conference rooms, there are more employees on site than remote and they use "paperwork" more than electronic material.
About tools that help with day-to-day tasks and communication for those who work remotely: Slack, Zoom, Google Drive, Trello, Quip, Pipefy, etc.
Disadvantages remote work: limited contact with professionals, loss of focus with day-to-day distractions, getting lost in working hours, putting too many rules at home.
Advantages: time saving, financial savings, schedule flexibility, no dress code.
Companies that accept remote work: Gitlab, Github, Dell, Spotify, Toptal, Amazon, Adobe, StackOverflow, among others.

In the last 4 years I have been working remotely and it's been a very good experience!

Basic example of.. FP

João Moraes — Fri, 28 May 2021 04:11:23 +0000

Here is a basic example of using functional programming inside javascript language, a multiparadigm language that provides support for functional programming. In the first image, there is an imperative approach to manipulating a list of names. And in the second image, a functional approach is being used to manipulate the same list of names.

In the image above, dealing with the imperative approach, an empty list is created to be filled with the names in lower case. Subsequently, a temporary variable called "i" is created to iterate through the list. Then, each item modified from the list received as a parameter is added to the new list. In this approach, it is possible to see that the machine is being told how it should perform its work, in detail.

In the image above, dealing with the declarative / functional approach, the original list calls the javascript map method, which invokes a function in each item covered in the list, in this case a callback function, which in turn is a function that makes lowercase string letters. The map method returns a new list, without modifying the original list and thus guaranteeing the absence of side effects and the presence of immutability.

The code snippets of both images aim to create a new list with the names in lowercase letters, however, it is easy to see that the code of the second image is smaller, cleaner and more intuitive. Consequently, it is easier to be tested and reused.

technology #development #softwaredeveloper #javascript #javascriptdeveloper