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 grandes equipes multifuncionais em 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 da Devart e Chefe de Vendas, 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 acompanhamento 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 (ORCL ) e PostgreSQL. A Devart também desenvolve soluções de conectividade de dados, como conectores ODBC, ADO.NET, Python e Delphi, além do 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, como a 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 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. Executar a BU me forçou 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 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 a implantação 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 disso se multiplica 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êniores, 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. Há dois anos, quando o hype de IA atingiu o pico e os concorrentes correram para fixar painéis de chat em todos os elementos da interface do usuário, 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 sua audiência pode detectar a diferença imediatamente.

O que mudou em 2026 é que a IA mudou 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 de capacidade completamente diferente. Agora podemos 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 da IDE do desenvolvedor e análise de negócios autônoma que não exigem um analista dedicado.

Esses 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 onde remover a 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.

Levamos mais tempo 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 do fato 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ê pode refazer. Um erro de IA no banco de dados é um ambiente de produção apagado, uma violação de PII ou uma paralisação transacional de toda a empresa.

Bancos de dados contê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 possa raciocinar sozinha, porque falta contexto de negócios.
• Definir guardrails e políticas de segurança rigorosas 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 retorno é: 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.

A oportunidade profissional aqui é significativa. Desenvolvedores que se atualizam para arquitetura e supervisão multiplicarão seu valor de mercado. Eles se tornarão a camada indispensável entre a produtividade da IA e a segurança da produção. O prêmio sobre a expertise de 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 maiores limitações das ferramentas de IA atuais no gerenciamento de banco de dados e onde você vê as principais quebras?

A IA atual ainda está presa na automação de superfície. Gerar uma consulta SQL básica ou código de modelo 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 sistemas. Eles podem gerar sintaxe, mas não entendem realmente o ambiente em que estão operando. A quebra 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.

Primeiro, 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, muitas dicas 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 indústrias regulamentadas permanecerá limitada.

As quebras significativas acontecerão quando a IA mudar de geração de sintaxe para funcionar mais como um arquiteto de fundo ou analista.

Uma parte disso é a camada semântica: mudar 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 agir mais como um DBA sênior em segundo plano. Analisando continuamente cargas de trabalho, identificando gargalos, sugerindo índices, detectando consultas de risco e pegando 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.

Essas são as evoluções que moldarão os próximos cinco anos de ferramentas de banco de dados.

Com base em sua experiência liderando receita e estratégia de entrada no mercado, como a IA está reformulando os modelos de preços, o empacotamento de produtos e a aquisição de clientes nas empresas de software?

O manual tradicional de entrada no mercado está quebrado. Vemos isso em nossos próprios números e em toda a categoria de ferramentas para desenvolvedores.

O fim da aquisição clássica. Apesar de melhorias significativas nas posições de busca de nossos produtos em 2026, estamos enfrentando a realidade do clique zero. A busca por IA entrega respostas diretamente na página de resultados e priva os sites de tráfego. Boas posições já não se traduzem em leads como acontecia até dois anos atrás.

Há cinco anos, uma estratégia de conteúdo sólida bastava para impulsionar o crescimento. Hoje, isso é apenas o requisito básico. Os LLMs ponderam a força da marca, as menções positivas e a densidade da comunidade ao formular respostas. Se sua marca não é visível e confiável, os sistemas de IA deixam de apresentá-la de forma consistente. Você não perde apenas tráfego: desaparece completamente da jornada de compra. Para piorar, todo o mercado entrou em pânico e correu para os anúncios pagos, elevando os CPCs a níveis absurdos e destruindo silenciosamente a economia unitária da maioria das empresas SaaS.

Essa mudança atinge de forma especialmente dura as empresas tradicionais de ferramentas para desenvolvedores. Os canais de aquisição orientados por SEO que financiaram uma geração de SaaS B2B estão perdendo eficiência rapidamente. Quem ainda depende deles como principal alavanca de crescimento precisa construir alternativas agora: distribuição por ecossistemas, comunidade e parcerias.

Evolução dos preços: de licenças por usuário ao PLG 3.0. Estamos entrando na próxima fase do crescimento liderado pelo produto. O preço por usuário começa a deixar de funcionar quando um agente de IA pode realizar o trabalho de vários funcionários. Nesse ambiente, cobrar por número de pessoas deixa de fazer sentido. As empresas que não reempacotarem seus produtos em torno do valor, em vez do número de usuários, verão sua receita recorrente mensal despencar nos próximos 24 meses.

O passo seguinte é o PLG 3.0: o momento em que um agente autônomo de IA, e não uma pessoa, avalia, testa e compra software empresarial. A adoção em massa desse padrão ainda está a alguns anos de distância, mas projetar produtos e preços para o comprador máquina é uma tarefa de 2026, não de 2028.

