No code, Low code, Vibe coding… afinal o que vem a ser isso na vida real de um Desenvolvedor de Artefatos de software?
Nomes diferentes para algo em comum
Recentemente participei de um convite de um congresso para avaliar um artigo, algo comum para a maioria dos professores hoje em dia. E a temática do artigo era sobre “Low-Code e uma determinada metodologia de gerenciamento de processos de negócios”. O artigo versava basicamente que plataformas de desenvolvimento Low-Code permitem “a criação de soluções tecnológicas ao reduzir a necessidade de programação tradicional” de acordo com uma determinada citação, e que o trabalho questiona “como as organizações podem implementar de forma eficiente as plataformas Low-Code”.
Isso já foi tentado no passado
Esse “sonho” de “programar computadores” sem necessariamente entender de programação é antigo e pode ser referenciado pelos primeiros geradores de código no final de 80 e na década de 90, destacando-se a linguagem Clipper. Relevante dizer que foram tentativas fracassadas no desenvolvimento de artefatos sérios e confiáveis. Essa dinâmica parece ser retomada hoje em dia impulsionada pela IA e pela crescente ansiedade de desenvolver artefatos de forma mais rápida, minimizando custos. Ferramentas modernas como cursor , v0 , firebaseStudio entre outras, prometem desenvolver sistemas web e/ou apps com um mínimo de conhecimento a partir de linguagem natural. Portanto, é compreensível que pessoas de áreas satélites à computação desejem se aventurar em um ambiente que pode proporcionar soluções tecnológicas a partir de um conhecimento teórico e/ou incipiente. Isso não é novidade, já foi tentado no passado e agora recebe mais força com os avanços tecnológicos atuais.
E hoje?
É realmente preocupante a mensagem e viés que este cenário pode produzir a curto prazo no mercado de tecnologia. Afirmações como a que li no artigo: “O Low-Code transforma organizações ao reduzir a dependência de programadores e exigir foco na usabilidade e recuperação da informação.” Soa como se a presença de desenvolvedores não “exigisse” o foco na usabilidade e RI. Ou ainda, isso remonta a outras afirmações como “os escritórios de advocacia reduzem a dependência de advogados” ou “os hospitais reduzem a dependência de médicos”. A visão de que o desenvolvimento sério e estruturado de artefatos computacionais pode ser feito por pessoas sem conhecimento da área computacional é realmente preocupante, mas as organizações poderão ver por si mesmas os frutos advindos deste cenário. Problemas de segurança, estabilidade ou mesmo atualização, serão resolvidos como e por quem?
Deve-se evitar tudo isso então?
Não podemos ignorar que agora com a IA as ferramentas atuais estão avançando rápido e em algumas situações, entregando artefatos surpreendentes.
Mas algumas questões precisam ser consideradas: i) Até que ponto soluções fabricadas por ferramentas automatizadas são capazes de entregar artefatos confiáveis? ii) Neste ambiente de criação sem profissionais da computação, como personalizar e dar manutenção corretiva em sistemas desta natureza por pessoas sem conhecimento da área? iii) Quais os riscos uma organização corre ao colocar em produção um código sem testes e definição de arquitetura ou engenharia de software?
Adaptação?
Os profissionais da computação estão cientes destas ferramentas Low-Code, e devem ser capazes de fazer o uso racional e controlado destes ambientes, priorizando a capacidade de personalização e manutenção do código. Os próprios “co-pilotos” de IAs integrados aos softwares de desenvolvimentos (editores e IDEs) são uma realidade produtiva em inúmeros casos.
Porém, o mercado vai diferenciar e precificar isso rapidamente, separando os “homens dos meninos” (neste cenário em específico). Programadores bons continuarão a ter oportunidades, sem dúvida. Copiadores e montadores agora têm um rival digital, o que vai tornar a vida mais difícil, esse deve ser o caminho mais provável.
Acredito que usar essas ferramentas para ajudar na produtividade é algo válido e até racional. Mas delegar todo um artefato e depois nem saber alterar um escopo do sistema, ou mesmo saber resolver um bug, não pode ser aceitável. É inadmissível uma situação desta e em algum momento as empresas e contratantes vão perceber isso (talvez primeiro pagando caro pela decisão errada).
Portanto, o programador de hoje deve investir muito em seu conhecimento técnico, compreender arquiteturas, estruturas de dados basilares e conceitos que vão acompanhar sua carreira por longos anos. Esse profissional também precisa se aproximar de um “minset” focado em soluções, na compreensão do usuário (uma pós em psicologia? :) e nas dinâmicas satélites que compreendem uma entrega de sistema, ou melhor, em uma entrega de solução (usando tecnologia).
Então, ao ouvir que a IA vai substituir os desenvolvedores… os bons não se preocupem (a curto prazo). Temos um caminho a trilhar ainda. (Black Mirror não fez um episódio só para nós, por enquanto. :)
Um vídeo imperdível sobre isso e mais:
Vibe Coding?
Foco do Dev atual?