Anton Onufriienko, Director Ejecutivo en Devart – Serie de Entrevistas

Anton Onufriienko, Director Ejecutivo en Devart, es un ejecutivo y operador de tecnología con experiencia profunda en el escalado de negocios de software, el crecimiento de ingresos y el liderazgo de equipos grandes y multifuncionales en SaaS, software empresarial y servicios financieros. A lo largo de su carrera, ha progresado desde la construcción de organizaciones de ventas y el lanzamiento de startups hasta la supervisión de operaciones de P&L completas para unidades de negocio importantes, incluida la división más grande de Devart con más de 130 empleados. Antes de convertirse en Director Ejecutivo, se desempeñó como Director de Ingresos de Devart y Jefe de Ventas, donde lideró la estrategia de go-to-market, la transformación de precios y las iniciativas de crecimiento internacional. También es CEO de TMetric, una plataforma de seguimiento de tiempo y rentabilidad enfocada en ayudar a las empresas impulsadas por servicios a obtener claridad operativa.

Devart es una empresa de software especializada en el desarrollo de bases de datos, la conectividad de datos, la integración y las herramientas de productividad para desarrolladores, administradores de bases de datos, analistas y equipos empresariales. Fundada en 1997, la empresa es más conocida por su suite de herramientas de gestión de bases de datos dbForge, que admite sistemas de bases de datos importantes como SQL Server, MySQL, Oracle (ORCL ) y PostgreSQL. Devart también desarrolla soluciones de conectividad de datos como ODBC, ADO.NET, Python y Delphi, junto con Skyvia, su plataforma de integración de datos en la nube sin código para ETL, automatización, copia de seguridad y orquestación de flujos de trabajo. La empresa atiende a más de 500.000 usuarios en todo el mundo, incluida una gran parte de las organizaciones Fortune 100, y se ha centrado cada vez más en integrar capacidades impulsadas por IA en sus productos a través de herramientas como dbForge AI Assistant, que ayuda a los desarrolladores a generar, optimizar, depurar y explicar consultas SQL utilizando lenguaje natural.

Ha progresado desde la construcción y el liderazgo de equipos de ventas hasta la gestión de operaciones de P&L completas y ahora la gestión de la unidad de negocio más grande de Devart. ¿Cómo ha moldeado su enfoque para integrar la IA en la estrategia de productos y la toma de decisiones a gran escala?

Las ventas me enseñaron a medir el ROI en todo. Al pasar a un papel de CRO, escalé esa disciplina en todas las funciones. Dirigir la BU me obligó a aplicarla a la IA en sí.

Tengo una visión práctica de la IA. No es que dude de ella: tres de nuestras cuatro apuestas de productos para 2026 son nativas de IA. Pero creo que el hype se interpone en el camino de los resultados reales y duraderos.

Hay un meme que circula que resume dónde la industria a menudo se equivoca. Las empresas intercambian suscripciones de SaaS de $400 por herramientas de código abierto que cuestan $1,000 al mes en tarifas de API y necesitan reparaciones constantes. Eso no es un cambio real, es solo un espectáculo costoso.

La lección que aprendí en las ventas es simple: cada iniciativa paga su camino, o muere. Dirijo nuestra implementación de IA de la misma manera que solía dirigir un territorio de ventas. Hipótesis de ROI explícita por flujo de trabajo, una implementación en tres fases y un impacto documentado antes de escalar.

Nuestro indicador clave es el Ingreso por Empleado, y nuestro objetivo es más que duplicarlo para finales de 2028. No se cierra esa brecha contratando. Se cierra cambiando la forma en que se hace el trabajo, y la IA es el único mecanismo realista a esa magnitud.

Mi filtro para cada iniciativa de IA, interna o de producto, es el mismo: ¿cuál es el valor medido, quién paga por ello y cómo sabemos que funcionó? Cualquier cosa que falle en esas tres preguntas no pertenece a la producción. El costo de equivocarse se acumula rápidamente, y la mayoría de las empresas descubrirán que de la manera más costosa.