Muitas organizações têm dificuldade para passar da experimentação com IA ao impacto real em produção. Quais são os principais fatores que determinam se as iniciativas de IA realmente terão sucesso?

A maioria dos recursos de IA fracassa antes mesmo de ser construída. O fracasso acontece na sala em que alguém diz “precisamos de IA neste produto”, não porque os usuários pediram, mas porque o conselho quer uma história sobre IA ou o marketing acha que isso atrairá um novo público. Esse é o pecado original da maioria das iniciativas de IA e molda tudo o que vem depois.

Continuo vendo os mesmos erros se repetirem nas empresas que não conseguem levar a IA da experimentação ao impacto real em produção.

O primeiro erro é criar recursos de IA que ninguém pediu. Quando um recurso de IA é imposto sem uma necessidade genuína do usuário, a equipe parte da tecnologia e trabalha de trás para frente para inventar um caso de uso. O resultado é previsível: um painel de chat anexado à interface existente, um preenchimento automático que atrapalha, um botão “resumir” que produz algo pior do que o próprio usuário escreveria. Esses recursos são lançados, ganham um comunicado à imprensa e silenciosamente ficam abaixo de todas as previsões de adoção. O dano mais profundo é que consomem capacidade de engenharia que deveria ter sido dedicada aos recursos realmente solicitados pelos usuários.

O segundo problema é que as equipes subestimam enormemente a diferença entre dados limpos de demonstração e dados reais de produção. Demonstrações de IA usam exemplos limpos e selecionados. A produção usa a bagunça real dos dados dos clientes: duplicatas, campos ausentes, dez grafias diferentes para o mesmo produto e quinze anos de casos extremos legados. Um modelo com ótima precisão na avaliação pode se degradar gravemente com dados reais, e a maioria das equipes só descobre isso quando os usuários reclamam. O custo dessa descoberta para a confiança no produto raramente é recuperável.

Outro ponto comum de fracasso é a pesquisa com usuários. Entrevistas convencionais de produto não funcionam para recursos de IA. Os usuários não conseguem dizer o que querem da IA porque não sabem o que é possível. Perguntar “você usaria IA para fazer X?” produz respostas educadas e afirmativas sem qualquer valor preditivo para a adoção. Uma pesquisa eficaz de produto com IA exige mostrar protótipos, observar o uso real e medir se as pessoas retornam depois que a novidade passa. Poucas equipes de produto reformularam suas práticas de pesquisa para isso. Ainda aplicam métodos de 2019 a problemas de 2026.

Por fim, muitas empresas medem a atividade da IA em vez do impacto nos negócios. “Duzentas pessoas usaram o recurso de IA esta semana” é uma métrica de adoção, não de impacto. Impacto real significa redução do tempo de ciclo, melhoria da qualidade, geração de receita ou eliminação de custos. Se você não consegue traçar uma linha direta entre o recurso de IA e um número no demonstrativo de resultados, não existe impacto em produção; existe uma atividade cara.

Há um quinto fator que se torna cada vez mais importante e que a maioria das equipes de produto ignora completamente.

Conformidade e o caminho de desenvolvimento sem IA. Uma parcela significativa dos usuários empresariais em finanças, saúde, governo, defesa e direito trabalha sob políticas que proíbem ou restringem recursos de IA em softwares de fornecedores. Se o produto acopla a IA rigidamente à experiência principal, sem uma forma de desativá-la ou contorná-la, acrescentar IA não amplia seu público: elimina um segmento dos clientes atuais.

É exatamente esse problema que estamos resolvendo com o AI Connectivity. As equipes de conformidade de setores regulamentados não se opõem à IA em si; elas se opõem à saída dos dados de seu perímetro. A solução não é remover a IA, mas oferecer a essas organizações uma arquitetura de IA compatível com suas restrições. Por isso o AI Connectivity é instalado localmente: a capacidade de IA permanece, os dados nunca deixam a infraestrutura do cliente e a compra passa na revisão já na primeira rodada, em vez da terceira.

As equipes que acertam projetam para a conformidade desde o primeiro dia. As que erram só descobrem o problema durante a análise de aquisição, quando o negócio já foi perdido.

A Devart atua em diversos ecossistemas de bancos de dados. Como a IA pode ajudar a simplificar a crescente complexidade da gestão de dados em diferentes plataformas?

O problema é real. Uma empresa típica da Fortune 500 opera simultaneamente de oito a doze mecanismos de banco de dados: Oracle legado para finanças, PostgreSQL para novos serviços, SQL Server para operações, Snowflake ou BigQuery para análise e, cada vez mais, um banco vetorial para embeddings. Cada um tem seu próprio dialeto, suas próprias ferramentas e seu próprio regime de governança. Um desenvolvedor que entra nesse ambiente pode passar três meses apenas aprendendo onde os dados estão e quem tem permissão para tocá-los.

