← Volver al blog Post

Prompt y producción no es ingeniería

Escritorio minimalista de un desarrollador de software al atardecer, con un monitor ultrapanorámico que muestra un flujo de despliegue CI/CD pendiente de aprobación y una mano suspendida sobre un teclado ergonómico antes de pulsar Enter, iluminado por la mezcla de luz natural cálida y el brillo de la pantalla.

Una reflexión sobre IA y criterio profesional

“Hazlo y súbelo.”

A veces no se formula así. Se disfraza de urgencia: tiene que estar mañana, ya lo revisaremos después, la IA lo resuelve, no hace falta darle más vueltas. Pero, cuando esa urgencia reemplaza la revisión y el criterio, el resultado es el mismo: una decisión de producción tomada sin comprender suficientemente qué estamos poniendo en producción.

Una frase que escuché la semana pasada me hizo detenerme: “Que lo haga la IA y súbelo; no aporta valor que un desarrollador revise el código”.

Hay escenarios en los que una revisión exhaustiva puede aportar poco. Tareas pequeñas, repetitivas, acotadas y reversibles pueden beneficiarse enormemente de la automatización. Negarlo sería dogmático.

Pero convertir esa idea en una norma general implica algo más profundo: asumir que la implementación es lo único que importa y que el criterio profesional puede desaparecer del proceso.

No escribo esto desde el rechazo a la inteligencia artificial. La uso a diario y creo que puede ampliar de forma extraordinaria nuestra capacidad para construir software. Puede resolver tareas repetitivas, acelerar exploraciones, desbloquear problemas y permitir que equipos pequeños validen ideas que antes habrían requerido recursos inalcanzables.

Eso es valioso. Y precisamente por serlo, merece un uso responsable.

El problema no es que la IA escriba código. El problema empieza cuando confundimos su capacidad para generar una solución con la certeza de que esa solución es adecuada para producción. Una herramienta puede proponer una implementación; no puede asumir las consecuencias de aceptarla.

Alguien sigue decidiendo qué se pide, qué datos puede tocar el sistema, qué permisos se le conceden, qué pruebas son suficientes, qué riesgo se acepta y cuándo se despliega. Aunque no haya escrito cada línea, esa persona o ese equipo sigue siendo responsable.

La profesionalidad no consiste en escribir todo a mano. Tampoco consiste en revisar cada cambio con la misma intensidad. Una landing page personal no tiene la criticidad de un sistema que procesa pagos, datos personales o infraestructura sensible. Una tarea pequeña, repetitiva y acotada puede ser un escenario excelente para delegar ampliamente en la IA.

Pretender el máximo control en todos los casos sería ineficiente. Pero eliminar el control por completo no es eficiencia: es renunciar al criterio.

La autonomía que concedemos a una herramienta debería depender menos de cuánto confiemos en ella y más de tres preguntas: cuánto daño puede causar un error, qué controles existen para detectarlo y qué capacidad tenemos para limitarlo o revertirlo.

Ahí entran los guardarraíles. Configuraciones previas, modelos adecuados para cada tarea, permisos limitados, validaciones automáticas, pruebas, entornos aislados, observabilidad, capacidad de revertir cambios y revisiones cuando el impacto lo justifique. No son una declaración de desconfianza hacia la IA; son una declaración de responsabilidad hacia las personas afectadas por el software.

También importa la preparación de quien usa la herramienta. El juicio profesional no desaparece porque una interfaz permita obtener resultados con rapidez. Al contrario: se vuelve más importante. Hay que poder distinguir una solución plausible de una solución segura; reconocer cuándo no se entiende suficientemente un cambio; y saber cuándo pedir ayuda o elevar un riesgo.

Pero tampoco toda la responsabilidad puede recaer sobre una única persona. Los equipos necesitan acuerdos: mínimos no negociables para ámbitos sensibles y prácticas que evolucionen con la experiencia. No hace falta prever cada situación desde el primer día; intentar hacerlo puede llevar a la parálisis. Sí hace falta aprender de lo que ocurre, convertir ese aprendizaje en mejores controles y no repetir los mismos riesgos por comodidad.

Cuando normalizamos el “prompt y producción” sin criterio, el daño no se limita a un fallo puntual. Puede traducirse en brechas de seguridad, costes invisibles, deuda técnica, pérdida de confianza y decisiones difíciles de revertir. También deteriora la percepción de nuestra profesión: transmite que desarrollar software consiste en pedir resultados y pulsar un botón, en lugar de tomar decisiones responsables bajo incertidumbre.

La IA multiplica nuestra capacidad de actuar. Puede hacer mejor lo que ya hacemos bien. Pero también puede ampliar, de forma peligrosa, una falta de cuidado, de conocimiento o de responsabilidad.

No se trata de revisar por revisar ni de desconfiar de la IA por defecto. Se trata de no confundir rapidez con responsabilidad.

Antes de darle a desplegar, pregúntate: ¿qué podría detectar o prevenir una revisión razonable? ¿Qué impacto tendría equivocarnos? ¿Qué controles existen para detectarlo, limitarlo o revertirlo?

Si no puedes responder, quizá todavía no es el momento de subirlo.

La IA puede escribir código. La responsabilidad de ponerlo en producción sigue siendo nuestra.

  • ai
  • software-engineering
  • professional-responsibility