Devart ha construido una sólida reputación en torno a las herramientas de bases de datos y la productividad de los desarrolladores. ¿Cómo está incorporando la IA en estos productos para ofrecer un valor real en lugar de una automatización de superficie?

Nuestros usuarios son especialistas técnicos especializados: administradores de bases de datos, ingenieros senior, arquitectos de datos. Detectan la automatización de superficie en segundos y se sienten ofendidos por ser vendidos juguetes de marketing disfrazados de innovación. Hace dos años, cuando el hype de la IA alcanzó su punto máximo y los competidores se apresuraron a agregar paneles de chat a cada elemento de la interfaz de usuario, la tentación de seguirles fue real. Había visto ese patrón antes, en móviles, en la nube, en código de bajo nivel, y me negué a repetirlo.

La disciplina fue directa: valor para el cliente en primer lugar. Construir funciones de IA que nadie solicitó, que no entregan un valor real, es el peor uso posible de recursos de ingeniería finitos. Eso es especialmente cierto cuando su audiencia puede detectar la diferencia de inmediato.

Lo que cambió en 2026 es que la IA pasó del hype a una revolución técnica real. La brecha entre lo que estos sistemas podían hacer en 2023 y lo que pueden hacer hoy no es incremental. Es una categoría completamente diferente de capacidad. Ahora podemos resolver problemas que eran genuinamente insolubles antes: acceso seguro a datos empresariales para agentes de IA, inteligencia contextual de bases de datos dentro del IDE del desarrollador y análisis empresariales autónomos que no requieren un analista dedicado.

Estos son nuevos productos que existen porque la IA hizo que el problema subyacente sea soluble. Esa es la barra a la que nos ceñimos: un producto de IA real es aquel en el que eliminar la capa de IA rompe el producto. La industria ha pasado dos años llamando a los paneles de chat “productos de IA”. Esas son características, no productos.

Nos tomó más tiempo porque queríamos hacerlo bien. Los próximos doce meses mostrarán si esa disciplina dio resultado.

La IA está escribiendo, optimizando y depurando código cada vez más. ¿Cómo ve el cambio del papel de los desarrolladores que trabajan con bases de datos en los próximos años?

El valor de conocer la sintaxis SQL se deprecia rápidamente. Si la IA puede generar una JOIN de tabla múltiple compleja en segundos e identificar índices faltantes en los registros en minutos, el valor de un ingeniero ya no proviene de escribir SQL. Esa parte del trabajo se está convirtiendo en una commodity.

Pero aquí está la nuance crítica que los evangelistas de la automatización total siempre omiten. Un error de IA en el frontend es un botón mal alineado que se actualiza. Un error de IA en la base de datos es un entorno de producción eliminado, una filtración de PII o un cierre transaccional de todo el negocio.

Las bases de datos contienen estado. No perdonan alucinaciones.

Esa asimetría redefine el papel por completo. En los próximos dos o tres años, los desarrolladores de bases de datos y los administradores de bases de datos evolucionarán de codificadores a arquitectos y auditores. Su trabajo principal se desplaza a tres cosas:

• Diseñar arquitecturas confiables que la IA no pueda razonar por sí sola, porque carece de contexto empresarial.
• Establecer guardias y políticas de seguridad duras para los agentes de IA que tocan sistemas de producción.
• Revisar y auditar el código que las máquinas generan antes de que llegue a la base de datos.

El modelo mental al que siempre regreso es el siguiente: los ingenieros gestionarán ejércitos de asistentes de IA. Herramientas como dbForge tendrán que evolucionar desde IDE tradicionales hasta centros de comando y auditoría. El trabajo se convierte menos en escribir SQL manualmente y más en revisar lo que genera la IA, validar y hacer cumplir los límites que la IA no puede cruzar de manera segura.

