Ideas, métodos y aprendizajes de campo sobre estrategia, innovación, producto e IA. Escritos para reconocer una señal, tomar una decisión y profundizar cuando importa.
La decisión clásica entre comprar y construir ya no describe todas las opciones. Hoy podemos componer
una capacidad con productos existentes, APIs, agentes, automatizaciones y pequeñas piezas de software
propio.
Una demostración puede probar que algo es posible. No demuestra que una organización pueda utilizarlo
de forma repetida, segura y autónoma. El salto del piloto a la capacidad es principalmente
organizativo.
Un prompt excelente no puede compensar un proceso que nadie sabe explicar. Para obtener resultados
repetibles necesitamos hacer visibles el contexto, los criterios, las herramientas, los límites y la
forma de aprender de cada ejecución.
Los agentes son adecuados para algunos trabajos complejos y variables, no para cualquier proceso. La
decisión depende de incertidumbre, reversibilidad, observabilidad, coste del error y capacidad de
supervisión.
Medir IA únicamente por horas ahorradas deja fuera buena parte de su valor y puede premiar el trabajo
equivocado. El retorno también aparece en la calidad, la velocidad de decisión, el aprendizaje, el
riesgo evitado y las posibilidades nuevas.
Una pyme no necesita empezar con una estrategia abstracta de IA ni con una herramienta de moda. El
primer caso útil suele estar en una decisión que se repite, consume atención y deja un resultado que
podemos comprobar.
Desde el lanzamiento público de ChatGPT basado en GPT-3.5, la interacción con IA ha pasado de la
conversación a archivos, herramientas, búsqueda, código y agentes. Memorizar funciones caduca; aprender
a experimentar y evaluar permanece.
Una conversación reveló una necesidad: encontrar la frase exacta dentro de horas de audio o vídeo.
Unas dos horas después existía AudioFind, una herramienta pequeña y utilizable. El caso muestra qué
problemas empiezan a merecer software cuando construir una primera respuesta cuesta mucho menos.
Cuando crear una primera versión se abarata, el cuello de botella deja de ser convertir requisitos en
código. Liderar producto pasa a significar escoger problemas, diseñar evidencia y decidir qué opciones
no deben sobrevivir.
Si la IA reduce el coste de crear software específico, quizá no gastemos menos en software. Quizá
construyamos muchas más soluciones para problemas que antes no superaban el umbral económico de un
proyecto.
Muchas organizaciones rechazan la IA por estar «en la nube» mientras ya confían correo, documentos y
clientes a otros proveedores cloud. Esa contradicción no demuestra que la IA sea segura: demuestra
que necesitamos aplicar el mismo análisis coherente a todos los servicios.
El problema del vibe coding no es usar IA. Es eliminar los mecanismos que permiten comprender,
comprobar y evolucionar el software. Reparar una aplicación así empieza por recuperar un modelo del
sistema, no por generar más código.
Una persona puede dirigir un sistema de agentes capaz de cubrir muchas funciones de un equipo de
software. Eso no elimina el trabajo ni la colaboración: obliga a hacer explícitos el contexto, los
roles, los controles de calidad y los límites.
Waterfall intentó predecir. Agile aprendió a iterar. La ingeniería agéntica vuelve a reducir el coste
de cada vuelta. Eso no vuelve inútiles los principios ágiles, pero sí obliga a revisar ceremonias y
artefactos diseñados para otra velocidad de ejecución.
Introducir IA en ingeniería no consiste en repartir licencias y esperar productividad. Hay que
rediseñar el flujo, acordar dónde puede ayudar, mantener visible la calidad y convertir los hallazgos
individuales en capacidad del equipo.
La diferencia no es que el agente escriba mejor. Un chatbot mantiene una conversación; un agente
controla un flujo de trabajo, utiliza herramientas, observa el resultado y decide el siguiente paso.
Usar un chat de IA no significa que una organización haya adoptado IA. Este marco distingue cinco
niveles según la autonomía, la integración, la responsabilidad y la capacidad de aprender del
sistema.
Un prototipo no sirve para demostrar que una idea era buena. Sirve para descubrir qué parte de la
idea todavía no entendemos. Prototype-Driven Development reduce la distancia entre una conversación,
una evidencia compartida y la siguiente decisión.