Cómo contratar a un ingeniero Rails cuando la IA escribe el código

Para contratar a un ingeniero Rails en una startup, empieza por definir el producto y las tareas de mantenimiento que asumirá. Después, pide a cada candidato que haga un cambio acotado en una aplicación Rails existente. Valora si delimita bien el trabajo, protege los datos, escribe pruebas útiles y plantea un despliegue viable. Haz las mismas preguntas y usa los mismos criterios de evaluación observables tanto si escribe el código a mano como si utiliza IA.

La pregunta cobra fuerza tras el ensayo que Jared Norman publicó el 24 de septiembre, «What About Rails?». Norman cuestiona cuánto se habló de Rails en la ponencia inaugural de Rails World, mientras el código generado con IA y el cambio de tecnología de un producto destacado acaparaban la atención. Una conversación en Hacker News reunió opiniones contrapuestas de profesionales. Ni un ensayo ni un hilo de comentarios te dicen a quién contratar. Esa decisión depende de tu aplicación, sus riesgos y el trabajo que viene.

¿De qué se ocupa un ingeniero Rails en una startup pequeña?

En una startup pequeña, un ingeniero Rails se responsabiliza de un producto que debe seguir funcionando con el tiempo, no solo de entregar commits. Su trabajo puede abarcar peticiones, datos, interfaces, tareas en segundo plano, integraciones, pruebas, despliegues e incidencias en producción. Especifica cuáles de esos ámbitos asumirá realmente la persona contratada.

Imagina un equipo de dos ingenieros con una aplicación Rails en producción. Un cliente pide poder exportar sus datos. La función visible quizá sea un botón y un archivo. El trabajo de ingeniería incluye decidir quién puede solicitar la exportación, qué registros pertenecen a esa cuenta, qué ocurre con una solicitud grande, cómo se gestionan los fallos y cómo se despliega la función. Quien crea el botón pero no sabe explicar el límite entre cuentas se ha saltado la parte más delicada del trabajo.

Rails proporciona una estructura reconocible. La doctrina de Rails defiende las convenciones, los componentes integrados por defecto y la posibilidad de sustituirlos cuando convenga. Una buena contratación sabe seguir el recorrido habitual de la aplicación, del controlador al modelo y de ahí a la vista o a una tarea, y explicar por qué se apartaría de él. No tiene que exigir que todas las aplicaciones Rails sean idénticas. Las convenciones del equipo son decisiones tomadas dentro del framework, no reglas universales impuestas por él.

Esa responsabilidad incluye mantener la aplicación al día. A 27 de septiembre de 2026, el registro de versiones de Rails incluye la 8.1.4, publicada el 24 de septiembre. Según la política de mantenimiento de Rails, la rama 8.1.x recibe correcciones de errores hasta el 10 de octubre de 2026 y de seguridad hasta el 10 de octubre de 2027; la cobertura de seguridad de 8.0.x termina el 7 de noviembre de 2026. Estas fechas cambiarán. La cuestión duradera al contratar es si esa persona puede identificar la versión y las dependencias de la aplicación, planificar una actualización, probarla y recuperar el servicio si un despliegue falla.

Si todavía no tienes una aplicación Rails y el trabajo necesita otra plataforma, no conviertas la experiencia con Rails en un filtro de selección. La guía para contratar al primer ingeniero aborda las responsabilidades más amplias de esa primera incorporación.

¿Ha cambiado la IA la necesidad de contratar a alguien que conozca Rails?

La IA puede escribir el primer borrador de un cambio. Sigue haciendo falta alguien que decida si encaja en el producto, protege a los usuarios y resistirá el despliegue. Evalúa la forma de trabajar que esperas de la persona contratada.

Norman sostiene que la ponencia ofreció poca orientación sobre el futuro de Rails y cuestiona la idea de que ya no haga falta leer el código generado. Es su interpretación de una charla y del desarrollo asistido por IA, no la política de mantenimiento del proyecto. En su página Rails and AI, el propio proyecto afirma que los nombres, directorios, comandos y patrones habituales ayudan a los agentes a producir cambios acordes con Rails. También publica evaluaciones de tareas concretas, entre ellas solicitudes de funciones para Fizzy y ejercicios pequeños sobre API de Rails. Son pruebas del propio proyecto y de alcance limitado. No demuestran que un agente pueda mantener tu aplicación sin supervisión, ni que usarlo haga mejor o peor a un candidato.