La oportunidad profesional aquí es significativa. Los desarrolladores que mejoran a arquitectura y supervisión multiplicarán su valor en el mercado. Se convierten en la capa indispensable entre la productividad de la IA y la seguridad de la producción. El valor agregado de la experiencia en bases de datos no desaparece; se desplaza hacia arriba hacia el diseño, la gobernanza y el juicio, que es exactamente donde la IA no puede operar sola.

¿Cuáles son las limitaciones más grandes de las herramientas de IA actuales en la gestión de bases de datos hoy en día, y dónde ve los avances más significativos en el futuro?

La IA actual todavía se encuentra en la automatización de superficie. Generar una consulta SQL básica o código de plantilla ya no es impresionante. El problema más grande es que la mayoría de los sistemas de IA todavía se comportan como mecanógrafos ciegos en lugar de arquitectos de sistemas. Pueden generar sintaxis, pero no entienden realmente el entorno en el que operan. El avance real ocurre cuando la IA comienza a razonar sobre el contexto, las dependencias, el estado y la lógica empresarial juntos.

Actualmente, veo tres limitaciones importantes que frenan a la IA en entornos de bases de datos.

Primero, hay un problema de contexto. Los grandes modelos de lenguaje pueden ver esquemas, DDL y nombres de columnas, pero no entienden realmente los planes de ejecución, la fragmentación de índices, los patrones de distribución de datos o la lógica empresarial subyacente. Sin esa comprensión más profunda, gran parte de los consejos de optimización se convierte en adivinanzas estadísticas disfrazadas de experiencia.

En segundo lugar, está el problema de las alucinaciones, y las empresas tienen casi cero tolerancia para ello en la capa de la base de datos. Una JOIN alucinada puede ralentizar los sistemas de producción. Un UPDATE incorrecto puede eliminar registros críticos. A ese nivel, incluso los pequeños fallos de precisión se vuelven extremadamente costosos muy rápidamente.

El tercer problema es la seguridad y la gobernanza. Ninguna empresa seria va a pegar esquemas de producción o PII en una herramienta de IA pública sin garantías sólidas sobre el aislamiento de datos y el control. Hasta que los proveedores resuelvan esto adecuadamente, la adopción de la IA en industrias reguladas permanecerá limitada.

Los avances significativos ocurrirán cuando la IA se mueva más allá de la generación de sintaxis y comience a funcionar más como un arquitecto de fondo o un analista.

Una parte de eso es la capa semántica: moverse de nombres de tablas crudos a significado empresarial real. No solo “tabla_usuarios”, sino comprender conceptos como cohortes de clientes, riesgo de abandono, tendencias de LTV del trimestre 3.

Otro cambio es que la IA actúa más como un administrador de bases de datos senior en segundo plano. Analiza continuamente las cargas de trabajo, identifica cuellos de botella, sugiere índices, detecta consultas de riesgo y atrapa problemas antes de que los sistemas fallen.

Luego está la operación entre máquinas, donde los agentes autónomos monitorean la carga de la base de datos, prueban estrategias de optimización en entornos aislados y despliegan mejoras bajo supervisión humana.

Esos son los desarrollos que darán forma a los próximos cinco años de herramientas de bases de datos.

Desde su experiencia en el liderazgo de ingresos y estrategia de go-to-market, ¿cómo está cambiando la IA los modelos de precios, el embalaje de productos y la adquisición de clientes en las empresas de software?

La guía de go-to-market tradicional está rota. La vemos en nuestros propios números y en toda la categoría de herramientas de desarrollo.

La muerte de la adquisición clásica. A pesar de las mejoras significativas en los rankings de búsqueda en nuestros productos en 2026, estamos golpeando la realidad de los resultados de búsqueda sin clics. La búsqueda de IA entrega respuestas directamente en la página de resultados y priva a los sitios web de tráfico. Los rankings fuertes ya no se traducen en leads de la manera que lo hacían incluso hace dos años.

