Qual problema você está resolvendo?

Em algum momento, durante um curso de graduação em ciência da computação, acho que a maioria de nós já ouviu a frase "não reinvente a roda".

Lembro de quando comecei a estudar POO, há mais de duas décadas. O Java tava hypado e era comum ouvir de pessoas mais experientes esse tipo de comentário. Afinal, uma das filosofias da orientação a objetos era justamente aproveitar códigos existentes.

Quando escutei isso pela primeira vez, com alguém me explicando, eu compreendi. O conceito fez sentido.
-- Já tem biblioteca pronta para ordenar array -- era alguns dos exemplos que escutava.

Mas, nessa época eu tava afiado nesses algoritmos e sabia de cabeça implementar um quicksort.
-- Não leva muito tempo para programar um algoritmo de ordenação -- pensei.

Então, tentei entender onde mais o conceito de não reescrever algo que já existe poderia ser aplicado e realmente ser útil. Depois que comecei a trabalhar em projetos de pesquisa e desenvolvimento, passei a compreender com mais profundidade a ideia de aproveitar o que existe e funciona bem: não precisamos perder tempo e esforço em algo que não é o foco do problema.

Para mim, o significado por trás de "não reinventar a roda" está em compreender o domínio de um problema.

E, muitas vezes, isso não é resolvido simplesmente codificando um algoritmo de ordenação (a não ser que isto seja justamente o escopo do projeto). É compreender que aquilo é parte do problema. Apenas uma parte do que eu preciso para resolver algo que ainda não tem solução.

Além disso, é importante analisar o que tenho agora, o que não tenho e preciso ter, o que não preciso e o que preciso fazer de imediato.

Mas também não acredito que usar bibliotecas às cegas, sem ao menos entender o mínimo de como determinada função funciona, seja um caminho sustentável. O desafio é que o código do projeto começa a crescer cada vez mais e, se eu não souber o que tou colocando ali, isso se torna um problema depois.

-- Deu bug, por que? Preciso refatorar o código, começo por onde? Vai entrar um novo dispositivo na arquitetura do projeto, preciso mexer em qual parte do código? Parou de funcionar o que já funcionava, por que? A thread tá sobrecarregando recursos da máquina, mas não deveria ocorrer com tarefas simples, o que tá acontecendo?

Já é difícil de investigar a raiz de um bug sabendo o que estamos fazendo, mas se torna ainda mais desafiador quando não temos a noção do que estamos fazendo.

No período das LLMs que estamos vivendo hoje, a LLM é útil como ferramentas para ajudar a mitigar bugs e assim acelerar o pipeline de desenvolvimento, mas é preciso cuidado. Ela pode ajudar a apontar erros e até mesmo gerar uma solução, mas esperar que a IA além de corrigir e gere códigos para tudo, penso que é um erro. Seria como usar um trecho de código do Stackoverflow sem saber o que o código faz. É necessário ter uma revisão em cima do código gerado.

O risco de ela inserir bugs ou quebrar o que já funcionava existe, principalmente quando começa a alterar partes do código que não precisavam ser alteradas. Mesmo em códigos mais simples: se peço para gerar uma landing page para captura de leads e depois começo a pedir alguns ajustes, é comum que, entre uma iteração e outra, ela também mude coisas que eu não pedi para mudar. A complexidade aumenta para sistemas distribuídos com vários tipos de dispositivos integrados.

Porém, para corrigir erros isolados dentro de um algoritmo, uma LLM sob supervisão do programador funciona bem e pode acelerar bastante o desenvolvimento de software.

Contudo, acho importante não confundirmos a disponibilidade de ferramentas que temos com a desnecessidade de entender o problema que precisamos resolver. Acredito que a partir do momento que entendemos uma questão já temos a metade do caminho para a solução.