Cómo usan la IA de forma diferente los desarrolladores sénior

No todos los desarrolladores con experiencia usan la IA de la misma manera, pero los buenos hábitos de ingeniería producen un patrón reconocible: dan contexto, piden análisis, acotan el cambio y validan la salida. La diferencia tiene menos que ver con una redacción ingeniosa del prompt y más con negarse a delegar el juicio sin evidencia.

Estas son prácticas útiles, no afirmaciones sobre cada desarrollador sénior ni una jerarquía de quién puede usar IA.

Solicitudes vagas frente a resúmenes con contexto

Solicitud menos fiable	Patrón de ingeniería más fiable
“Refactoriza este componente.”	Explica la duplicación, el comportamiento que se debe conservar, los archivos acotados y las pruebas que deben seguir pasando.
“Corrige la navegación móvil.”	Describe el problema de usabilidad móvil mientras proteges el comportamiento de escritorio y el estado de las rutas.
“Haz esto más rápido.”	Pide un cuello de botella medido, hipótesis en competencia y la mejora medible más pequeña.

El contexto permite que un asistente elija entre opciones técnicas plausibles. Sin él, puede optimizar el código visible en lugar del problema real de la persona usuaria.

Respuestas primero frente a análisis primero

Una solicitud breve de implementación está bien para una utilidad evidente. Es arriesgada para transiciones de estado, propiedad de datos, comprobaciones de permisos o un fallo de producción.

Un prompt de análisis primero se parece a esto:

Antes de editar, sigue cómo se trasladan las preferencias de notificaciones desde
el formulario hasta el registro de usuario almacenado y de vuelta a la interfaz.

Identifica el escritor único, la ruta de lectura y la ruta de error. Separa el
comportamiento confirmado de los supuestos. Después enumera los archivos más
pequeños que probablemente cambiarán y la prueba que demostraría el error
informado.

El asistente se convierte primero en un compañero de investigación. El desarrollador puede revisar el modelo del sistema antes de aceptar un parche.

Cambios grandes frente a cambios incrementales

Una tarea amplia puede combinar una corrección de error, una refactorización, una reescritura de pruebas y un cambio de estilo. Eso hace difícil ver la causa y el efecto.

Usa puntos de control en su lugar:

1. Reproduce el fallo y describe la ruta actual.
2. Realiza la corrección de comportamiento más pequeña.
3. Añade una prueba de regresión enfocada y ejecútala.
4. Muestra el diff y explica por separado la limpieza restante.

Esto no es trabajo innecesario. Los cambios pequeños hacen más seguras la revisión, la reversión y la respuesta a incidentes.

Confiar en la salida frente a validarla

El código generado por IA puede tener buen formato, ser seguro en tipos y aun así ser incorrecto para el producto. Los flujos de trabajo sólidos validan en varios niveles:

Comprobaciones estáticas: comprobación de tipos, linting, validación de esquemas.
Comprobaciones de comportamiento: pruebas unitarias o de integración enfocadas.
Comprobaciones de producto: un flujo de trabajo manual que coincida con el problema de la persona usuaria.
Comprobaciones de revisión: inspección del diff para detectar regresiones de alcance, permisos, configuración regional y efectos secundarios.

Pide al asistente que proponga estas comprobaciones y ejecuta después las pertinentes tú mismo. Si una comprobación no puede ejecutarse localmente, registra la carencia en lugar de afirmar que tuvo éxito.

Pensamiento centrado en la implementación frente al problema

La primera idea de implementación suele ser la forma más cara de resolver un síntoma. Empieza por el problema:

Problema: Un estudiante pierde la tarea actual después de cambiar de pestaña del
navegador en una pantalla pequeña.

No supongas que la respuesta es una nueva capa de persistencia. Inspecciona la
navegación, la propiedad del estado y el comportamiento de restauración actuales.
Recomienda el cambio más pequeño que permita al estudiante volver a la tarea
activa sin duplicar estado ni debilitar la privacidad.

Esto deja espacio para una respuesta más sencilla: una corrección de rutas, una corrección de estado obsoleto o una interacción móvil diferente.

Los hábitos sénior son hábitos de revisión

El patrón más transferible no es “usa un modelo concreto” ni “escribe prompts más largos”. Consiste en hacer el trabajo revisable:

Explica por qué importa el cambio.
Indica qué debe seguir siendo cierto.
Pregunta qué evidencia podría refutar el plan.
Limita el primer cambio.
Define la prueba de que funcionó.

Así piensa un buen compañero de equipo sobre una incidencia o un pull request. La IA simplemente hace más visible la necesidad de contexto explícito.

Un patrón de prompt que adoptar

Problema: [Impacto en la persona usuaria o el sistema.]
Evidencia: [Reproducción, prueba que falla, registros o comportamiento actual.]
Supuesto: [Lo que crees que puede estar ocurriendo.]
Alcance: [Qué se debe inspeccionar primero.]
Restricciones: [Qué no debe cambiar.]
Resultado: [Éxito observable.]
Validación: [Pruebas, ruta manual, medición, revisión.]

Analiza el comportamiento actual antes de editar. Cuestiona el supuesto y propone
el cambio más pequeño respaldado por la evidencia.

Empieza con cómo escribir mejores prompts para IA para conocer la estructura completa y después usa ingeniería de prompts para desarrolladores para adaptarla al trabajo de implementación, depuración y revisión. Para obtener una lista de comprobación de lo que sale mal cuando se omiten estos hábitos, lee errores de los asistentes de programación con IA y cómo evitarlos.

Para el trabajo basado en comandos, se aplica el mismo principio: verifica la entrada y la salida reales en lugar de adivinar el comportamiento de un script. Practica escenarios de línea de comandos en el navegador antes de escribir o revisar automatizaciones.