Anton Onufriienko, Diretor Geral da Devart – Série de Entrevistas

Anton Onufriienko, Diretor Geral da Devart, é um executivo de tecnologia e operador com experiência profunda em escalonar negócios de software, impulsionar o crescimento de receita e liderar equipes cross-funcionais em larga escala, incluindo SaaS, software empresarial e serviços financeiros. Ao longo de sua carreira, ele progrediu de construir organizações de vendas e lançar startups para supervisionar operações de P&L completas para unidades de negócios importantes, incluindo a maior divisão da Devart, com mais de 130 funcionários. Antes de se tornar Diretor Geral, ele atuou como Diretor de Receita e Chefe de Vendas da Devart, onde liderou a estratégia de go-to-market, transformação de preços e iniciativas de crescimento internacional. Ele também é CEO da TMetric, uma plataforma de rastreamento de tempo e produtividade focada em ajudar empresas orientadas a serviços a obter clareza operacional.

Devart é uma empresa de software especializada em desenvolvimento de banco de dados, conectividade de dados, integração e produtividade para desenvolvedores, DBAs, analistas e equipes empresariais. Fundada em 1997, a empresa é mais conhecida por sua suíte dbForge de ferramentas de gerenciamento de banco de dados, que suporta principais sistemas de banco de dados, incluindo SQL Server, MySQL, Oracle e PostgreSQL. A Devart também desenvolve soluções de conectividade de dados, como conectores ODBC, ADO.NET, Python e Delphi, além da Skyvia, sua plataforma de integração de dados baseada em nuvem para ETL, automação, backup e orquestração de fluxo de trabalho. A empresa atende a mais de 500.000 usuários em todo o mundo, incluindo uma grande parcela de organizações do Fortune 100, e tem se concentrado cada vez mais em integrar capacidades impulsionadas por IA em seus produtos, por meio de ferramentas como o dbForge AI Assistant, que ajuda os desenvolvedores a gerar, otimizar, solucionar problemas e explicar consultas SQL usando linguagem natural.

Você progrediu de construir e liderar equipes de vendas para executar operações de P&L completas e agora gerenciar a maior unidade de negócios da Devart. Como essa jornada moldou sua abordagem para integrar a IA na estratégia de produto e tomada de decisões em larga escala?

As vendas me ensinaram a medir o ROI em tudo. Ao me mudar para um papel de CRO, eu escalei essa disciplina em todas as funções. Ao executar a BU, eu fui forçado a aplicá-la à própria IA.

Eu tenho uma visão prática da IA. Não é que eu seja cético: três de nossas quatro apostas de produto para 2026 são nativas em IA. Mas acredito que o hype atrapalha os resultados reais e duradouros.

Há um meme que circula e resume onde a indústria frequentemente erra. As empresas trocam assinaturas de SaaS de US$ 400 por ferramentas caseiras que custam US$ 1.000 por mês em taxas de API e precisam de reparos constantes. Isso não é uma mudança real, é apenas um show caro.

A lição que eu aprendi nas vendas é simples: toda iniciativa paga seu caminho, ou morre. Eu executo o rollout de IA do mesmo jeito que eu costumava executar um território de vendas. Hipótese de ROI explícita por fluxo de trabalho, rollout em três ondas e impacto documentado antes de escalar.

Nossa métrica estrela é a Receita por Funcionário, e nosso alvo é mais que dobrá-la até o final de 2028. Você não fecha essa lacuna contratando. Você fecha mudando o que o trabalho parece, e a IA é o único mecanismo realista nessa magnitude.

Meu filtro para toda iniciativa de IA, interna ou de produto, é o mesmo: qual é o valor medido, quem paga por isso e como sabemos que funcionou? Qualquer coisa que falhe nessas três perguntas não pertence à produção. O custo de errar nisso se acumula rapidamente, e a maioria das empresas descobrirá isso do jeito caro.

