DEV Community: Matheus Moura

High-quality software development with AI

Matheus Moura — Mon, 24 Aug 2026 00:25:28 +0000

Este artigo também está disponível em português no link https://dev.to/matheusmoura17/desenvolvendo-software-de-qualidade-com-ia-279h

Hello! If you are reading this article, it is because you have heard the term Vibe Coding somewhere, come across some application/project that didn't work very well, or are just wanting to know a little more about it.
In this article, I will provide a brief introduction to Vibe Coding, explain some Software Quality concepts, and then talk about a new approach that is becoming popular.

What is Vibe Coding

It is an intuitive approach to building applications without needing to code a single line of code, you don't need technical knowledge, as the term itself suggests: "vibe" is similar to coding, but it's not exactly that, it's like having someone who will do the heavy lifting for you. In this methodology, you just instruct an LLM with your intuition and desires.

How it works

You describe what you want, for example: "Make a login form for a web page".
An LLM makes all the decisions about which technology to use and generates the source code.
No code generated by AI is bug-free, so you need to test everything and ensure it is working as it should. The focus is on the functionality itself, and not on reviewing the source code, meaning you will test the application as an end user.
If everything is right, your code is ready, otherwise, describe the necessary changes as in step 1 and repeat the process until finished.

Pros

Whether you are a software engineer or a person who has no idea what code is, you will be able to test your idea quickly. This is great for validating short flows, of projects that may never go into production and can be discarded right after.

I have a Designer friend who uses Vibe Coding to create screen prototypes, this allows him to validate flows quickly. Then, it's just a matter of converting everything to a Handoff (delivery documentation) in Figma, and passing it all to the developers, who will have the official layout to implement, as well as a navigable prototype to explore.

Cons

You have no control over the generated code, and this creates drastic consequences for a software. Problems will arise, and a lot of dirt (dead code) will be left behind haunting the project throughout its existence, new features might end up deriving from places they shouldn't.

I want to leave a reflection here about Vibe Coding: If you are a baker and you ask 10 people to bake a cake without specifying exactly what you want, each person will make a different cake, and you have no guarantee that the taste is as it should be, you are only evaluating the aesthetics.

Software Quality

Having a beautiful screen or well-structured code full of Design Patterns does not mean your software is good. There are globally accepted metrics as criteria for defining software quality, they range from a simple click on a button to an architectural choice that allows the portability of a microservice from AWS to Google Cloud for example.
These quality criteria are defined in ISO/IEC 25010, and can be better visualized in the image below.

When placing Vibe Coding and Software Quality side by side, it is noticeable that the two things do not work together, and the effort to have quality without knowing the code becomes increasingly arduous, even making us question whether it is worth using an LLM to generate code. If it takes you more time to make corrections than writing it manually, why use AI then? Relax, there are very effective alternatives to deal with this.

A new approach

In the Software Engineering area, some terms have emerged such as "Vibe Engineering", "Engineering-Guided AI", "Agentic Programming", among others... I believe that at some point these terms will converge into a single one because they are very similar, so in this article we will view this new approach as something abstract and without a defined nomenclature (although I particularly really like the term Engineering-Guided AI lol).

This method aims to centralize decisions on the engineer, as well as extract as much knowledge as they possess. A practical example: A team of 10 interns delivers code faster than a single senior engineer, in this context, the senior needs to clearly specify what needs to be delivered, and divide the work among the team. In a team with this amount of interns, you stop being a coder and become an orchestrator, you need to expose your ideas, review code, define architecture, and ensure that the code being developed and created meets your quality standards.

The same applies to AI, Claude Code can generate great codes, and in a surreal amount of time, you just need to specify how you want it, and for that you need to define everything as if you were talking to an intern. By following this approach and paying attention to the software quality guidelines existing in ISO/IEC 25010, we will have highly efficient and extremely high-quality software.

The idea behind it is not to outsource your macro vision and critical thinking, you must always be in control of everything that is being created, but you can use AI in absolutely all stages, even to generate insights about code review! Even in defining policies and reviewing code, just be careful not to turn a blind eye to some things...

How it works