Hace cinco años, una sólida estrategia de contenido era suficiente para impulsar el crecimiento. Hoy es un requisito previo. Los LLMs ponderan la fuerza de la marca, las menciones positivas y la densidad de la comunidad al formar respuestas. Si su marca no es visible y de confianza, los sistemas de IA dejan de presentarla consistentemente. No solo pierde tráfico. Desaparece por completo del viaje de compra.

Este cambio está golpeando particularmente duro a las empresas de herramientas de desarrollo tradicionales. Los canales de adquisición impulsados por SEO que financiaron una generación de SaaS B2B están perdiendo eficiencia rápidamente. Cualquiera que aún dependa de ellos como palanca de crecimiento principal necesita estar construyendo activamente alternativas en este momento: distribución de ecosistemas, comunidad y asociaciones.

La evolución de los precios: de asientos a PLG 3.0. Estamos entrando en la próxima fase de PLG. El precio por asiento comienza a romperse cuando un agente de IA puede hacer el trabajo de varios empleados. En ese entorno, cobrar por cabeza deja de tener sentido. Las empresas que no reempaquen los productos en torno al valor en lugar de la cantidad de cabezas perderán MRR en los próximos 24 meses.

El siguiente paso es PLG 3.0: el momento en que un agente de IA autónomo, y no un ser humano, evalúa, prueba y compra software empresarial. La adopción masiva de ese patrón todavía está a unos años, pero arquitectar productos y precios para el comprador de máquina es una tarea de 2026, no de 2028.

Muchas organizaciones luchan por pasar de la experimentación con la IA a un impacto real en la producción. ¿Cuáles son los factores clave que determinan si las iniciativas de IA realmente tienen éxito?

La mayoría de las características de IA fallan antes de que se construyan. Fallan en la sala donde alguien dice “necesitamos IA en este producto”, no porque los usuarios lo solicitaron, sino porque la junta directiva quiere una historia de IA o el marketing cree que atraerá a una nueva audiencia. Ese es el pecado original de la mayoría de las iniciativas de IA, y da forma a todo lo que sigue.

Sigo viendo los mismos errores repetidos en las empresas que luchan por mover la IA de la experimentación a un impacto real en la producción.

El primer error es construir características de IA que nadie solicitó realmente. Una vez que una característica de IA se ordena sin una necesidad genuina del usuario, el equipo trabaja hacia atrás desde la tecnología para inventar un caso de uso. El resultado es predecible: un panel de chat agregado a una interfaz de usuario existente, un autocompletar que se interpone en el camino, un botón “resumir” que produce una salida peor que la que el usuario podría escribir él mismo. Estas características se envían, reciben un comunicado de prensa y quedan en silencio con un desempeño inferior a todas las previsiones de adopción. El daño más profundo es que consumen capacidad de ingeniería que debería haber ido a características que los usuarios realmente solicitaron.

El segundo problema es que los equipos subestiman enormemente la diferencia entre los datos de demostración limpios y los datos de producción reales. Los demos de IA se ejecutan en ejemplos limpios y curados. La producción se ejecuta en el verdadero desorden de los datos del cliente: duplicados, campos faltantes, diez maneras diferentes de deletrear el mismo nombre de producto, quince años de casos de borde de legado. Un modelo que logra una precisión impresionante en la evaluación puede degradarse severamente en datos en vivo, y la mayoría de los equipos no descubren esto hasta que los usuarios se quejan. El costo de ese descubrimiento en la confianza de la producción rara vez se recupera.

Otro punto de fallo común es la investigación de usuarios. Las entrevistas de productos estándar no funcionan para las características de IA. Los usuarios no pueden articular lo que quieren de la IA porque no saben qué es posible. Preguntar “¿usarías IA para hacer X?” obtiene respuestas de sí educadas que no tienen valor predictivo para la adopción. La investigación de productos de IA efectiva requiere mostrar prototipos, observar el uso real y medir si los usuarios regresan después de que la novedad se desvanece. Pocos equipos de productos han reconstruido su práctica de investigación para esto. Todavía están ejecutando la guía de 2019 para problemas de 2026.

