Entrevista: Herminio Rocha, da Maha Systems, sobre engenharia, diagnóstico e IA supervisionada
Herminio Rocha, fundador da Maha Technology Systems, software house do interior do Paraná, fala sobre entender a operação antes do código, engenharia que sobrevive ao mundo real e IA com supervisão: o engenheiro define, o agente executa.

A série de entrevistas da Softdex ouve os líderes das software houses brasileiras sobre como elas nascem, o que as diferencia e para onde o setor está indo. O convidado desta edição é Herminio Rocha, fundador da Maha Technology Systems, software house do interior do Paraná. Com mais de oito anos de estrada em contextos que vão de operações financeiras a logística e IoT, e um produto próprio no mercado (o Gestor PRO, voltado a oficinas e assistências técnicas), ele defende que a tecnologia vem depois do entendimento e resume sua abordagem de IA em uma frase: o engenheiro define, o agente executa.
O que motivou você a empreender abrindo uma software house?
Minha trajetória com desenvolvimento de software começou bem antes da Maha. São mais de oito anos trabalhando com tecnologia, passando por back-end, desenvolvimento mobile, integrações, arquitetura e sistemas em produção em contextos bastante diferentes, de operações financeiras e bancárias até logística, educação, gestão empresarial e projetos envolvendo hardware e IoT.
Com o tempo, uma coisa começou a se repetir.
Muitas empresas chegavam com uma ideia de solução já pronta: "preciso de um aplicativo", "preciso trocar esse sistema", "preciso integrar isso com aquilo". Mas, quando você entrava de verdade na operação, percebia que o problema quase nunca começava na tecnologia.
Às vezes o fluxo estava errado. Às vezes existiam três sistemas que não conversavam. Às vezes uma planilha tinha virado parte crítica da empresa. Em outros casos, desenvolver exatamente o que havia sido pedido significaria simplesmente transformar um processo ruim em um software caro.
Foi daí que a Maha começou a ganhar forma.
Eu queria ter uma estrutura própria na qual pudesse assumir o problema de ponta a ponta, não simplesmente receber uma especificação e devolver código. Entender a operação, questionar quando necessário, desenhar a arquitetura, desenvolver, integrar, colocar em produção e acompanhar o comportamento real da solução.
A experiência com produto próprio também reforçou muito isso. O Gestor PRO, por exemplo, nasceu olhando problemas bastante concretos de pequenas operações, principalmente oficinas e assistências técnicas: ordem de serviço, caixa, estoque, histórico do cliente, processos que muitas vezes estavam espalhados entre papel, planilha e WhatsApp.
Construir um produto próprio muda bastante a cabeça de quem desenvolve software. Você deixa de pensar apenas na entrega da funcionalidade e começa a conviver com suporte, usuário real, custo de infraestrutura, evolução do banco, compatibilidade, migração, observabilidade, cobrança e decisões que precisam continuar fazendo sentido meses depois.
A Maha acabou sendo consequência dessa trajetória: transformar experiência de engenharia em uma empresa capaz de resolver problemas reais de negócio com software.
O que você acredita ser o principal diferencial da sua software house?
Eu resumiria em uma frase: na Maha, a tecnologia vem depois do entendimento.
Parece simples, mas essa ordem muda bastante o resultado de um projeto.
Não gosto da lógica em que o cliente entrega uma lista de telas e funcionalidades e a software house simplesmente estima quantas horas serão necessárias para programar aquilo. Antes precisamos entender como a empresa trabalha, onde está o gargalo, quem vai utilizar a solução, o que já existe, quais sistemas precisam conversar e, principalmente, qual resultado aquela tecnologia precisa produzir.
Às vezes a resposta é um sistema novo. Às vezes é uma integração. Às vezes é automatizar uma parte da operação. E, em alguns casos, a melhor decisão é não desenvolver determinadas coisas.
O segundo ponto é engenharia.
Por ter trabalhado com sistemas em contextos onde disponibilidade, consistência de dados, integrações e evolução são importantes, tenho uma preocupação muito grande com o que acontece depois do "funcionou na demonstração".
Software precisa sobreviver ao mundo real.
Precisa lidar com crescimento de volume, falhas de serviços externos, concorrência, dados inconsistentes, mudanças de regra, versões diferentes, usuários fazendo coisas que ninguém imaginou e sistemas legados que não podem simplesmente ser desligados.
Por isso arquitetura, observabilidade, testes, segurança, contratos entre sistemas e capacidade de evolução não entram como acabamento. Fazem parte da concepção.
E existe um terceiro aspecto que considero importante: responsabilidade ponta a ponta.
Quem participa do entendimento do problema também participa das decisões técnicas. Tentamos evitar aquela cadeia em que comercial entende uma coisa, análise entende outra, desenvolvimento recebe outra e o cliente só descobre a diferença no final.
Nosso objetivo não é ser especialistas em "fazer telas". É entender operações e construir tecnologia que continue fazendo sentido quando entra em produção.
Como você enxerga o mercado de software houses hoje?
Acho que estamos vivendo uma mudança bastante profunda.
Durante muito tempo, capacidade de programação era uma barreira de entrada importante. Você precisava de pessoas especializadas para transformar uma ideia em software.
Essa barreira está diminuindo muito.
Low-code, plataformas prontas e, principalmente, inteligência artificial tornaram muito mais barato produzir código. Isso é positivo, mas também criou uma situação curiosa: ficou mais fácil produzir software e, ao mesmo tempo, ficou mais fácil produzir software ruim em grande velocidade.
É possível construir uma aplicação visualmente convincente muito rápido. O problema começa quando ela precisa virar parte da operação de uma empresa.
Quem responde quando uma integração falha? Como os dados serão migrados? Como lidar com concorrência? Como garantir isolamento entre clientes? Como auditar uma operação financeira? Como atualizar sem quebrar usuários existentes? Como monitorar produção? O que acontece se uma API externa ficar indisponível?
Essas perguntas não aparecem em uma demonstração de cinco minutos.
Por isso acredito que o valor da software house está mudando. O código continua importante, obviamente, mas deixa de ser o principal elemento de diferenciação.
Diagnóstico, engenharia, arquitetura, conhecimento de negócio, integração, segurança e responsabilidade sobre o que foi construído passam a valer mais.
Também acredito que o cliente está ficando mais criterioso. Há muita oferta e muita promessa no mercado. Então portfólio verificável, reputação, capacidade de explicar decisões e transparência sobre limitações tendem a pesar cada vez mais.
Para mim, a software house que se limitar a vender horas de programação vai sofrer cada vez mais pressão por preço. A que conseguir assumir problemas de negócio e transformá-los em sistemas confiáveis continuará tendo muito espaço.
Falando em IA, qual é o papel da software house nesse novo contexto de mercado?
A primeira responsabilidade é não vender IA onde não existe problema para ela resolver.
Existe uma pressão enorme para colocar IA em qualquer produto ou processo. Só que nem todo problema precisa de um modelo de linguagem, um agente ou machine learning. Às vezes uma boa regra de negócio, uma integração ou uma automação convencional é mais barata, mais previsível e mais segura.
Quando IA realmente faz sentido, aí entra uma responsabilidade ainda maior da engenharia.
Porque existe uma diferença enorme entre abrir uma ferramenta, fazer uma demonstração interessante e colocar IA dentro de um processo de negócio que precisa funcionar todos os dias.
Nesse segundo cenário aparecem questões de privacidade, contexto, permissões, qualidade dos dados, rastreabilidade, custo por utilização, comportamento não determinístico, segurança e supervisão humana.
Vejo então a software house ocupando cada vez mais o papel de tradutora entre capacidade tecnológica e problema de negócio.
O cliente não deveria precisar saber qual modelo, framework ou arquitetura de agentes está na moda naquela semana. Ele precisa saber se aquilo reduz custo, elimina trabalho manual, melhora uma decisão, diminui tempo de atendimento ou cria uma capacidade nova para a empresa.
Também acredito que a IA muda a própria economia do desenvolvimento.
Se produzir código fica mais rápido, o cliente não precisa receber três vezes mais código. Ele deveria receber decisões melhores, ciclos menores de validação, mais testes, mais documentação, mais qualidade e mais atenção ao que realmente diferencia o negócio.
Essa é a oportunidade.
Como a sua empresa tem abordado o uso de IA?
Na Maha, estamos usando IA de forma bastante próxima da engenharia, principalmente através de agentes e ferramentas inseridas no próprio processo de desenvolvimento.
Mas existe uma diferença importante na forma como enxergamos isso.
A ideia não é entregar a responsabilidade do projeto para a IA. É aumentar a capacidade do engenheiro.
Eu costumo resumir assim: o engenheiro define, o agente executa.
Arquitetura, padrões, restrições, regras de negócio, critérios de aceite e decisões que envolvem trade-offs continuam sendo responsabilidade humana. O agente recebe contexto e trabalha dentro dessas fronteiras.
Isso muda bastante a qualidade do resultado.
Usamos IA em atividades como investigação de código existente, análise de impacto, documentação, elaboração e revisão de testes, pesquisa técnica, auxílio em refatorações, geração de implementações repetitivas e validação de diferentes alternativas.
Quando trabalhamos com agentes, procuramos fornecer contexto suficiente para que eles não atuem simplesmente a partir de um prompt solto. Repositório, arquitetura, convenções, contratos, invariantes e critérios de validação fazem parte desse contexto.
E existe uma preocupação forte com validação.
Um agente pode produzir código muito rapidamente, mas velocidade sem controle também significa conseguir produzir erro muito rapidamente. Por isso revisão, testes, permissões limitadas e validação das alterações continuam fazendo parte do processo.
Essa visão inclusive virou tema de um trabalho que venho desenvolvendo sobre agentes aplicados à programação: como sair do uso de IA como simples autocomplete ou gerador de código e começar a tratá-la como parte de um processo de engenharia supervisionado.
No desenvolvimento de soluções para clientes seguimos a mesma lógica. Não partimos do pressuposto de que um produto precisa de IA. Primeiro analisamos o problema. Se houver uma aplicação onde IA realmente gere vantagem, desenhamos a solução considerando desde o início integração, dados, segurança, custo e supervisão.
Para nós, IA não é um produto que precisa ser colocado em tudo. É mais uma ferramenta extremamente poderosa dentro da caixa de ferramentas da engenharia.
Como a Softdex tem ajudado a sua empresa?
A relação da Maha com a Softdex ainda é relativamente recente, então prefiro não dizer que a plataforma já se tornou nosso principal canal comercial ou atribuir resultados que ainda estamos construindo.
O impacto mais concreto até aqui tem sido em visibilidade e posicionamento.
Estamos justamente em uma fase de estruturar a Maha de maneira mais forte como empresa, ampliando a presença comercial para além de projetos que chegam por relacionamento e indicação. Nesse contexto, estar em um ambiente específico para software houses, com perfil verificado e possibilidade de ser encontrado por empresas que já estão procurando um fornecedor de tecnologia, é bastante relevante.
Existe também um segundo ponto que considero importante: confiança.
Para quem está contratando software sob medida, avaliar fornecedores é difícil. Site bonito todo mundo consegue fazer. Uma estrutura externa que organize empresas, especialidades, avaliações e processos de verificação ajuda a reduzir um pouco essa assimetria.
A própria visibilidade que a Maha vem recebendo dentro da plataforma e iniciativas como esta entrevista ajudam uma empresa do interior do Paraná a apresentar seu trabalho para um público que dificilmente chegaria até nós apenas por proximidade geográfica.
E acho particularmente interessante o fato de a Softdex também estar produzindo conteúdo sobre o mercado. Não é apenas um catálogo de empresas. Quando a plataforma discute contratação, IA, engenharia e o próprio cenário das software houses brasileiras, ela ajuda também a amadurecer o mercado dos dois lados: quem vende e quem contrata.
Para uma empresa que está entrando em uma nova etapa de crescimento, esse tipo de ecossistema é bastante útil.
Sua software house também quer participar da série de entrevistas? Mantenha o perfil atualizado no diretório da Softdex e fale com a nossa equipe.