Contrata a un desarrollador para arreglar código generado por IA: preguntas de entrevista

Qué falla con el código generado por IA en proyectos reales

Las apps generadas por IA suelen verse bien en una demo porque el camino feliz funciona. El problema llega cuando los usuarios reales hacen cosas reales: se registran dos veces, restablecen una contraseña, pegan entradas extrañas, abren la app en una red lenta o la prueban desde otro dispositivo. Muchos prototipos creados con IA están cosidos rápido, así que el primer caso límite puede romper un flujo clave.

Los fallos comunes son fáciles de identificar cuando sabes dónde mirar. La autenticación es uno importante: el login funciona localmente y luego falla tras el despliegue, o los roles y las sesiones se comportan de forma inconsistente. Otro problema clásico son secretos expuestos, como claves API en código cliente o cometidas en el repo. La lógica a menudo es frágil también: un total de checkout se calcula en dos sitios, un webhook se ejecuta dos veces, o los errores se tragan y terminas con corrupción silenciosa de datos en lugar de un fallo claro.

Síntomas que suelen significar que el código necesita una reparación real (no pequeños ajustes):

• La autenticación y permisos parecen aleatorios (los usuarios ven cosas que no deberían)
• Los secretos están hardcodeados o compartidos entre entornos
• Cambios en un área rompen funciones no relacionadas
• El manejo de datos es inconsistente (duplicados, actualizaciones faltantes, escrituras parciales)
• La app funciona localmente pero falla tras el despliegue

Para lo que estás contratando no es “alguien que añada funciones”. Necesitas a alguien que pueda diagnosticar rápido, explicar qué ocurre y aplicar arreglos seguros sin crear nuevos problemas. Eso implica leer código desconocido, rastrear solicitudes de extremo a extremo, escribir algunas pruebas o comprobaciones dirigidas y mejorar la estructura para que la siguiente corrección sea más fácil.

La rapidez importa, pero velocidad sin corrección convierte prototipos en retrabajos sin fin. Fija expectativas desde el principio: pide un diagnóstico inicial primero y luego un plan de reparación con prioridades. Un buen desarrollador separa arreglos de “detener la hemorragia” (agujeros de seguridad, auth rota, pérdida de datos) del trabajo de “mejorarlo” (refactors, limpieza). Si quieres rapidez, sé claro sobre dónde son aceptables los acabados toscos y dónde no (seguridad, pagos, datos de usuarios).

Antes de la entrevista: define el trabajo que realmente necesitas

Si quieres contratar a un desarrollador para arreglar código generado por IA, no empieces con una oferta genérica. Empieza por escribir qué significa “hecho” para tu proyecto. Sin eso, las entrevistas se convierten en batallas de opinión en vez de una decisión clara sí/no.

Define “hecho” en resultados, no en sensaciones. Para un repo desordenado, “hecho” suele significar que los flujos principales funcionan, hay comprobaciones de seguridad básicas y puedes desplegar sin sorpresas.

Un objetivo simple es listar lo que debe ser cierto cuando el trabajo esté terminado. Manténlo práctico: los recorridos clave de usuario funcionan de extremo a extremo, las rutas de mayor riesgo tienen al menos una pequeña red de seguridad con pruebas, los secretos no están expuestos, los pasos de despliegue son repetibles (no “funciona en mi máquina”) y el código es lo bastante legible para que otro desarrollador continúe.

Luego confirma si el trabajo es realmente “reparar” y no “reconstruir”. Las apps generadas por IA pueden parecer completas pero esconder problemas profundos (estructura enredada, estado frágil, autenticación rota). Decide qué aceptarás: un parche que estabilice el código actual o una reescritura parcial de las partes más riesgosas.

También decide qué tipo de desarrollador necesitas: alguien cómodo con código que no escribió. Puedes filtrar esto antes de la entrevista pidiéndoles que describan sus primeras 48 horas en un repo desordenado. Busca un plan que empiece por diagnóstico (ejecutarlo, reproducir errores, leer logs), luego añada seguridad (tests, backups, cambios pequeños), no grandes refactors el primer día.

Finalmente, fija expectativas sobre cómo comunican el riesgo. Quieres a alguien que pueda decir: “No estoy seguro aún. Esto es lo que voy a comprobar a continuación y esto es lo que puede cambiar la estimación”.

Preguntas de entrevista que revelan su enfoque de depuración

No estás contratando por ingenio. Contratas por una forma repetible de encontrar la causa real, incluso cuando el código es un desastre.