Y, finalmente, muchas empresas miden la actividad de la IA en lugar del impacto empresarial. “Doscientas personas usaron la característica de IA esta semana” es un métrico de adopción, no un métrico de impacto. El impacto real es el tiempo de ciclo reducido, la calidad mejorada, los ingresos generados o el costo eliminado. Si no puede dibujar una línea recta desde la característica de IA hasta un número en el P&L, no tiene un impacto en la producción. Tiene una actividad costosa.

Hay un quinto factor que se está volviendo cada vez más crítico y que la mayoría de los equipos de productos pasan por alto por completo.

La conformidad y el camino de construcción sin IA. Una participación significativa de los usuarios empresariales en finanzas, atención médica, gobierno, defensa y derecho operan bajo políticas que prohíben o restringen las características de IA en el software de los proveedores. Si su producto acopla duramente la IA en la experiencia central sin una forma de deshabilitarla o evitarla, no expande su audiencia al agregar la IA. Pierde un segmento de su audiencia existente.

Este es exactamente el problema que estamos resolviendo con la Conectividad de IA. Los equipos de cumplimiento en las industrias reguladas no se oponen a la IA en sí. Se oponen a que los datos salgan de su perímetro. La solución no es quitar la IA; es dar a esas organizaciones una arquitectura de IA que se adapte a sus restricciones. Eso es por lo que la Conectividad de IA se envía como local: la capacidad de IA permanece, los datos nunca dejan la infraestructura del cliente y la adquisición pasa la revisión en la primera ronda en lugar de la tercera.

Los equipos que lo hacen bien arquitectan para la conformidad desde el día uno. Los equipos que lo hacen mal descubren el problema durante la revisión de la adquisición, cuando la oferta ya está perdida.

Devart opera en varios ecosistemas de bases de datos. ¿Cómo puede la IA ayudar a simplificar la creciente complejidad de la gestión de datos en diferentes plataformas?

El dolor es real. Una empresa Fortune 500 típica ejecuta ocho a doce motores de base de datos diferentes simultáneamente: Oracle de legado para finanzas, PostgreSQL para nuevos servicios, SQL Server para operaciones, Snowflake o BigQuery para análisis y cada vez más un almacén de vectores para incrustaciones. Cada uno tiene su propio dialecto, su propia herramienta, su propio régimen de gobernanza. Un desarrollador que se une a ese entorno puede pasar tres meses solo aprendiendo dónde vive el dato y quién está autorizado a tocarlo.

La IA no soluciona esa complejidad por sí sola. Amplifica cualquier contexto que se le da. Ocho bases de datos desconectadas con metadatos no unificados producen ocho conjuntos desconectados de sugerencias superficiales. Eso es exactamente el modo de fallo que vemos en la mayoría de las implementaciones de IA empresariales en pilas.

La oportunidad es una capa de contexto que se sitúa entre los agentes de IA y las bases de datos subyacentes. Una que habla con todos ellos, normaliza los metadatos, aplica políticas de gobernanza unificadas y expone una interfaz de MCP limpia para que cualquier agente de IA, ya sea Claude, GPT o un modelo interno, funcione en toda la propiedad con reglas consistentes.

Esa es la arquitectura hacia la que estamos construyendo con la Conectividad de IA: un servidor de MCP local con soporte multi-base de datos, una capa semántica que captura definiciones comerciales una vez en lugar de forzar a cada agente de IA a volver a aprenderlas, control de acceso basado en roles a nivel de operación de SQL y registros de auditoría completos.

La simplificación no es gratuita. Alguien todavía tiene que modelar la capa semántica y establecer la política. Pero ese trabajo se hace una vez, no repetidamente para cada agente de IA que agregue.