Los comentarios de Hacker News tampoco coinciden sobre el valor y la facilidad de mantenimiento del código generado. Son experiencias individuales, no reglas para contratar.

En lugar de eso, pide al candidato que explique sus decisiones sobre el código generado. ¿Qué supuesto comprobó? ¿Qué propuesta descartó? ¿Puede seguir la ruta de autorización sin pedirle al agente que explique su propio diff? ¿Podría reducir el cambio a la mitad y seguir resolviendo la necesidad del usuario? Las preguntas sirven también para quien no utilizó IA. La revisión del trabajo se puede observar; una cifra de líneas escritas no la sustituye.

Si aún estás decidiendo si usar Rails, analiza las interfaces necesarias, el rendimiento, las integraciones, los sistemas existentes, la capacidad del equipo y el horizonte de mantenimiento. El cambio de tecnología de otro producto no decide tu arquitectura. Para una aplicación Rails ya en marcha, «responsable de esta base de código Rails» describe mejor la vacante que «experto en IA».

¿Qué conocimientos de Rails deben figurar en la oferta de empleo?

Enumera los conocimientos necesarios desde el primer día y sepáralos de las convenciones que una persona competente puede aprender al incorporarse. Así, los requisitos responden al trabajo real y la entrevista no premia la memorización de detalles del framework.

Empieza por un inventario concreto. ¿Qué versión de Rails utilizáis? ¿Dónde se comprueba el acceso a los datos de cada cuenta? ¿Las modificaciones suelen afectar a páginas renderizadas en el servidor, API, tareas en segundo plano o integraciones? ¿Quién despliega y analiza las incidencias? ¿Qué exige el plan de producto del próximo trimestre? Resume las respuestas en una descripción breve del puesto. La guía para contratar a un ingeniero full-stack puede ayudarte si el puesto combina frontend y backend; el título «ingeniero Rails» no define por sí solo ese equilibrio.

Para mantener una aplicación con varias cuentas de clientes, las competencias necesarias desde el primer día podrían ser:

• Seguir una petición o tarea en segundo plano hasta los datos que lee y modifica.
• Explicar cómo se aplican la autorización y el ámbito de la cuenta al cambio concreto.
• Añadir o adaptar una prueba de regresión útil, incluido un caso de error.
• Leer una migración y describir los riesgos del despliegue y de la recuperación.
• Seguir las convenciones de la base de código y explicar una alternativa más sencilla cuando exista.
• Comunicar las incertidumbres antes de modificar un comportamiento visible para el cliente.

Puedes exigir más soltura con Rails si esa persona tendrá que mantener la aplicación en solitario desde el principio. Indícalo claramente. Si el equipo puede acompañar a un buen ingeniero procedente de otro stack, valora su criterio transferible por encima de recordar el nombre de un método auxiliar. Los requisitos de experiencia deben reflejar el puesto, no las costumbres de quienes entrevistan.

Esta distinción sigue la guía de análisis del puesto de la OPM estadounidense, que relaciona las pruebas de selección con las tareas y competencias necesarias. La guía de la OPM sobre muestras de trabajo advierte asimismo contra evaluar conocimientos que se enseñarán tras la contratación. Son principios generales de selección de una entidad pública de Estados Unidos, no una lista de comprobación validada para startups que usan Rails.

¿Cómo evaluar el criterio con Rails sin recurrir a preguntas de memoria?

Entrega a los candidatos una aplicación Rails pequeña y ficticia, junto con un cambio parecido al que realizarían en el puesto. La prueba debe permitirles mostrar dónde ubicarían el comportamiento, cómo protegerían los datos y cómo verificarían el resultado. No debe ser una forma encubierta de resolver tareas pendientes de tu producto.

Este es un ejemplo original que conviene probar antes de usar, no una prueba de selección cuya eficacia esté demostrada. Una aplicación ficticia con dos cuentas ya tiene usuarios, registros de informes y una tarea en segundo plano. Un administrador quiere exportar los informes de su cuenta. El repositorio incluye instrucciones de instalación, datos de ejemplo, el esquema, pruebas existentes y un único comando para ejecutarlas. Da a todos el mismo material y una política explícita sobre IA y recursos externos.