A Devart construiu uma reputação sólida em torno de ferramentas de banco de dados e produtividade de desenvolvedores. Como você está incorporando a IA nesses produtos para entregar valor real em vez de automação de superfície?

Nossos usuários são especialistas técnicos hardcore: DBAs, engenheiros sênior, arquitetos de dados. Eles detectam a automação de superfície em segundos e ressentem-se por serem vendidos brinquedos de marketing disfarçados de inovação. Dois anos atrás, quando o hype de IA atingiu o pico e os concorrentes correram para fixar painéis de chat em todos os elementos de UI, a tentação de seguir foi real. Eu havia visto esse padrão antes, em dispositivos móveis, em nuvem, em low-code, e me recusei a repeti-lo.

A disciplina foi direta: valor do cliente em primeiro lugar. Construir recursos de IA que ninguém pediu, que não entregam valor real, é o pior uso possível de recursos de engenharia finitos. Isso é especialmente verdadeiro quando seu público pode detectar a diferença imediatamente.

O que mudou em 2026 é que a IA se moveu do hype para uma revolução técnica real. A lacuna entre o que esses sistemas podiam fazer em 2023 e o que podem fazer hoje não é incremental. É uma categoria completamente diferente de capacidade. Podemos agora resolver problemas que eram genuinamente insolúveis antes: acesso de dados de empresa seguros para agentes de IA, inteligência de banco de dados contextual dentro do IDE do desenvolvedor e análise de negócios autônoma que não exigem um analista dedicado.

Essas são novas linhas de produtos que existem porque a IA tornou o problema subjacente solúvel. Essa é a barra que nos impomos: um produto de IA real é aquele em que a remoção da camada de IA quebra o produto. A indústria passou dois anos chamando painéis de chat de “produtos de IA”. Esses são recursos, não produtos.

Nós demoramos mais porque queríamos acertar. Os próximos doze meses mostrarão se essa disciplina valeu a pena.

A IA está cada vez mais escrevendo, otimizando e depurando código. Como você vê isso mudando o papel dos desenvolvedores que trabalham com bancos de dados nos próximos anos?

O valor de saber a sintaxe SQL está se depreciando rapidamente. Se a IA pode gerar uma junção de tabela complexa em segundos e identificar índices faltantes a partir de logs em minutos, o valor de um engenheiro não vem mais de digitar SQL. Essa parte do trabalho está se tornando uma commodity.

Mas aqui está a nuance crítica que os evangelistas da automação total sempre pulam. Um erro de IA na interface do usuário é um botão desalinhado que você recarrega. Um erro de IA no banco de dados é um ambiente de produção apagado, uma violação de PII ou um fechamento transacional de todo o negócio.

Bancos de dados mantêm estado. Eles não perdoam alucinações.

Essa assimetria redefine o papel completamente. Nos próximos dois a três anos, os desenvolvedores de banco de dados e DBAs evoluirão de codificadores para arquitetos e auditores. Seu trabalho principal muda para três coisas:

• Projetar arquiteturas confiáveis que a IA não pode raciocinar sozinha, porque falta contexto de negócios.
• Definir limites e políticas de segurança rígidas para agentes de IA que tocam sistemas de produção.
• Revisar e auditar o código gerado por máquinas antes que ele chegue ao banco de dados.

O modelo mental que eu continuo a retornar: os engenheiros gerenciarão exércitos de assistentes de IA. Ferramentas como dbForge terão que evoluir de IDEs tradicionais para centros de comando e auditoria. O trabalho se torna menos sobre escrever SQL manualmente e mais sobre revisar o que a IA gera, validá-lo e impor os limites que a IA não pode cruzar com segurança.

Oportunidade profissional aqui é significativa. Desenvolvedores que se tornam arquitetos e supervisores multiplicarão seu valor de mercado. Eles se tornam a camada indispensável entre a produtividade da IA e a segurança de produção. O prêmio sobre a especialização em banco de dados não some; ele se desloca para cima, em direção ao design, governança e julgamento, que é exatamente onde a IA não pode operar sozinha.