Ha liderado equipos grandes y multifuncionales. ¿Cómo está cambiando la IA la colaboración interna y la toma de decisiones entre producto, ingeniería, marketing y ventas?

La mayoría de la fricción entre equipos fue realmente solo personas esperando información de otros equipos. La IA colapsa esa fricción más rápido que cualquier marco de gestión.

Los cambios son prácticos e inmediatos.

En producto e ingeniería: un gerente de productos hace una pregunta de base de datos en términos comerciales simples, “¿cuál es la variación de LTV en nuestros tres niveles de precios principales?”, y obtiene una respuesta útil al instante, en lugar de archivar un ticket de Jira a análisis y esperar tres días.

En marketing y datos: el análisis de cohortes ocurre en línea, no a través de una cola de solicitudes. El gerente de marketing pregunta, obtiene números y construye la campaña, todo en la misma mañana.

En ventas e ingeniería: las respuestas técnicas para los prospectos ya no requieren programar una llamada con un ingeniero senior. El representante de ventas obtiene una respuesta técnica creíble en tiempo real, y el ciclo de la oferta se comprime.

Las decisiones se mueven hacia la conversación en lugar de hacia el seguimiento. El patrón “Déjame regresar a ti con ese número” muere. Las reuniones se reducen porque la IA maneja los pre-lecturas y los resúmenes que solían consumir la primera mitad de cada sesión.

Este colapso de la fricción fuerza un cambio de gestión más profundo, y es el que la mayoría de los equipos de liderazgo subestiman.

Cada empresa afirma estar orientada a resultados. Mire debajo de la superficie y la mayoría todavía se ejecuta en métricas de proxy: puntos de historia, líneas de código, tickets cerrados, horas registradas. Usamos la actividad como un proxy para el valor porque el valor real era difícil de medir. La IA rompe ese proxy permanentemente. Cuando un agente puede escribir 10,000 líneas de código o cerrar 500 tickets de soporte en un minuto, medir la actividad se vuelve peligrosamente engañoso.

Estamos pasando explícitamente a una Gestión Orientada a Resultados Verdaderos, donde el desempeño se mide estrictamente por el resultado y el juicio. Brutal en la práctica, porque la mayoría de los sistemas de desempeño no están diseñados para ello. Las personas que solían esconderse detrás de una alta actividad se vuelven visibles de inmediato, y el liderazgo debe estar dispuesto a actuar sobre esa visibilidad.

La consecuencia estructural es una organización con menos capas. Las capas de coordinación y enrutamiento de información se comprimen. Las organizaciones que se adapten más rápidamente operarán con estructuralmente menos personas a mayor apalancamiento.

Con el auge del desarrollo asistido por IA y las herramientas sin código, ¿estamos avanzando hacia un futuro en el que la gestión de bases de datos se vuelve accesible para usuarios no técnicos?

Hay una confusión peligrosa en la industria en este momento. La gente trata una base de datos de proyecto lateral y una base de datos empresarial de legado como si fueran lo mismo. No lo son.

Para proyectos pequeños y nuevos, la democratización ya está aquí. He construido personalmente aplicaciones desde cero sin habilidades profundas en gestión de bases de datos. Si todo su esquema cabe dentro de la ventana de contexto de un LLM, la IA funciona como magia. Los desarrolladores ciudadanos que construyen herramientas internas a pequeña escala serán una categoría real y en crecimiento.

La realidad empresarial es completamente diferente. Las bases de datos de legado masivas enfrentan el mismo problema que los monolitos de código: el muro del contexto. No puede caber quince años de evolución de esquema no documentada, dependencias entre bases de datos y lógica de desencadenador personalizada en un prompt. Cuando la IA pierde el contexto en una base de datos grande, las alucinaciones no se degradan de manera elegante. Se multiplican exponencialmente.