Define the development policies for your project, which architecture to use, cite references, and make it clear how the code should be written, you can put this in a claude.md file or another location of your choice.
Now you need to interact with the code and there are several ways to do this, an engineer should not be limited to a single medium, but rather find what is best for their codebase, here I will cite some examples that I use in my daily life and see my engineer friends using:
- SDD (Spec Driven Development): It is an approach where well-structured technical specifications become the source of truth, you create specifications instead of code. In fact, this approach has a "constitution" that acts as the software development policies I mentioned earlier.
- Prompt: This is the simplest and most direct way to interact with your code, found a bug? Fix it using a prompt, need to find coupling flaws in your code? Request it via prompt! Perhaps this is the approach closest to Vibe Coding, but always be careful not to specify overly generic items, remember that you are an engineer and need to ensure the quality of the software.
- Multi Agents: This is one of the most "attractive" ways to develop software, instead of creating multiple prompts every time, you can create them once, and store them in an Agents folder, so you have a specialized agent for a type of problem, such as creating unit tests, doing a security scan, validating architectural problems, etc...
- MCP Tools: The tools allow you to interact with your codebase using external MCP servers like Figma, Jira, Github, or something of your preference, you can also create your own MCP server and provide tools that perform some specific action from your daily routine.
Review the entire process, is the generated code correct? Does the application work as it should? Routinely check if the software development policy is being met.

Pros

You have control over everything that is being implemented, and act as a software engineer, you can ensure the quality of what is being delivered and do not need to write the code manually.

Cons

The process is slower compared to Vibe Coding, you need to review more and contextualize well, otherwise the result will come out bad and you will have to make many adjustments.

Following the reflection I brought earlier, if you are a baker and you ask 10 people to bake a cake, but you specify everything that will be necessary from the beginning and review the result, everyone delivers the cake in the same way.

Conclusion

Vibe Coding cannot guarantee Software Quality, and therefore it is not suitable for robust production applications. Opt for Engineering-Guided AI, which is essential for applying advanced engineering practices since it keeps the developer at the center of decision-making.

There are various models and frameworks available, but they mean nothing without proper application. Think like a Software Engineer; explore ways to optimize your time with AI without compromising quality. The golden rule is to never outsource your critical thinking. Take control of the architecture and let AI do the heavy lifting for you.

Sources and links

Vibe Coding
https://copilot4devops.com/vibe-coding/

Qualidade de Software
https://www.sofist.co/blog/iso-iec-25010

Spec Kit
https://github.com/github/spec-kit

Spec Driven Development
https://www.softdesign.com.br/blog/spec-driven-development/

Desenvolvendo um Software de Qualidade com IA

Matheus Moura — Sun, 23 Aug 2026 08:06:06 +0000

This article is also available in English: https://dev.to/matheusmoura17/developing-a-high-quality-software-with-ai-1aj4

Olá! Se você está lendo este artigo, é porque já ouviu o termo Vibe Coding em algum lugar, se deparou com alguma aplicação/projeto que não funcionou muito bem, ou então está querendo saber um pouco mais sobre isso.
Neste artigo vou abordar uma breve introdução sobre Vibe Coding, explicar alguns conceitos de Qualidade de Software e em seguida falar sobre uma nova abordagem que está se popularizando.

O que é Vibe Coding

É uma abordagem intuitiva de construir aplicações sem precisar codificar nenhuma linha de código, você não precisa de um conhecimento técnico, como o próprio termo sugere: "vibe" é parecido com codificar, mas não é bem isso, é como ter alguém que vai fazer o trabalho pesado para você. Nessa metodologia você apenas instrui uma LLM com a sua intuição e desejos.

Como funciona

Você descreve o que você deseja, por exemplo: "Faça um formulário de login para uma página web".
Uma LLM toma todas as decisões sobre qual tecnologia utilizar e gera o código-fonte.
Nenhum código gerado por IA está livre de bugs, então você precisa testar tudo e garantir que está funcionando como deveria. O foco é a funcionalidade em si, e não a revisão do código-fonte, ou seja, você irá testar a aplicação como um usuário final.
Se tudo estiver certo, seu código está pronto, caso contrário, descreva as alterações necessárias como no passo 1 e repita o processo até finalizar.

Prós

Seja você um engenheiro de software ou uma pessoa que não faz a menor ideia do que é um código, você vai conseguir testar sua ideia rapidamente. Isso é ótimo para validar fluxos curtos, de projetos que talvez nunca vão entrar em produção e podem ser descartados em seguida.

Tenho um amigo Designer que utiliza Vibe Coding para criar protótipos de telas, isso permite que ele valide fluxos rapidamente. Em seguida é só converter tudo para um Handoff (documentação de entrega) no Figma, e repassar tudo para os desenvolvedores, que terão o layout oficial para implementar, e também um protótipo navegável para explorar.

Contras

Você não tem nenhum controle sobre o código que foi gerado, e isso gera consequências drásticas para um software. Problemas surgirão, e muita sujeira (código morto) vai ficar para trás assombrando o projeto durante toda sua existência, novas features podem acabar se derivando de locais que não deveriam.