Pide sus primeros cinco pasos después de un informe de bug crítico. Escucharás un plan calmado y ordenado (reunir hechos, reproducir, reducir el alcance), no “empezaría a cambiar cosas”. Los candidatos fuertes mencionan confirmar el impacto, capturar la salida exacta del error y comprobar cambios recientes.

Prompts que exponen su forma de trabajar:

• “Un usuario dice que el checkout falla. ¿Cuáles son tus primeros 5 pasos, en orden?”
• “¿Cómo reproduces un bug cuando el reporte es vago? ¿Qué detalles pides?”
• “¿Cómo aislas el caso fallante más pequeño, y por qué importa eso?”
• “¿A qué recurres primero: logs, breakpoints, tests, tracing? ¿Cuándo cambias de herramienta?”

Después de que respondan, pídeles que detallen un ejemplo real. Por ejemplo: la app funciona localmente, pero en producción los usuarios se desloguean aleatoriamente. Un buen depurador hablará de comparar entornos, revisar cookies y sesiones, buscar timeouts y añadir logging dirigido con una hipótesis clara.

La pregunta más reveladora es qué hacen cuando no pueden reproducir el bug. Busca respuestas como: mejorar la observabilidad (mejores logs, traces), crear una prueba mínima, reducir el riesgo con un guard o feature flag y construir una lista corta de hipótesis para confirmar o eliminar. Si dicen “seguiría probando cosas”, es una señal de alarma en bases de código frágiles generadas por IA donde un “arreglo pequeño” puede romper tres flujos más.

Si quieres una verificación rápida, pídeles que expliquen su enfoque en lenguaje llano, como si actualizaran a un fundador no técnico al final del día. Las actualizaciones claras suelen coincidir con depuración disciplinada.

Preguntas que ponen a prueba cómo manejan la incertidumbre y el fallo

El código generado por IA tiene la habilidad de estar equivocado con gran seguridad. Necesitas a alguien que pueda admitir que se equivocó, cambiar de rumbo rápido y dejar el sistema más seguro de lo que lo encontró.

Esta parte de la entrevista no trata de respuestas perfectas. Trata de cómo reaccionan cuando la realidad no coincide con su primera teoría.

Pide una historia real de fallo (y hazla específica)

Forza el detalle, no una historia de éxito pulida:

• “Cuéntame sobre un bug que diagnosticaste mal al principio. ¿Qué pensabas que era y qué resultó ser realmente?”
• “¿Qué señal te hizo cambiar de opinión?”
• “¿Qué hiciste primero para reducir el riesgo mientras aún estabas inseguro?”
• “¿Cómo confirmaste la corrección y cómo te aseguraste de que no rompiera algo cercano?”

Si se mantienen vagos, sigue con: “¿Cuál fue el experimento más pequeño que ejecutaste para probar o refutar tu teoría?”

Un ejemplo realista: el login de una app falla “aleatoriamente”. Un candidato débil culpa a “auth es inestable” y prueba nuevas librerías. Uno fuerte explica cómo lo reprodujo, detectó expiración de token o deriva de reloj y lo probó con una o dos comprobaciones dirigidas.

Qué suenan como buenas respuestas

Escucha hábitos de los que puedas fiarte. Los buenos candidatos describen una línea de tiempo (hipótesis, prueba, resultado, siguiente paso), nombran la evidencia que cambió su mente y hablan de contención (planes de rollback, guardias temporales). También previenen repeticiones con una prueba pequeña, una nota de causa raíz o una alerta de monitorización.

Si no pueden explicar un error sin culpar a otros, o dicen que “nunca se equivocan”, es una señal de alarma. Depurar código desordenado es incertidumbre y los mejores se mantienen tranquilos y metódicos.

Hábitos de seguridad: preguntas que sacan prácticas reales

La seguridad suele ser donde “funciona en mi máquina” se convierte en riesgo real. Quieres hábitos repetibles, no promesas.

Empieza por autenticación y sesiones. Las apps hechas con IA a menudo mezclan patrones (cookies, JWTs, localStorage) y dejan huecos.

Preguntas que exponen práctica real rápidamente:

• “Cuando abres un nuevo codebase, ¿qué revisas primero en auth y manejo de sesiones?” Escucha detalles: flags de cookie (HttpOnly, Secure, SameSite), expiración de sesión, flujos de refresh y dónde se almacenan tokens.
• “Muéstrame cómo encontrarías secretos expuestos y configuración insegura.” Buenas respuestas incluyen escaneo de archivos .env comprometidos y claves en el repo, además de un plan para rotación y prevención de reintroducción.
• “¿Cómo previenes inyección SQL y consultas inseguras aquí?” Debes oír consultas parametrizadas, patrones seguros de ORM y validación de entrada. Si dicen “solo saneo entradas”, pregunta cómo, exactamente.
• “¿Cuál es tu rutina de actualización de dependencias en un proyecto desordenado?” Respuestas sólidas hablan de lockfiles, herramientas de auditoría y un plan de pruebas tras upgrades.

Un seguimiento útil: “Explica la compensación entre velocidad y seguridad en esta corrección.” Por ejemplo, si un prototipo guarda JWTs en localStorage, un buen ingeniero puede explicar por qué moverlos a cookies HttpOnly reduce el impacto de XSS y qué cambia en el frontend.

Señales de alarma que suenan confiadas pero vagas: no pueden nombrar comprobaciones concretas para sesiones y almacenamiento de tokens; tratan la validación de entrada como la solución completa a la inyección SQL; minimizan el riesgo de dependencias porque “es solo un prototipo”; o evitan hablar de rotación de secretos tras una filtración.

Cómo explican las compensaciones en lenguaje llano

No solo contratas habilidad de codificar. Contratas criterio. Los mejores candidatos pueden decirte qué hacen, por qué lo hacen y qué ganas (y pierdes) con cada opción.

Una prueba simple: pídeles que expliquen la misma decisión dos veces, una como si fueras desarrollador y otra como si fueras un fundador ocupado que solo quiere riesgo y coste en palabras sencillas. Si no pueden cambiar de registro, te costará tomar buenas decisiones juntos.

Parche rápido vs refactor adecuado

Dales un tipo de bug real (auth rota, crashes aleatorios, pagos fallando) y pídeles comparar un parche rápido con una corrección profunda. Escucha cómo describen el riesgo y si incluyen un paso de seguridad como tests, logging o un plan de rollback.

Prompts útiles:

• “Si enviamos un parche rápido hoy, ¿qué puede romper la próxima semana?”
• “¿Qué te haría parar y decir: esto necesita refactor, no parche?”
• “¿Cómo probarías que la corrección funciona sin confiar en la buena suerte?”

Reescribir vs reparar y cómo documentan decisiones

El código generado por IA suele funcionar hasta que llega tráfico real. Pregunta cómo deciden reescribir un módulo o repararlo. Los candidatos fuertes usan señales como límites poco claros, dependencias enredadas, lógica copiada varias veces o riesgo de seguridad difícil de contener.

Pide un ejemplo concreto: “Si el módulo de perfil de usuario es spaghetti, ¿qué harías en las primeras 48 horas?” Un buen plan suele ser: aislar el módulo, añadir algunas pruebas, refactorizar en pasos pequeños y vigilar rendimiento para no crear páginas lentas o sorpresas de escalado.

Finalmente, pregunta cómo dejan por escrito las decisiones para que gente no técnica las entienda. Busca notas cortas de decisión: qué cambió, qué no cambió (todavía), riesgos y siguientes pasos.

Un escenario realista para repasar en la entrevista

Usa una historia pequeña y concreta y pídeles que hablen en voz alta.

Escenario: tras una actualización de una herramienta de IA, los usuarios no pueden iniciar sesión. La app muestra “Sesión inválida” incluso con la contraseña correcta. Ayer funcionaba. Ahora el soporte acumula tickets.

Primero, escucha las preguntas que hagan antes de tocar el código. Los candidatos fuertes piden lo básico: qué cambió (deploy, vars de entorno, actualización de dependencias), si afecta a todos los usuarios o a un subconjunto, logs o traces, qué método de auth usan (cookies, JWT, OAuth) y si se rotaron secretos o claves. Extra si preguntan por riesgo: “¿Los usuarios están bloqueados o las sesiones se aceptan incorrectamente?”

Luego pídeles que se pongan un límite de tiempo. El plan debe sonar a checklist, no a conjeturas:

• Primera hora: reproducir el bug, capturar una petición/respuesta fallida, examinar diffs recientes, comprobar la configuración (dominio de cookie, CORS, URL de callback, almacén de sesiones).
• Primer día: trazar todo el flujo de login, añadir logging temporal alrededor de la creación y validación de sesiones, escribir una prueba pequeña que demuestre la falla.
• Una vez estable: refactorizar las partes frágiles, eliminar acoplamientos ocultos, añadir monitorización y documentar lo cambiado para que no vuelva a ocurrir.