El riesgo que se pasa por alto es la confianza falsa a gran escala. Las interfaces de lenguaje natural son únicas para producir respuestas que parecen plausibles pero que son ligeramente incorrectas. Si una consulta SQL tiene un error de sintaxis, obtiene un mensaje de error. Si una interfaz de lenguaje natural malinterpreta “clientes activos” porque sus datos tienen seis definiciones diferentes de actividad, obtiene un número. El número parece bien. Puede estar equivocado en un 30%. El usuario no tiene forma de saber.

Así que no, la gestión de bases de datos empresariales no se está convirtiendo en un patio de recreo para usuarios no técnicos.

El DBA ciudadano es un mito a gran escala.

El futuro pertenece a los arquitectos de datos expertos que utilizan herramientas profesionales para salvar la brecha de contexto y construir infraestructura que permita a la IA operar de manera segura en la parte superior.

La solución estructural es la capa semántica: un vocabulario controlado donde las definiciones comerciales se fijan una vez y se reutilizan en cada interacción de IA. Esa es la arquitectura central que estamos construyendo en Insightis. Sin ella, la accesibilidad se convierte en una responsabilidad.

Mirando hacia adelante, ¿cómo se ve una “herramienta de desarrollo nativa de IA” y cómo deben prepararse los equipos para ese cambio hoy en día?

Una herramienta de desarrollo nativa de IA no es un chatbot agregado a un IDE. La mayoría de lo que se comercializa como “nativo de IA” hoy en día es una interfaz de chat más un modelo de autocompletar. Eso es lo básico, no el destino.

Para mí, una herramienta de desarrollo genuinamente nativa de IA necesita tres cosas.

Primero, la IA necesita un contexto profundo. Debe comprender su base de código, su infraestructura, sus decisiones históricas y su entorno de datos de manera continua, no solo a través de prompts pegados en una ventana de chat. La mayoría de las herramientas actuales fallan en esta prueba. Su contexto se restablece con cada sesión, y el usuario paga el costo de volver a construirlo constantemente.

En segundo lugar, las herramientas en sí deben comunicarse entre sí adecuadamente. Su IDE debe hablar con su base de datos, la base de datos con su pila de observabilidad y la CI/CD con su revisor de IA, etc. El Protocolo de Contexto del Modelo se está convirtiendo en la capa estándar aquí, con 97 millones de descargas de SDK por mes en el primer trimestre de 2026, un aumento con respecto a las 100,000 de finales de 2024. Eso es una curva de adopción de 970 veces en quince meses y la curva de adopción más pronunciada que he visto en la infraestructura de desarrollo.

En tercer lugar, la IA de producción requiere guardias de seguridad serios. Vista previa del radio de explosión antes de operaciones destructivas. Análisis de dependencias. Planes de reversión automatizados. Registros de auditoría por defecto. La IA sin estos es adecuada para prototipos y peligrosa en producción.

Cómo prepararse, concretamente.

Audit su pila contra esos tres componentes. ¿Cada herramienta expone API y MCP? ¿Habla con otros, o se sienta en un silo? ¿Tiene controles de seguridad? Las herramientas que fallan dos de tres son activos a corto plazo.

Construya la infraestructura de contexto ahora. Documente los esquemas, las definiciones comerciales y las decisiones arquitectónicas en formatos legibles por máquina. El contexto rico no se construye en un trimestre. Los equipos cuya IA tiene eso en 2027 son aquellos que documentan hoy.

Ejecutar la IA en producción antes de que crea que está listo. Los equipos que esperan una “estrategia de IA” formal antes de enviar estarán dieciocho meses detrás de los equipos que ya están aprendiendo de los fallos de producción reales. Elija un caso de uso de bajo riesgo. Envíelo. Construya el músculo.

Los equipos que toman estas decisiones hoy definirán la próxima década de cómo se construye el software. La ventana es estrecha, y está abierta ahora.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Devart.