Lo que un prompt no puede construir
Un modelo te va a escribir un sistema que anda más rápido de lo que podría cualquier equipo. No te va a decir si está bien, y ese hueco no se cierra a medida que mejoren los modelos: la información que falta no está en el modelo. Acá está dónde cae la línea de verdad, con un ejemplo de la construcción de este mismo sitio.
Qué produce un prompt, y qué no
- Produce código. Buen código, rápido, para problemas que se parecen a problemas que ya vio. Eso es real y no va a retroceder.
- No produce acceso. Credenciales, una posición dentro de la red, permiso para tocar un sistema en producción. Ninguna capacidad se gana la confianza de una empresa.
- No produce verdad sobre tu entorno. Qué versión está instalada realmente, qué devuelve de verdad ese sistema de 2011, cuál es la regla de negocio una vez que contás la excepción que nadie escribió.
- No produce consecuencia. Cuando algo falla, alguien tiene que responder. Eso no se delega en un sistema que no arriesga nada.
- No produce acuerdo. Qué tiene que hacer el sistema es una negociación entre personas con intereses distintos, no una pregunta con respuesta correcta.
Por qué estos límites son estructurales y no temporales
La información no está en internet
Un modelo aprende de texto público. El comportamiento de una máquina sin documentar, un proceso interno, las mañas reales de un sistema viejo: ese conocimiento vive en los equipos y en la cabeza de la gente. No hay corpus con qué entrenar, así que la capacidad no ayuda.
Verificar requiere acceso a lo que se verifica
Un modelo puede comprobar si un código es coherente consigo mismo. No puede comprobar si coincide con una realidad a la que no tiene acceso. Son preguntas distintas, y sólo la segunda determina si tu sistema funciona.
La responsabilidad no se automatiza por definición
Una firma vale porque el que firma arriesga algo. Un sistema que no arriesga nada puede producir el documento pero no la garantía, por bueno que sea el documento.
La entrada más difícil es qué quiere la gente
Casi toda la dificultad de un proyecto real está en decidir qué construir, y eso es un desacuerdo entre finanzas, operaciones y un fundador. Un modelo puede escribir cualquier cosa; no puede zanjar eso.
Dónde aparece esto en la práctica
El ejemplo de este sitio
El formulario de contacto de esta web se escribió con asistencia de IA. Las pruebas también. Pasaron todas. El formulario estuvo roto para todos los visitantes reales durante dos días: las pruebas mandaban JSON y los navegadores mandan multipart. El código era correcto; el supuesto sobre el mundo de afuera, no.
La versión instalada, no la del ejemplo
Una directiva de configuración válida en nginx 1.25 y fatal en 1.24. Sintácticamente impecable, y no dejaba arrancar el servidor. Esa diferencia no está en el código: está en la máquina.
La regla correcta que igual está mal
Una regla de redirección que hacía exactamente lo que decía, y que al combinarse con una reescritura interna producía un bucle infinito. Revisar la regla no muestra nada. Pedir la página lo muestra al instante.
La entrada que nadie cuestionó
Un limitador contando peticiones por dirección IP, funcionando perfecto, y contando lo que no era: detrás de una red de distribución todas las peticiones llegan desde esa red. Lógica correcta, entrada equivocada, y ninguna prueba lo habría detectado.
Cinco preguntas para hacerle a cualquier cosa generada
- ¿Se ejercitó como lo va a usar una persona real, o como se lo imaginó quien lo escribió?
- ¿Coincide con las versiones realmente instaladas, o con las de la documentación?
- Si falla a las tres de la mañana, ¿hay registrado lo suficiente para saber por qué?
- ¿Quién responde por esto, y lo entiende lo bastante como para responder?
- La pregunta «¿esto está bien?», ¿la hizo alguien capaz de darse cuenta?
Preguntas que esto abre
¿Esto es un argumento en contra de usar IA para escribir código?
No. En Devsitia la usamos todo el tiempo y es una ganancia real. El argumento es más acotado: generar código y saber si está bien son problemas distintos, y sólo el primero se abarató. Tratarlos como si fueran el mismo es lo que produce sistemas que funcionan en la demo.
¿Alguien sin formación en software puede construir así un sistema real?
Puede construir algo que parece funcionar, y eso es un cambio real que hay que tomar en serio. Lo que no puede es evaluarlo. El que no podía escribir el código tampoco puede leerlo, así que no tiene forma de distinguir un sistema que anda de uno que todavía no falló. La barrera que se movió fue la de producir, no la de saber.
¿Esto va a cambiar a medida que mejoren los modelos?
Una parte sí, y rápido. Todo lo que sea cuestión de capacidad va a caer. Lo que no va a caer es la parte donde la información necesaria no existe en ningún corpus de entrenamiento, y la parte donde alguien tiene que hacerse cargo. Eso no son problemas de dificultad.
Entonces, ¿cuál es el consejo práctico?
Usá la generación. Después verificá contra el entorno real: el formato de petición que llega de verdad, la versión instalada, el sistema andando. Y sostené a una persona capaz de distinguir código correcto de código apenas verosímil, porque verosímil es lo que un modelo produce por construcción.
¿Cómo se baja el riesgo sin perder la velocidad?
Ensamblando componentes ya verificados para lo que sale caro si está mal —autenticación, permisos, cobros, integridad de datos, auditoría— y generando libremente en todo lo demás. Los modos de falla se concentran en unos pocos lugares, y esos son los que no conviene improvisar.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.