Eu não sou um engenheiro de software
(huronbikes.mataroa.blog)- A rejeição da identidade de engenheiro de software começou há 23 anos, a partir da avaliação de que era “um bom hacker, mas não um engenheiro”
- O paradigma de agentes parece uma forma de fazer programas que deveriam ser determinísticos usando programas não determinísticos
- A confiança no código está em sua legibilidade, compreensibilidade, eficiência, capacidade de raciocínio e reprodutibilidade de produzir a mesma saída para a mesma entrada
- Os agentic user flows no trabalho e os KPIs de uso de IA são vistos como uma abordagem que prioriza métricas e entrada em linguagem natural acima de um bom código
- A visão de futuro da indústria de IA parece imaginar não apenas a substituição do desenvolvimento de software, mas a construção de um fosso em torno do próprio pensamento
Engenharia de software e o paradigma de agentes
- A postura de se excluir da identidade de engenheiro de software parte da experiência de, 23 anos atrás, ter ouvido de um colega que era “um bom hacker”, mas não um engenheiro
- O recente “novo paradigma de agentes” parece uma forma de pedir a uma máquina como Waylon Smithers que não cometa erros, e então embalar o resultado como engenharia de software especializada
- Está sendo apresentado como o futuro da engenharia de software um modo de escrever programas que deveriam ser determinísticos com programas que produzem saídas não determinísticas
- A crença básica no código continua sendo sua legibilidade, compreensibilidade, eficiência, capacidade suficiente de raciocínio e a reprodutibilidade de gerar a mesma saída para a mesma entrada
- Como a reprodutibilidade já é difícil em sistemas reais, o próprio ato de escrever código não deveria ser construído sobre “areia movediça”
- Detalhes como o impacto de views compostas por subconsultas acopladas e expressões de agregação no desempenho de consultas, inversão de controle (Inversion-of-Control) e projetos que separam funcionalidades de métodos para permitir testes independentes continuam sendo importantes
Desconfiança em relação ao fluxo de desenvolvimento centrado em IA
- Os agentic user flows exigidos no trabalho não têm significado claro, e também é difícil se convencer de por que uma caixa de texto em linguagem natural seria melhor do que escolher entre um pequeno conjunto de opções
- Há um movimento para usar agentes em todas as etapas do ciclo de vida do desenvolvimento de software, e também se diz que escrever código manualmente passará a ser tratado como usar COBOL
- Os agentes parecem wrappers de prompt para LLM que avaliam saídas de acordo com o contexto, e a saída real com frequência parece insuficiente
- O uso de IA é acompanhado por KPIs, mas nos últimos 23 anos escrever um bom código foi mais importante do que KPIs
- Um código escrito no passado recebeu a avaliação de que “parece ter sido escrito por alguém formado em matemática”, e isso foi recebido como um grande elogio
- A implementação de um staff software engineer na mesma empresa não tinha interface explícita, expunha o contêiner de DI como membro
public statice usava configuração em CSV não por ser adequada a dados tabulares, mas porque “é mais fácil para usuários de negócios usarem” - Dizer que aquela implementação era muito ruim causou problemas, e esse episódio levou à conclusão irônica de que talvez não fosse um engenheiro de software
- Já ouviu duas vezes, de pessoas consideradas inteligentes, o conselho de que a IA é o futuro da escrita de software e da indústria, e que portanto deveria ser aceita, mas essa atitude parece descuidada
- O software de IA que já usou pareceu atrapalhar o processo de pensamento ou até tomar esse processo para si ativamente, e essa apropriação (co-option) é motivo de preocupação
- Líderes de grandes empresas de IA falam com entusiasmo sobre o futuro da indústria de desenvolvimento de software, anunciam que seus produtos terão devastating effects sobre o emprego e usam a expressão “intelligence too cheap to meter”
- Esse futuro é terrível não porque máquinas vão transformar todos em clipes de papel, mas porque eles parecem imaginar a construção de um fosso em torno do próprio pensamento
1 comentários
Opiniões do Lobste.rs
Há uma história parecida em um livro de Mary Walton sobre W. Edwards Deming. Um operário de fábrica acabou produzindo apenas produtos defeituosos por causa de uma falha na máquina; ele avisou o problema, mas como a manutenção demorou, tentou consertá-la por conta própria, e então o supervisor apareceu e mandou que ele simplesmente continuasse operando
No fim, era uma ordem para “produzir defeitos”, e ele teria dito algo como: “Onde fica meu orgulho como trabalhador? Seria melhor se o supervisor me respeitasse pelo menos tanto quanto respeita a máquina.” Ele não queria fabricar produtos defeituosos e receber por isso
Vale a leitura?
Tenho muito menos experiência que o autor, mas no começo da carreira tentei tirar parte de um fluxo de trabalho de CSV por causa de vários problemas com CSV, e naquela época ouvi a resposta de que “para fluxos de trabalho de negócios, CSV é mais simples”
Na época, como o autor, achei essa resposta bem ruim, mas com o tempo passei a achar que esse julgamento estava mais para certo
Se você ainda se incomoda com a opinião idiota de alguém que disse, “há 23 anos”, que você não é engenheiro de software, acho que a solução é simplesmente ligar menos para a opinião dos outros
Se políticas idiotas do empregador ou a falta de seriedade dos colegas te frustram, procure outra empresa. Há 8 bilhões de pessoas no mundo, muitas delas querem que computadores façam alguma coisa por elas, e muitas delas pagam pelo custo da programação
Soa como dizer: “Quando trabalhei numa padaria pela primeira vez, um colega disse que croissants eram uma conspiração da Big Dairy para vender mais manteiga, então transformei isso na base da minha visão de mundo e concluí que nunca mais poderia trabalhar em padarias.” Se o autor não tivesse informado a idade, eu teria chutado que era um estudante do ensino médio, mas se ele está falando de algo que aconteceu 23 anos atrás, claramente já passou bastante dessa fase
A ideia principal não é que o autor literalmente não seja um engenheiro de software; ele provavelmente trabalhou com esse cargo por muito tempo. O ponto é mais uma reação à forma como o setor mudou, expressa por essa atitude de se excluir desse título
É como dizer: “Isto não é engenharia, é bobagem. Se é isso que significa ser engenheiro de software, então eu não sou isso”
Pessoalmente, eu me identifico com esse sentimento. Muitas vezes achei que chamar de “engenharia” o que fazemos como desenvolvedores de software é quase um insulto a outras áreas da engenharia. Principalmente porque, ao mesmo tempo em que usamos esse nome, na prática mal nos importamos com aquilo que construímos
Engenheiros civis levam muito a sério a possibilidade de uma ponte cair, e quando acontece um grande colapso, o setor inteiro reage e aprende para evitar que isso se repita. Já os chamados “engenheiros” de software podem derrubar produção repetidas vezes por motivos totalmente evitáveis e ainda colocar isso no currículo quase como história de sucesso
Sobre a direção atual da engenharia de software — isto é, a tendência de não se importar com o código que realmente vai para produção e delegar sua escrita a outra “inteligência” — você provavelmente já consegue imaginar minha opinião
Não quero dizer que entendo perfeitamente por que isso acontece nem que tenho todas as respostas sobre o que fazer. Mas não deveríamos fingir que isso é um trabalho sério, isto é, “engenharia”