Quero deixar aqui uma reflexão sobre Vibe Coding: Se você é um confeiteiro e pede para 10 pessoas fazerem um bolo sem especificar exatamente o que você quer, cada pessoa fará um bolo diferente, e você não tem nenhuma garantia de que o sabor está como deveria, você avalia apenas a estética.

Qualidade de software

Ter uma tela bonita ou um código bem estruturado cheio de Design Patterns não significa que seu software é bom. Existem métricas aceitas globalmente como critérios para definir a qualidade de um software, elas vão desde um simples clique num botão até uma escolha de arquitetura que permite a portabilidade de um microsserviço da AWS para Google Cloud por exemplo.
Esses critérios de qualidade são definidos na ISO/IEC 25010, e podem ser melhor visualizados na imagem abaixo.

Ao colocar Vibe Coding e Qualidade de Software lado a lado, é notável que as duas coisas não trabalham juntas, e o esforço para ter qualidade sem conhecer o código fica cada vez mais árduo, fazendo-nos questionar inclusive se vale a pena usar uma LLM para gerar código. Se você leva mais tempo para fazer correções do que escrevendo manualmente, por que usar IA então? Calma, existem alternativas muito eficazes de lidar com isso.

Uma nova abordagem

Na área de Engenharia de Software têm surgido alguns termos como "Vibe Engineering", "Engineering-Guided AI", "Agentic Programming", e entre outros... Acredito que em algum momento esses termos irão convergir em um único pois são bem similares, então nesse artigo vamos enxergar essa nova abordagem como algo abstrato e sem uma nomenclatura definida (apesar de particularmente eu gostar muito do termo Engineering-Guided AI rsrsrs).

Este método visa centralizar as decisões no engenheiro, assim como extrair o máximo possível de conhecimento que ele possua. Um exemplo prático: Uma equipe com 10 estagiários entrega código mais rápido do que um único engenheiro sênior, nesse contexto, o sênior precisa especificar bem o que precisa ser entregue, e dividir o trabalho entre o time. Numa equipe com essa quantidade de estagiários, você deixa de ser um codificador e passa a ser um orquestrador, você precisa expor suas ideias, revisar código, definir arquitetura e garantir que o código que está sendo desenvolvido e criado atenda seus padrões de qualidade.

O mesmo se aplica à IA, o Claude Code consegue gerar ótimos códigos, e num tempo surreal, você só precisa especificar como você quer, e para isso você precisa definir tudo como se estivesse falando com um estagiário. Seguindo essa abordagem e nos atentando nas diretrizes de qualidade de software existentes na ISO/IEC 25010, teremos um software altamente eficiente e de extrema qualidade.

A ideia por trás é não terceirizar sua visão macro e pensamento crítico, você deve estar sempre no controle de tudo que está sendo criado, mas você pode usar AI em absolutamente todas as etapas, até para gerar insights sobre a revisão do código! Até mesmo na definição das políticas e na revisão do código, só tome cuidado para não fazer vista grossa para algumas coisas...

Como funciona

Defina as políticas de desenvolvimento do seu projeto, qual arquitetura usar, cite referências e deixe claro como o código deve ser escrito, você pode colocar isso num arquivo claude.md ou outro local de sua escolha.
Agora você precisa interagir com o código e existem várias formas de fazer isso, um engenheiro não deve se limitar a um único meio, mas sim encontrar o que é melhor para sua base de código, aqui vou citar alguns exemplos que utilizo no meu dia a dia e vejo meus amigos engenheiros utilizando:
- SDD (Spec Driven Development): É uma abordagem onde as especificações técnicas bem estruturadas se tornam a fonte da verdade, você cria especificações ao invés de código. Inclusive, essa abordagem possui uma "constituição" que funcionam como as políticas de desenvolvimento de software que mencionei anteriormente.
- b. Prompt: Esta é a forma mais simples e direta de interagir com seu código, encontrou um bug? Corrija utilizando prompt, precisa encontrar falhas de acoplamento no seu código? Solicite isso via prompt! Talvez essa seja a abordagem mais próxima do Vibe Coding, mas esteja sempre atento a não especificar itens genéricos demais, lembre-se que você é um engenheiro e precisa garantir a qualidade do software.
- c. Multi Agents: Essa é uma das formas mais "atraentes" de desenvolver um software, ao invés de ficar criando vários prompts toda vez, você pode criar uma única vez, e guardar numa pasta Agents, assim você tem um agente especialista num tipo de problema, como criar testes unitários, fazer uma varredura de segurança, validar problemas de arquitetura, etc...
- MCP Tools: As tools permitem que você interaja com sua base de código utilizando servidores MCP externos como Figma, Jira, Github ou algo de sua preferência, você também pode criar seu próprio servidor MCP e fornecer ferramentas que realizem alguma ação específica do seu dia a dia.
Revise todo o processo, o código gerado está correto? A aplicação funciona como deveria? Verifique rotineiramente se a política de desenvolvimento de software está sendo atendida.