A IA não resolve essa complexidade sozinha. Ela amplifica o contexto que recebe. Oito bancos desconectados e sem metadados unificados produzem oito conjuntos desconectados de sugestões superficiais. É exatamente esse padrão de fracasso que vemos na maioria das implantações empresariais de IA.

A oportunidade está em uma camada de contexto entre os agentes de IA e os bancos de dados subjacentes. Uma camada que converse com todos eles, normalize metadados, aplique políticas de governança unificadas e exponha uma interface MCP limpa, para que qualquer agente de IA — Claude, GPT ou um modelo interno — trabalhe em todo o ambiente sob regras consistentes.

Essa é a arquitetura que estamos construindo com o AI Connectivity: um servidor MCP local com suporte a vários bancos, uma camada semântica que registra as definições de negócio uma única vez em vez de obrigar cada agente de IA a reaprendê-las, controle de acesso baseado em funções no nível das operações SQL e logs de auditoria completos.

A simplificação não é gratuita. Alguém ainda precisa modelar a camada semântica e definir as políticas. Mas esse trabalho é realizado uma vez, não repetidamente para cada novo agente de IA.

Você liderou grandes equipes multifuncionais. Como a IA está mudando a colaboração interna e a tomada de decisões entre produto, engenharia, marketing e vendas?

Grande parte do atrito entre funções era, na verdade, pessoas esperando informações de outras equipes. A IA elimina esse atrito mais depressa do que qualquer estrutura de gestão jamais conseguiu.

As mudanças são práticas e imediatas.

Em produto e engenharia: um gerente de produto faz uma pergunta sobre o banco em linguagem de negócios — “qual é a variação do LTV entre nossos três principais níveis de preço?” — e recebe uma resposta utilizável na hora, em vez de abrir um chamado no Jira para análise e esperar três dias.

Em marketing e dados: a análise de coortes acontece no próprio fluxo, não em uma fila de solicitações. O gerente de marketing pergunta, recebe os números e monta a campanha, tudo na mesma manhã.

Em vendas e engenharia: respostas técnicas para potenciais clientes já não exigem agendar uma chamada com um engenheiro sênior. O representante de vendas recebe uma resposta técnica confiável em tempo real e o ciclo do negócio encurta.

As decisões passam a acontecer durante a conversa, e não no acompanhamento posterior. O padrão “vou verificar esse número e volto depois” está desaparecendo. As reuniões encurtam porque a IA cuida das leituras prévias e dos resumos que antes consumiam a primeira metade de cada sessão.

Esse desaparecimento do atrito força uma mudança de gestão mais profunda — justamente aquela que a maioria das equipes de liderança subestima.

Toda empresa afirma ser orientada a resultados. Quando se olha por dentro, a maioria ainda opera com métricas substitutas: pontos de história, linhas de código, chamados encerrados, horas registradas. Usávamos a atividade como substituta do valor porque o valor real era difícil de medir. A IA rompe esse substituto para sempre. Quando um agente pode escrever 10.000 linhas de código ou encerrar 500 chamados de suporte em um minuto, medir atividade se torna perigosamente enganoso.

Estamos migrando explicitamente para a Gestão Verdadeiramente Orientada a Resultados, na qual o desempenho é medido estritamente pelo resultado e pelo julgamento. Na prática é duro, porque a maioria dos sistemas de desempenho não foi construída para isso. Pessoas que antes se escondiam atrás de muita atividade tornam-se imediatamente visíveis, e a liderança precisa estar disposta a agir diante dessa visibilidade.

A consequência estrutural são organogramas mais horizontais. As camadas de coordenação e encaminhamento de informações encolhem. As organizações que se adaptarem mais rapidamente operarão, por estrutura, com menos pessoas e maior alavancagem.

Com a ascensão 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 pequenos projetos verdes, a democratização já está aqui. Eu pessoalmente construí aplicações pequenas 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 mágica. Desenvolvedores cidadãos construindo 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 código-fonte monolítico: 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 grande banco de dados, as alucinações não se degradam de forma graciosa. Elas se multiplicam exponencialmente.

O risco que é subdiscutido é a confiança falsa em escala. Interfaces de linguagem natural são únicas em 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 correçã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.

Primeiro, 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 entre si adequadamente. Seu IDE deve conversar com seu banco de dados, o banco de dados com sua pilha de observabilidade, e o CI/CD com seu revisor 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. Essa é a curva de adoção mais acentuada que eu já vi em infraestrutura de desenvolvedor.

Terceiro, a IA 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. 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 arquiteturais 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 documentam hoje.

Execute a IA em produção antes de pensar que está pronto. Equipes que esperam uma estratégia de IA formal antes de implantar 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. Implantar. Construir 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.