Quais são as principais limitações das ferramentas de IA atuais em gerenciamento de banco de dados hoje e onde você vê os avanços mais significativos vindo?

A IA atual ainda está presa na automação de superfície. Gerar uma consulta SQL básica ou código de boilerplate não é mais impressionante. O problema maior é que a maioria dos sistemas de IA ainda se comporta como datilógrafos cegos, em vez de arquitetos de sistema. Eles podem gerar sintaxe, mas não entendem realmente o ambiente em que estão operando. O avanço real acontece quando a IA começa a raciocinar sobre contexto, dependências, estado e lógica de negócios juntos.

Atualmente, vejo três limitações principais que impedem a IA em ambientes de banco de dados.

Primeiramente, há o problema de contexto. Modelos de linguagem grande podem ver esquemas, DDL e nomes de coluna, mas não entendem realmente planos de execução, fragmentação de índice, padrões de distribuição de dados ou a lógica de negócios por trás dos dados. Sem essa compreensão mais profunda, muitos conselhos de otimização se tornam adivinhação estatística disfarçada de expertise.

Em segundo lugar, há o problema de alucinação, e as empresas têm quase zero tolerância para isso na camada do banco de dados. Uma junção alucinada pode desacelerar sistemas de produção. Uma atualização errada pode apagar registros críticos. Nesse nível, mesmo falhas de precisão pequenas se tornam extremamente caras muito rapidamente.

O terceiro problema é segurança e governança. Nenhuma empresa séria vai colar esquemas de produção ou PII em uma ferramenta de IA pública sem garantias fortes em torno de isolamento de dados e controle. Até que os fornecedores resolvam isso adequadamente, a adoção de IA em setores regulamentados permanecerá limitada.

Os avanços significativos virão quando a IA se mover além da geração de sintaxe e começar a funcionar mais como um arquiteto de fundo ou analista.

Uma parte disso é a camada semântica: mover-se de nomes de tabela brutos para significado de negócios real. Não apenas “tabela_usuários”, mas entender conceitos como coortes de clientes, risco de churn, ou tendências de LTV do trimestre 3.

Outra mudança é a IA agindo mais como um DBA sênior em segundo plano. Analisando continuamente cargas de trabalho, identificando gargalos, sugerindo índices, detectando consultas de risco e capturando problemas antes que os sistemas falhem.

Então você tem operações de máquina para máquina, onde agentes autônomos monitoram a carga do banco de dados, testam estratégias de otimização em ambientes isolados e implantam melhorias sob supervisão humana.

Esses são os desenvolvimentos que moldarão os próximos cinco anos de ferramentas de banco de dados.

Com o aumento do desenvolvimento assistido por IA e ferramentas de não-código, estamos nos movendo em direção a um futuro em que o gerenciamento de banco de dados se torna acessível a usuários não técnicos?

Há uma confusão perigosa na indústria agora. As pessoas tratam um banco de dados de projeto lateral e um banco de dados de legado empresarial como se fossem a mesma coisa. Eles não são.

Para projetos verdes pequenos, a democratização já está aqui. Eu pessoalmente construí aplicativos pequenos do zero sem habilidades profundas de gerenciamento de banco de dados. Se todo o seu esquema cabe dentro da janela de contexto de um LLM, a IA funciona como magia. Desenvolvedores cidadãos que constroem ferramentas internas em pequena escala serão uma categoria real e em crescimento.

A realidade empresarial é completamente diferente. Bancos de dados de legado maciços enfrentam o mesmo problema que os monólitos de código: a parede de contexto. Você não pode caber quinze anos de evolução de esquema não documentada, dependências entre bancos de dados e lógica de gatilho personalizada em um prompt. Quando a IA perde o contexto em um banco de dados grande, as alucinações não se deterioram de forma graciosa. Elas se multiplicam exponencialmente.