Prós

Você tem controle de tudo que está sendo implementado, e age como um engenheiro de software, consegue garantir a qualidade do que está sendo entregue e não precisa escrever o código manualmente.

Contras

O processo é mais lento comparado ao Vibe Coding, você precisa revisar mais e contextualizar bem, caso contrário o resultado vai sair ruim e você terá que fazer muitos ajustes.

Seguindo a reflexão que trouxe anteriormente, se você é um confeiteiro e pede para 10 pessoas fazerem um bolo, mas especifica tudo que será necessário desde o início e revisa o resultado, todos entregam o bolo da mesma maneira.

Conclusão

Vibe Coding não consegue garantir a Qualidade de Software, portanto, não serve para aplicações robustas em produção. Prefira o Engineering-Guided AI, que se mostra essencial para aplicar práticas avançadas de engenharia, uma vez que mantém o desenvolvedor no centro das decisões.

Existem vários modelos e frameworks, mas eles não significam nada sem a aplicação correta. Pense como um Engenheiro de Software, explore formas de otimizar o seu tempo com IA sem abrir mão da qualidade. A regra de ouro é nunca terceirizar o seu pensamento crítico. Assuma o controle da arquitetura e deixe a IA executar o trabalho pesado para você.

Fontes e links

Vibe Coding
https://copilot4devops.com/vibe-coding/

Qualidade de Software
https://www.sofist.co/blog/iso-iec-25010

Spec Kit
https://github.com/github/spec-kit

Spec Driven Development
https://www.softdesign.com.br/blog/spec-driven-development/

Definindo o type certo para seu array filter

Matheus Moura — Fri, 15 Mar 2024 21:35:52 +0000

Um problema comum que muitos desenvolvedores enfrentam ao utilizar Array.filter em Typescript, é a utilização de runtime ao invés de type em operações de array.filter com checagem de nulos.

Exemplo:

// Types
interface IFruitModel {
    name: string
    icon: string
}

// Models
const banana: IFruitModel = {
    name: "Banana",
    icon: "🍌"
}

// Data manipulation
const fruits = [banana, null, banana]

const fruitsIcons = fruits
    .filter(fruit => !!fruit)
    .map(fruit => fruit.icon)

console.log(fruitsIcons)

O código acima irá gerar o erro 'fruit' is possibly 'null'.(18047). Isso acontece pois durante o filter as frutas nulas são removidas, mas o type recebido no map é IFruitModel | null.

Durante o map, temos certeza que não existem frutas nulas, nosso código está correto e temos um erro de tipagem que não faz sentido.

Vou listar abaixo a forma incorreta, e a forma certa de resolver este problema.

🚨 Exemplo do que não fazer

const fruitsIcons = fruits
    .filter(fruit => !!fruit)
    .map(fruit => fruit as IFruitModel)
    .map(fruit => fruit.icon)

Neste caso, é utilizado runtime para corrigir um problema de tipagem, comprometendo a performance do sistema em prol de um simples problema que poderia ser evitado, o código transpilado para JavaScript ficaria assim:

const fruitsIcons = fruits
    .filter(fruit => !!fruit)
    .map(fruit => fruit)
    .map(fruit => fruit.icon)

Perceba que o primeiro map não faz nada a não ser retornar a própria fruta, é um desperdício de processamento.

✅ Exemplo do que fazer
A forma mais adequada de se resolver este problema, é definindo o predicado.

Em um array.filter(predicate: () => boolean), o predicado é a função que é passada por parâmetro e sempre retorna um booleano.

Podemos modificar este predicado para injetar um valor de saída no array.filter da seguinte forma:

const fruitsIcons = fruits
    .filter((fruit) : fruit is IFruitModel => !!fruit)
    .map(fruit => fruit.icon)

Deste modo a fruta que entra no filter ainda é IFruitModel | undefined, mas o retorno será um array de IFruitModel. Viabilizando o map que vem em seguida.

O código equivalente em javascript seria:

const fruitsIcons = fruits
    .filter(fruit => !!fruit)
    .map(fruit => fruit.icon)