Experto en productos comparte el flujo de trabajo de programación intuitiva que está reemplazando los traspasos a ingeniería

Anton Ingachev es el fundador de Mini Apps Builder, una plataforma sin código para crear aplicaciones de Telegram, donde dirige el producto. Antes de esto, ocupó varios puestos como CPO y director de producto.

Hablamos con Anton para saber cómo está eliminando las transferencias al equipo de ingeniería al programar él mismo pequeñas funcionalidades mediante lenguaje natural. Esto es lo que nos contó.

Adentrarse en la IA por necesidad

Llevo más de diez años trabajando en producto: fintech, plataformas de ajedrez, blockchain y tecnología sanitaria. Fui CPO en dos ocasiones y director de producto una vez.

Mi trayectoria con la IA comenzó por una necesidad práctica, no por una estrategia. Hace aproximadamente un año y medio cofundé Mini Apps Builder, una plataforma B2B2C sin código para crear aplicaciones de Telegram. Como CPO no ingeniero, necesitaba lanzar funcionalidades rápidamente sin esperar a un ciclo completo de desarrollo. Fue entonces cuando empecé a utilizar Claude Code y Cursor a diario, no solo para documentación o creación de prototipos, sino también para trabajar en producción.

Para demostrar todo su potencial, construí en solitario un producto listo para producción —arquitectura, backend, frontend, todo— utilizando herramientas de IA y sin un equipo de ingeniería. Ahí fue cuando dejé de pensar «utilizo la IA para trabajar más rápido» y pasé a pensar «puedo crear y lanzar productos reales por mi cuenta».

Ahora aplico el mismo enfoque en Mini Apps Builder: desarrollo directamente algunas funcionalidades, en lugar de limitarme a especificarlas para los ingenieros.

Así que mi camino no fue «leí sobre la transformación mediante IA y decidí liderarla». Necesitaba avanzar rápido sin un equipo grande; la IA lo hizo posible y ahora pienso de otra manera sobre la estrategia de producto gracias a ello: cada decisión de la hoja de ruta incluye ahora la pregunta: «¿Puede la IA encargarse de este paso o solo servir de apoyo?»

Cómo la IA sustituye el antiguo modelo de transferencia en los flujos de trabajo de producto

Durante años creí que el trabajo de un PM terminaba en la especificación. Escribes los requisitos, pero no tocas el código: ese es el trabajo del ingeniero. Cruzar esa línea parecía extralimitarse.

Ese es el mayor cambio que la IA ha provocado en el mundo del producto. Ahora me encargo yo mismo de las funcionalidades sencillas. Las desarrollo utilizando Claude Code y las lanzo directamente, sin esperar a que haya capacidad disponible en ingeniería.

Eso significa que podemos eliminar un paso completo de transferencia. En lugar de pasar de especificación → revisión de ingeniería → desarrollo → control de calidad, a menudo desarrollo y pruebo directamente.

Ahora nuestro ciclo de lanzamiento es de dos o tres funcionalidades publicadas por semana con un equipo de dos personas, entre el sitio web, el panel del comerciante, la propia Mini App de Telegram y nuestro panel de administración interno. Ese ritmo no sería posible con el antiguo modelo de transferencia.

También cambió mi forma de pensar sobre la estructura del equipo. La limitación ya no es «¿Cuántos ingenieros tenemos?». Ahora es «¿Hasta qué punto puedo especificar bien lo que quiero?»

Un flujo de desarrollo de funcionalidades basado en IA

Así es el desarrollo de una funcionalidad:

1. Describo la tarea a un modelo de primer nivel como Claude Code. Comparto lo que me gusta, lo que no me gusta, el problema que estamos resolviendo y lo que no debería olvidarse ni romperse. Proporciono referencias, a veces de competidores directos, aunque no siempre.
2. El modelo genera un plan detallado. Lo leo. Si es necesario, hago cambios o cuestiono el plan.
3. Pido a Claude que implemente el plan en código.
4. Creo una PR, que pasa por comprobaciones automatizadas antes de asignarse al CTO.
5. Si todo está bien, el CTO la integra en dev y la pruebo en el producto.
6. Si algo no está bien, el CTO deja comentarios, le pido al modelo que los corrija y el proceso se repite.
7. Si algo está muy mal, hablo con el CTO sobre cómo mejorar las instrucciones proporcionadas al LLM y lo repetimos.
8. Después de probarlo en dev, lo pasamos a producción.

Pensamientos de Anton

Comparto lo que me gusta, lo que no me gusta, el problema que estamos resolviendo y lo que no debería olvidarse ni romperse.

Dónde se puede aplicar la IA en los flujos de trabajo de producto

Las principales herramientas de IA que utilizo son Claude Code, Codex, Cursor, Gamma, Midjourney y Figma Agent. Estas son otras formas en las que utilizo la IA en los flujos de trabajo de producto, junto con algunos de sus beneficios:

1. Todo nuestro producto — interfaces, blog, Centro de ayuda y artículos sobre actualizaciones del producto — se traduce a 20 idiomas casi en tiempo real con un solo clic.
2. Los artículos del blog redactados por un LLM prácticamente duplicaron nuestro tráfico de búsqueda — y redactar los artículos lleva una fracción del tiempo.
3. Como responsable de producto, la IA me facilita cuestionar mis propias ideas — puedo pedirle que encuentre datos que las respalden o las refuten.
4. Redactar las notas de lanzamiento ya no es un problema, porque la IA lo hace casi automáticamente.

Sinceramente, no se me ocurre ningún ámbito en el que la IA no ayude. Utilizarla aporta un beneficio claro en casi todas partes. Sí, las personas deben comprobarla, ajustarla y entrenarla, pero siempre que haya un objetivo claro y se entienda cómo alcanzarlo con IA, el proceso mejora.

Por qué la IA necesita el contexto adecuado antes de integrarse en los flujos de trabajo

Cuando se trata de IA, el contexto lo es todo.

Antes redactaba artículos para el blog basándome en las indicaciones de un especialista en SEO. Tardaba entre dos y tres horas. Después, cargué el contexto del proyecto en un LLM y le proporcioné directamente las indicaciones; ahora los artículos tardan entre 5 y 7 minutos. Y, como he mencionado antes, tienen una mayor calidad, lo que ha duplicado el tráfico.

Sin embargo, cuando le pedí al especialista en SEO que los redactara con IA, me sorprendió lo deficientes que eran los resultados. ¿El motivo? Su LLM tenía mucho menos contexto del proyecto que el mío.

Sea cual sea el flujo de trabajo, ¡invierte en proporcionar contexto a tus herramientas de IA!

Por qué los responsables de producto deben revisar a fondo algunos flujos de trabajo de producto, pero no necesariamente todos

¿Mi consejo? Integra la IA en la mayoría de tus procesos desde ahora mismo. Ya no estamos en 2022; su valor está claro. La IA es imprescindible.

Los responsables de producto deberían volver a examinar todos los procesos y herramientas que antes consideraban óptimos. Pero eso no significa necesariamente revisarlos todos a fondo con IA. Debes comprender las limitaciones de la IA, tus propios puntos fuertes y débiles, el producto en el que trabajas, los presupuestos, etc.

La configuración será diferente para cada proyecto concreto. Todo es flexible. Y no existen prácticas recomendadas establecidas. Eso complica las cosas.

La única forma de averiguarlo para tu producto es mediante la experimentación práctica.

Las reflexiones de Anton

¿Mi consejo? Integra la IA en la mayoría de tus procesos desde ahora mismo. Ya no estamos en 2022; su valor está claro. La IA es imprescindible.

Sigue su trabajo

Puedes seguir el trabajo de Anton Ingachev en LinkedIn y GitHub. También puedes descubrir Mini Apps Builder.

¡Próximamente, más entrevistas con expertos en The CPO Club!