O risco que é subdiscutido é a confiança falsa em escala. Interfaces de linguagem natural são únicas para produzir respostas plausíveis, mas sutilmente erradas. Se uma consulta SQL tem um erro de sintaxe, você obtém uma mensagem de erro. Se uma interface de linguagem natural interpreta mal “clientes ativos” porque seus dados têm seis definições diferentes de atividade, você obtém um número. O número parece bom. Pode estar errado em 30%. O usuário não tem como saber.

Então, não, o gerenciamento de banco de dados empresarial não está se tornando um playground para usuários não técnicos.

O DBA cidadão é um mito em escala.

O futuro pertence a arquitetos de dados especializados que usam ferramentas profissionais para pontuar a lacuna de contexto e construir infraestrutura que permita que a IA opere com segurança em cima.

A solução estrutural é a camada semântica: um vocabulário controlado onde definições de negócios são fixadas uma vez e reutilizadas em todas as interações de IA. Essa é a arquitetura central que estamos construindo no Insightis. Sem isso, a acessibilidade se torna uma responsabilidade.

Olhando para o futuro, como uma “ferramenta de desenvolvedor nativa em IA” parece, e como as equipes devem começar a se preparar para essa mudança hoje?

Uma ferramenta de desenvolvedor nativa em IA não é um chatbot fixado em um IDE. A maioria do que é comercializado como “nativo em IA” hoje é uma interface de chat mais um modelo de autocompletar. Isso é básico, não o destino.

Para mim, uma ferramenta de desenvolvedor genuinamente nativa em IA precisa de três coisas.

Primeiramente, a IA precisa de contexto profundo. Ela precisa entender seu código-fonte, sua infraestrutura, suas decisões históricas e seu ambiente de dados continuamente, não apenas por meio de prompts colados em uma janela de chat. A maioria das ferramentas atuais falha nesse teste. Seu contexto é reiniciado a cada sessão, e o usuário paga o custo de reconstruí-lo constantemente.

Em segundo lugar, as próprias ferramentas precisam se comunicar adequadamente entre si. Seu IDE deve falar com seu banco de dados, o banco de dados com sua pilha de observabilidade, e o CI/CD com sua revisora de IA, etc. O Protocolo de Contexto de Modelo está se tornando a camada padrão aqui, com 97 milhões de downloads de SDK por mês no primeiro trimestre de 2026, subindo de 100.000 no final de 2024. Isso é uma curva de adoção mais acentuada do que qualquer outra que eu já vi em infraestrutura de desenvolvedor.

Terceiramente, a IA de produção em nível de produção exige guardrails de segurança sérios. Visualização de raio de explosão antes de operações destrutivas. Análise de dependência. Planos de rollback automatizados. Registros de auditoria por padrão. A IA sem isso é boa para protótipos e perigosa em produção.

Como se preparar, concretamente.

Audite sua pilha contra esses três componentes. Cada ferramenta expõe APIs e MCP? Ela fala com os outros, ou fica em um silo? Ela tem controles de segurança? Ferramentas que falham em dois dos três são ativos de curto prazo.

Construa infraestrutura de contexto agora. Documente esquemas, definições de negócios e decisões arquitetônicas em formatos legíveis por máquina. Contexto rico não é construído em um trimestre. As equipes cuja IA o tem em 2027 são as que estão documentando hoje.

Execute a IA em produção antes que você pense que está pronto. Equipes que esperam por uma estratégia de IA formal antes de enviar estarão dezoito meses atrás das equipes que já estão aprendendo com falhas de produção reais. Escolha um caso de uso de baixo risco. Envie. Construa o músculo.

As equipes que tomam essas decisões hoje definirão a próxima década de como o software é construído. A janela é estreita, e está aberta agora.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Devart.