No exijas una cola solo para comprobar si el candidato sabe usarla. En este ejemplo ya existe una tarea; puede aprovecharla si el comportamiento de la aplicación lo requiere. Quien explique por qué basta una ruta síncrona para una exportación pequeña y acotada puede mostrar mejor criterio que quien añade varias piezas nuevas. Por el contrario, quien ignore una restricción conocida sobre grandes volúmenes de datos debería justificarlo.

Pide a un ingeniero que pruebe el material, indica el tiempo estimado y comprueba la instalación desde un checkout limpio. Si el ejercicio se convierte en reparar dependencias, estarás midiendo la paciencia con tu entorno. Para un puesto orientado al frontend, sustituye el caso por un flujo de estados y errores con Hotwire; para uno de operaciones, por un escenario de despliegue o incidente. Evalúa el trabajo que has anunciado.

La guía de seguridad de Rails y la guía de pruebas de Rails ofrecen contexto técnico para revisar la solución. Los mecanismos del framework pueden reducir riesgos frecuentes, pero no responden por sí solos a si este administrador puede ver los informes de otra cuenta. Las pruebas permiten comprobar el comportamiento; el candidato debe identificar qué caso peligroso merece una prueba. El ejercicio aporta valor porque los revisores pueden comentar esas decisiones a partir de un diff real. No se ha validado como predictor del desempeño tras la contratación.

Si necesitas más orientación para delimitar el esfuerzo y redactar instrucciones claras, consulta la guía sobre ejercicios de código.

¿Qué deben preguntar y valorar los revisores?

Haz a todos los candidatos las mismas preguntas relacionadas con el puesto y valora lo observado según criterios escritos antes de entrevistar a nadie. La conversación posterior debe mostrar cómo razonaron sobre su cambio, incluido cualquier resultado generado con IA, en vez de premiar que reciten vocabulario de Rails.

Estas cinco preguntas sirven para el ejemplo de exportación:

1. ¿Dónde encaja este comportamiento en la aplicación existente y por qué lo situaste ahí?
2. ¿Qué límite entre cuentas o permisos te preocupa más? Muéstranos dónde se aplica.
3. ¿Qué regresión detectaría tu prueba más útil? ¿Qué queda sin probar?
4. ¿Qué comprobarías antes de desplegar y cómo recuperarías el servicio si fallara la exportación?
5. Si usaste IA, ¿qué sugerencia modificaste o descartaste y por qué? Si no la usaste, ¿qué otra opción consideraste y dejaste de lado?

Después, plantea a todos la misma ampliación hipotética: ahora las exportaciones se ejecutan de forma asíncrona y el administrador pierde el acceso a la cuenta antes de que empiece la ejecución. Pregunta qué debe cambiar, incluida la autorización al generar la exportación y al entregarla o descargarla. No hay una respuesta obligatoria de una sola línea. Observa si identifica el intervalo temporal, las consecuencias para el usuario y los dos puntos en los que debe comprobarse el acceso. También puede explicar que falta información para fijar una política definitiva. Saber decir qué datos hacen falta para decidir es una señal útil.

La guía de la OPM sobre entrevistas estructuradas recomienda preguntas predefinidas y relacionadas con el puesto, así como criterios comunes de evaluación. Las preguntas y los criterios de la tabla son propuestas de este artículo, no preguntas avaladas por la OPM. Pruébalos con el puesto concreto.

Valora lo observado, no la presentación. Los revisores deben anotar primero lo que vieron y después comentar juntos sus valoraciones. «Detectó la consulta sin limitar por cuenta y añadió una prueba entre cuentas» es una observación; «parece sénior» no lo es. Un candidato con otro diseño válido también puede obtener una valoración alta. Si el puesto permite expresamente aprender Rails tras incorporarse, no penalices a alguien por consultar la documentación de una API.

La investigación general sobre selección de personal, incluida la nueva evaluación de Sackett y sus colegas y su trabajo posterior, ayuda a entender las evaluaciones estructuradas en términos generales. No valida estos criterios para Rails, la política sobre IA ni la conversación posterior. Pruébalos y revísalos. La guía sobre cuadros de evaluación estructurados aborda el proceso de decisión más amplio.