A continuación, pregunta cómo confirman la corrección. Buenas respuestas incluyen un paso reproducible, pruebas para casos de éxito y fallo, y un plan de rollback. También deben mencionar prevenir repeticiones (fijar versiones, comprobaciones de config más seguras, reglas básicas de code review).

Finalmente, presiona sobre las compensaciones: ¿qué enviarían ahora vs qué programarían para después? Quieres a alguien que proteja a los usuarios hoy sin enterrarte en deuda técnica futura.

Errores comunes al entrevistar para reparación de código desordenado

Los mayores fallos en entrevistas ocurren cuando la conversación se mantiene abstracta. Quieres detalles: qué miran primero, qué miden y qué hacen cuando se equivocan.

Un error es hacer preguntas que premian la confianza, no la claridad. Si preguntas “¿Puedes limpiar esto?”, casi cualquiera dirá “sí”. En su lugar, insiste en lo específico: qué señales indican que el bug está en datos, auth o estado y qué evidencia recogerían antes de tocar el código.

Otro fallo es centrarse demasiado en frameworks. Un candidato que habla solo de reescribir en la última pila puede estar evitando el trabajo real: leer código extraño, trazar solicitudes y reducir riesgo.

Señales de alarma:

• Su plan de depuración es básicamente “añadir console logs” (sin mencionar reproducción, acotar entradas, logs y traces).
• Descartan las pruebas como “para después” y no hablan de una red de seguridad antes de refactors.
• Dan un plazo firme sin pedir ver el repo, la configuración y el despliegue.
• Se niegan a explicar decisiones en lenguaje llano o se molestan con preguntas de “por qué”.

Los plazos son una trampa especial. Los ingenieros fuertes dan rangos y un plan, no promesas. “Día uno: reproducir y mapear el flujo. Día dos: arreglar las causas principales y añadir pruebas. Luego reevaluar” es más creíble que un plazo garantizado sin revisar el código.

Lista rápida: señales de que encontraste a la persona correcta

Tras una breve revisión, un candidato fuerte puede decirte qué está mirando y por qué falla. No necesitan certeza perfecta, pero deben poder resumir la base de código en términos claros: qué hace la app, dónde están los flujos principales (login, pagos, subidas, admin) y qué parece fuera de lugar (vars faltantes, modelo de datos confuso, lógica duplicada).

Tampoco saltan directamente a reescrituras. El patrón ideal es: “Primero haré una auditoría rápida, luego te doy una lista de arreglos priorizada.” Esa lista debe ordenarse por impacto y riesgo, no por lo que les apetece limpiar.

Escucha por hábitos de producción, no promesas vagas. Deben mencionar pruebas para caminos rotos, un entorno de staging, un plan de rollback y monitorización básica (incluso logs y alertas simples). Deben hablar de cómo demostrarán que el arreglo funcionó, no solo de cómo lo implementarán.

La seguridad es otro indicador rápido. Un buen candidato detecta riesgos sin pistas: secretos expuestos, controles de auth débiles, construcción insegura de SQL, falta de validación de entrada o CORS demasiado abierto.

También pregunta cómo planifican la semana de trabajo: quieres check-ins claros y entregables que entiendas, como una lista corta de problemas principales con severidad, lo que se envió, lo siguiente y lo bloqueado.

Próximos pasos: haz una pequeña prueba y establece un plan de reparación claro

No te lances a una gran reescritura. Con código desordenado generado por IA aprendes más con una pequeña prueba pagada que con otra hora de conversación. El objetivo es ver cómo piensan, cómo comunican y si dejan el código más seguro que como lo encontraron.

Mantén la prueba pequeña pero real: un bug visible para el usuario, una corrección de seguridad y una prueba simple para afianzar el cambio. Por ejemplo: “El login a veces falla”, “eliminar un secreto expuesto del repo y rotarlo” y “añadir una prueba básica para el flujo de login”. Un alcance ajustado te deja juzgar resultados en uno o dos días.

Antes de empezar, pon por escrito qué significa “hecho” y qué recibirás. Debes ver una explicación corta de lo que cambió y por qué, notas sobre actualizaciones de config o entorno y un plan de despliegue simple que incluya cómo verificar y cómo revertir.

Si no tienes tiempo para evaluar candidatos a fondo, un enfoque de auditoría primero aún puede avanzar. FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar apps generadas por IA desde herramientas como Lovable, Bolt, v0, Cursor y Replit, y comienza con una auditoría de código gratuita para que veas problemas concretos y prioridades antes de comprometerte a una reescritura.