Metodología
Cómo construye InTech software con IA
La IA acelera la construcción. Los ingenieros conservan el criterio, la arquitectura y los controles de calidad, bajo CRAFT.
Comience con nuestro agente de IA. Encuentre su siguiente paso.
Metodología
En qué le ayuda esto
- Distinga el trabajo asistido por IA del código generado por IA
- Vea cómo CRAFT gobierna cada etapa de la construcción
- Sepa quién construye su software y qué es suyo
Hay una diferencia entre el código que simplemente generó una IA y el software que funciona. El primero toma atajos en la arquitectura, se salta las revisiones de seguridad y acumula una deuda técnica que crece con el tiempo. El segundo trata la IA como un acelerador dentro de un proceso de ingeniería disciplinado, en el que un ingeniero evalúa cada resultado de una herramienta de IA en cuanto a corrección, seguridad y mantenibilidad.
InTech no se dedica a generar código con IA. Practicamos el desarrollo asistido por IA (se abre en una pestaña nueva). Y esa distinción cambia por completo lo que llega a producción.
El problema del código generado por IA
Todos los días hay equipos que abren ChatGPT, le piden una funcionalidad, copian el resultado en su base de código y lo dan por terminado. Se siente rápido. Y lo es, hasta que el esquema de la base de datos falla bajo carga, o la lógica de autenticación tiene una vulnerabilidad que toma tres semanas depurar, o el código es tan opaco que nadie puede modificarlo seis meses después.
El costo real del código generado por IA no es el tiempo que se ahorra al principio. Es la deuda que se contrae: una arquitectura imposible de mantener, falta de manejo de errores, integraciones de terceros elegidas por comodidad y no por ser las adecuadas, nada de observabilidad y ningún razonamiento documentado detrás de las decisiones.
Cuando alguien de su equipo, inevitablemente, necesite modificar ese código, tendrá que empezar desde cero, porque no quedó registrado por qué se construyó de esa manera.
El enfoque de InTech es distinto. Usamos herramientas de IA para la estructura base, el código repetitivo, los primeros borradores de funciones y la generación de pruebas. Pero un ingeniero con experiencia revisa cada resultado antes de que entre a su base de código. Ese ingeniero es responsable de la arquitectura, de la postura de seguridad y de la mantenibilidad a largo plazo. La IA acelera la ejecución. Las personas aportan el criterio.
Cómo construye InTech software con IA: el proceso CRAFT
CRAFT (Context, Rationale, Automate, Fortify, Telemetry) es el sistema operativo de InTech, la gobernanza que sostiene la estrategia, la ingeniería de producto y las operaciones gestionadas. Pro-Neering es la filosofía que lo respalda. En la construcción, CRAFT está diseñado para detectar los vacíos que el código generado por IA deja completamente abiertos.
Context: el contexto primero
Antes de escribir una sola línea de código, InTech establece un entendimiento compartido de qué se va a construir realmente y por qué. Esto se logra con un Intent Contract. Un Intent Contract es una declaración breve y aprobada del resultado, el alcance, las métricas de éxito, las restricciones, los límites de la autoridad humana y los criterios de aceptación. No es un acuerdo legal; las condiciones comerciales se establecen en el contrato del proyecto.
Un Intent Contract no es un documento de requisitos. Es el norte del trabajo. Es lo que evita que el proyecto se desvíe hacia un exceso de funcionalidades o termine resolviendo el problema equivocado. Cuando el equipo se atasca en una decisión técnica, consulta el Intent Contract para decidir si un enfoque determinado sirve o no a la métrica de resultado.
Esta fase evita el primer error costoso: construir rápido lo equivocado.
Rationale: el fundamento, documentado
Cada decisión técnica importante (elección de arquitectura, modelo de datos, integración con terceros, enfoque de autenticación) queda registrada en un Decision Record. No solo la decisión, sino el razonamiento: por qué se eligió esa opción, qué alternativas se evaluaron y qué restricciones determinaron la elección.
Los Decision Records cumplen dos funciones. Primero, obligan a pensar con claridad en el momento en que se toma una decisión. Segundo, evitan que las mismas decisiones vuelvan a discutirse seis meses después, cuando alguien pregunte: "¿por qué lo construimos así?"
Cuando la IA genera código que parte de un supuesto de arquitectura, un Decision Record explica por qué ese supuesto es válido o si hay que reconsiderarlo. Sin ese registro, los ingenieros que lleguen después quedarán bloqueados u obligados a adivinar.
Automate: automatizar con supervisión
Aquí es donde las herramientas de IA entran al proceso. Los prompts son precisos porque los requisitos están claros y documentados. La IA genera esqueletos de funciones, estructura base, casos de prueba y código rutinario. Los ingenieros revisan el resultado en cuanto a corrección, implicaciones de seguridad, características de rendimiento y alineación con la arquitectura documentada.
La automatización es proporcional al riesgo. Una función utilitaria generada recibe una revisión ligera. El diseño del flujo de autenticación recibe una evaluación rigurosa. Cuanto más riesgoso es el código, más criterio humano recibe.
Fortify: fortalecer antes de lanzar
Los controles de calidad son obligatorios, no opcionales. Antes de que el código salga a producción, las pruebas deben pasar. La ruta de reversión debe validarse en un entorno de preproducción. Las variables de entorno deben gestionarse de forma segura. La observabilidad debe estar activa: si algo falla en producción, su equipo lo sabrá en cuestión de minutos. La aprobación de QA no es una cortesía; es un control.
"Parece que ya está listo" no es un estándar de calidad suficiente cuando se opera en producción un software del que dependen las personas. Fortify asegura que lo que sale del pod esté realmente listo.
Telemetry: telemetría desde el primer día
El éxito no se mide por la fecha de despliegue. Se mide frente a la métrica de resultado definida en el Intent Contract, observada mediante telemetría en vivo después del lanzamiento. Treinta días después del lanzamiento, el equipo revisa esa telemetría: ¿la funcionalidad realmente está reduciendo la fricción para los clientes? ¿Se está usando como esperábamos? ¿Qué falló que no habíamos previsto?
Así se cierra el ciclo. Lo que aprende de la telemetría orienta la siguiente iteración, el siguiente Decision Record y el siguiente Intent Contract.
El modelo de pods: quién construye su software
Asignamos pods dedicados, no freelancers: equipos integrados que se hacen responsables del resultado.
Un pod incluye ingenieros dedicados, un Product Delivery Lead y apoyo de QA, DevOps y UI/UX proporcional a las necesidades del producto. Un Product Delivery Lead es responsable del resultado: gestiona la intención, los hitos y el ritmo de entrega durante todo el proyecto. Un solo equipo responsable se mantiene a cargo de su producto, los especialistas se suman según haga falta y el contexto se conserva en el Context Graph y en los Decision Records. Nosotros respondemos por la calidad del código. Usted es dueño del código y de la infraestructura.
InTech ofrece dos configuraciones de pod:
Express Pod. Un Express Pod lleva una mejora medible a producción en cuestión de semanas, con el plazo acordado en el Intent Contract antes de empezar a construir. Toma una sola restricción bien definida y la hace pasar por cuatro etapas (Alinear, Construir, Verificar y Comprobar), de modo que la viabilidad, la utilidad, la adopción y la capacidad de dar soporte se demuestran en lugar de suponerse. Este modelo es para equipos que necesitan evidencia en producción antes de comprometerse con una entrega sostenida.
Build Pod. El Build Pod es capacidad de entrega continua con un Product Delivery Lead, dimensionada según la forma del trabajo y gestionada en función de resultados. Las condiciones comerciales se acuerdan en cada proyecto. Funciona para equipos que tienen una dirección de producto clara y necesitan capacidad de ingeniería sostenida para ejecutar una hoja de ruta.
Para productos más grandes con varios frentes de trabajo, o para equipos que necesitan avanzar más rápido en una hoja de ruta compleja, el Build Pod se configura para varios frentes de trabajo, bajo el mismo modelo de responsabilidad.
Toda la infraestructura se configura desde el primer día en sus repositorios y sus cuentas en la nube (AWS, GCP, Azure, Vercel, Railway, Supabase o lo que ya utilice). Las llaves son suyas. Nunca depende de cuentas ni de integraciones administradas por InTech.
Qué recibe
Un pod de InTech entrega más que código. Recibe una base de código documentada y mantenible, con el fundamento de las decisiones integrado en todo el código. Recibe Intent Contracts que aclaran la estrategia. Recibe un solo equipo que entrega desde varias regiones, incluidos Estados Unidos y América Latina, con contexto compartido y horarios que se superponen con el horario laboral de Estados Unidos. Recibe visibilidad semanal del avance y un camino claro hacia cada hito.
Obtiene una base de código que su propio equipo puede entender, modificar y operar. No está pagando por deuda técnica disfrazada.
Preguntas frecuentes
¿El desarrollo asistido por IA significa que el código es menos confiable?
No. La IA genera código rápidamente, pero sin criterio humano suele pasar por alto implicaciones de seguridad, problemas de escalabilidad y la coherencia de la arquitectura. El enfoque de InTech invierte esto: la IA resuelve rápido las tareas de programación rutinarias y los ingenieros concentran su atención en las decisiones más importantes, las que determinan si el sistema es seguro, escalable y mantenible. El resultado es código que pasa por los mismos controles de revisión, seguridad y calidad que el código que un ingeniero sénior escribe a mano.
¿Qué pasa si tenemos código existente con el que queremos integrarnos?
Es lo normal. El pod hereda su base de código existente, entiende su arquitectura y sus restricciones, y la amplía de acuerdo con su hoja de ruta. Las decisiones de integración quedan registradas en Decision Records. El objetivo es una base de código coherente, no un sistema en el que el código antiguo y el nuevo siguen patrones distintos.
¿Cuánto tenemos que involucrarnos?
Necesita estar disponible para aclarar el Intent Contract y para dar retroalimentación en cada fase. El Product Delivery Lead programará reuniones semanales de sincronización y señalará los bloqueos con anticipación. Cuente con una o dos horas por semana durante las fases de construcción activa. Si se desentiende por completo, el pod no puede validar que está construyendo lo correcto.
¿Podemos cambiar de ingenieros a mitad del proyecto?
Asignamos pods dedicados, no freelancers. Si hace falta un cambio en el pod, primero lo conversamos con usted, y el Context Graph y los Decision Records mantienen el trabajo en marcha sin perder contexto.
¿Qué pasa después del lanzamiento?
La primera revisión de telemetría se hace al final del periodo de medición fijado en el Intent Contract, a menudo 30 días después del lanzamiento. Lo que sigue es decisión suya. Su equipo puede operar el sistema, un Build Pod puede seguir desarrollándolo o InTech Operate puede operarlo y mejorarlo como servicio gestionado, con las mismas evaluaciones y la misma telemetría.
¿Usan el stack tecnológico que yo elija?
Construimos en sus repositorios y sus cuentas en la nube, y trabajamos con el stack tecnológico que ya usa cuando es adecuado. Cuando no hay un stack existente al cual ajustarse, solemos empezar con Node.js/TypeScript, Railway, Supabase y Cloudflare, porque son herramientas confiables y cómodas para los desarrolladores. El objetivo es usar herramientas con las que su equipo pueda mantener el sistema con confianza a largo plazo.
Cuéntenos qué es lo que se interpone.
Dígale a nuestro agente de IA qué quiere mejorar. Le ayudaremos a encontrar un primer paso útil.