¿Cómo mantener la prueba justa y útil con el tiempo?

Una muestra de trabajo solo sirve si los candidatos capacitados pueden hacerla en condiciones comparables. Publica el tiempo previsto, las reglas de uso de herramientas, los criterios de evaluación y el formato de entrega. Después, comprueba si los candidatos reales pueden participar en esas condiciones.

La política sobre IA forma parte del diseño de la prueba. Si tu equipo usa agentes en el trabajo, permitirlos en el ejercicio puede revelar cómo revisa sus resultados cada persona. Da a todos las mismas instrucciones sobre herramientas permitidas, tratamiento de datos y necesidad de servicios de pago. No exijas un registro de conversaciones con la IA como supuesto certificado de autoría. Pide a los candidatos que expliquen sus decisiones en la conversación posterior. Si prohíbes la IA para un puesto concreto, explica por qué esa restricción refleja el trabajo y aplícala por igual.

Prueba el ejercicio antes de utilizarlo. Pide a un ingeniero que lo complete desde un checkout limpio y anote los problemas de instalación y el tiempo real. Recorta lo que resulte demasiado largo. Ofrece otro formato o una adaptación cuando el formato habitual impida participar a una persona capacitada. Para empleadores de Estados Unidos, las orientaciones de la EEOC son un punto de partida sobre las obligaciones de adaptación; otras jurisdicciones tienen sus propias reglas. La promesa práctica es sencilla: los candidatos deben saber cómo solicitar un ajuste sin tener que explicarlo a todas las personas que los entrevistan.

Mantén actualizado el material como si fuera software. Fija o indica las versiones de Rails y Ruby, conserva las dependencias instalables, ejecuta el comando de pruebas en CI y elimina las pistas accidentales de los datos de ejemplo. Cuando cambie el puesto real, revisa la muestra y los criterios de evaluación. Observa si los candidatos abandonan o hacen una y otra vez la misma pregunta: quizá el material esté mal planteado, en lugar de que falten capacidades. No reutilices un ejercicio indefinidamente solo porque funcionó una vez.

Por último, deja tiempo suficiente a los revisores para leer el diff. Si el proceso solo premia que pasen las pruebas, pasarás por alto las decisiones que este artículo propone evaluar. Una conversación breve y uniforme puede sacar a la luz un supuesto oculto, pero no convierte a posteriori una mala muestra de trabajo en una prueba relacionada con el puesto.

¿Cómo organizar el proceso con Kit?

Kit puede coordinar la candidatura mientras tu equipo se ocupa de la evaluación. Su pipeline de contratación incluye ejercicios de código vinculados a GitHub, etapas separadas de entrevista y revisión del equipo, y criterios de puntuación en las etapas que admiten evaluación. Con esas funciones puedes gestionar un ejercicio probado, un plazo y una conversación humana sin fingir que el producto certifica el criterio con Rails.

Para un ejercicio de código, Kit crea un repositorio privado a partir de una plantilla de GitHub y establece un plazo. Añade a esa plantilla la aplicación ficticia y las instrucciones. Utiliza una etapa posterior de revisión o de muestra de trabajo para los criterios de evaluación y las observaciones sobre el diff. No conviertas la etapa del ejercicio en un juez automático de arquitectura o seguridad. Kit no crea esos criterios, no demuestra quién escribió cada línea y no realiza la conversación posterior por ti.

Kit es también una aplicación Rails. Sus páginas de contratación para personas utilizan Hotwire, mientras que herramientas MCP remotas y autenticadas ofrecen operaciones de contratación para agentes por otra vía. Es un ejemplo concreto de cómo ofrecer una interfaz de usuario y acceso para agentes a la vez. No demuestra que Rails sea el stack adecuado para todas las startups ni que la vía de los agentes sustituya la revisión humana.

El siguiente paso es pequeño: escribe una descripción del puesto de una página, prueba un cambio Rails acotado con tu equipo y acordad los criterios antes de invitar a los candidatos. Si buscas un lugar donde organizar el ejercicio y las revisiones posteriores, descubre Kit. Decidir qué hace un buen ingeniero en tu aplicación sigue siendo tarea de tu equipo.