Una demo puede demostrar que un proyecto responde. Por sí sola no demuestra que la persona entendió el problema, eligió un límite razonable o comprobó qué ocurre cuando algo falla. Para evaluar un portafolio de ingeniero de software, sigue el camino entre lo que el proyecto afirma y la evidencia que otra persona puede inspeccionar.

El recorrido más útil tiene cuatro pasadas: problema, decisiones, verificación y límites. Después, pregunta por la autoría y los siguientes pasos. Así, un repositorio se convierte en una conversación técnica. No crea una nota universal para contratar a alguien ni sustituye una entrevista estructurada.

La guía sobre lo que debe demostrar un portafolio de software engineer con IA mira el mismo asunto desde el lado de quien publica el proyecto. Esta página responde otra pregunta: ¿qué puede confirmar un revisor sin adivinar?

Diagrama de un revisor que sigue el problema, las decisiones, la verificación y los límites de un portafolio de software.

Conclusiones rápidas

  • Empieza por el problema que el proyecto dice resolver, no por la cantidad de tecnologías.
  • Busca decisiones visibles y una contribución que la persona pueda explicar.
  • Comprueba que exista un camino reproducible para revisar comportamiento, fallos y datos.
  • Lee los límites como evidencia de criterio, no como defectos automáticos.
  • Usa el resultado para elegir mejores preguntas, no para inferir toda una carrera.

1. ¿El proyecto deja claro qué problema resuelve?

Lee el README antes de abrir el código. En pocas líneas deberías descubrir quién tiene el problema, qué comportamiento cambia y qué queda fuera del alcance. Si la primera pantalla es una lista de frameworks o un vídeo sin contexto, la revisión empieza con una carencia.

Un buen problema de portafolio no necesita ser empresarial ni tener usuarios reales. Sí debe ser lo bastante concreto para que puedas preguntar qué significa tener éxito. "Construí un chatbot" describe una tecnología. "Organicé los documentos de un equipo y rechazo una respuesta cuando no encuentro una fuente" ya señala la entrada, el comportamiento y el límite.

No conviertas la escala de producción en un requisito. Un proyecto personal puede usar pocos datos, ejecutarse solo en local o tener una interfaz sencilla. La pregunta es si el autor explica el alcance y sus consecuencias. La guía sobre habilidades de ingeniería de software para coding agents ayuda a separar la tecnología usada de la capacidad que el proyecto intenta demostrar.

Busca también la frase que define lo que el proyecto no resolverá. Lo que queda fuera no es papeleo. Muestra si el autor puede reducir una idea grande a un problema que se pueda construir y comprobar.

2. ¿Dónde aparecen las decisiones de ingeniería?

Cuando entiendas el problema, busca decisiones que podrían haber sido distintas. ¿Por qué existe una cola? ¿Por qué el estado vive en una base de datos? ¿Por qué se rechaza un permiso? ¿Por qué la aplicación devuelve una respuesta parcial en lugar de reintentar?

Una lista de herramientas no responde a esas preguntas. Busca un registro breve de decisiones, un diagrama, un commit explicativo o una sección del README que conecte una elección con un riesgo. No necesitas una arquitectura grande. Necesitas saber si la persona puede explicar el coste de una decisión.

Puedes seguir esta tabla durante la revisión:

Pregunta del revisor Evidencia que conviene buscar Pregunta de seguimiento
¿Cuál era el riesgo principal? problema, restricciones y alcance excluido ¿Qué ocurre si falla esa premisa?
¿Qué decisión protege ese riesgo? contrato, límite, diagrama o prueba ¿Qué alternativa descartaste?
¿Quién controla los efectos? permisos, datos, escrituras e integraciones ¿Qué sigue dependiendo de una persona?
¿Cómo se comprueba el cambio? prueba, fixture, eval, log o comando ¿Qué caso podría hacer fallar la prueba?
¿Qué sigue siendo desconocido? límites, trabajo futuro y riesgo residual ¿Cómo reducirías esa incertidumbre?

No des más peso a una decisión porque use una herramienta conocida. Un proyecto pequeño con un límite bien explicado puede mostrar más criterio que una arquitectura llena de componentes que el autor no puede defender.

3. ¿La prueba es ejecutable o solo descriptiva?

Busca un camino corto para comprobar el proyecto. Puede ser un comando de instalación, una fixture, una prueba, una captura de pantalla o un ejemplo de entrada y salida. El formato depende del proyecto. El requisito es que la afirmación principal pueda ser cuestionada.

En proyectos que usan modelos, no confundas una respuesta pulida con una evaluación. La documentación de evals de OpenAI modela una evaluación con datos de entrada, criterios de prueba y resultados. Puedes hacer la misma pregunta a un portafolio sin usar la API de OpenAI: ¿qué entrada se eligió, qué comportamiento se esperaba y dónde se registró el resultado?

Una buena prueba también muestra el fallo. Busca entradas vacías, permisos ausentes, timeouts, duplicados, respuestas inválidas o un caso que el proyecto reconoce que no resuelve. Un proyecto personal no necesita una suite completa. No debería depender de "abre el enlace y confía" como único camino.

Para un proyecto que usa coding agents, los evals de pull request en CI muestran cómo convertir la evidencia de revisión en un paso repetible. La versión del portafolio puede ser más pequeña, siempre que la entrada, el criterio y el resultado sean visibles.

Si el repositorio necesita una cuenta que no está disponible, un servicio de pago o una configuración que nadie puede repetir, regístralo como un límite de la evidencia. No concluyas automáticamente que el proyecto no funciona. Reduce solo lo que afirmas haber verificado.

4. ¿Cómo evaluar un proyecto creado con IA?

En un proyecto asistido por IA, la pregunta no es si la persona usó un modelo. Pregunta dónde conservó la responsabilidad: definición del problema, selección del contexto, revisión del diff, pruebas, integración y decisiones sobre riesgos.

El artículo de investigación When AI Can Build It, What Should We Assess? propone separar evidencias de producto, proceso y origen, verificación, explicación, reflexión y garantía individual en un curso de ingeniería permisivo con la IA. No es una rúbrica universal de contratación. Es una lente útil para no tratar el producto final como la única prueba.

Pide a la persona que elija un cambio pequeño y explique el recorrido. Debería poder decir:

  • qué solicitud recibió y qué parte delimitó;
  • qué contexto o fuente entregó al agente;
  • qué sugerencia rechazó o cambió;
  • qué prueba o inspección ejecutó después;
  • qué riesgo sigue sin estar demostrado.

No necesitas pedir la transcripción completa del agente. Un historial entero puede esconder la decisión importante entre demasiado texto. Un resumen fiel, un diff, una prueba y una explicación breve son más útiles. Si el proyecto usa Claude Code, Codex u otra herramienta durante sesiones largas, el autor puede usar RemoteCode como herramienta de trabajo. Eso describe su método, no demuestra que el proyecto sea bueno.

Evita la prueba injusta de pedir que la persona reconstruya todo el repositorio en directo. Si queda una duda, elige una parte del proyecto y pide un cambio limitado o un análisis de fallo. El objetivo es observar comprensión, no pedir trabajo gratuito.

5. ¿Qué dicen los límites sobre el proyecto?

Lee la sección de limitaciones antes de formarte una opinión. Un autor que escribe "no medí carga real" hace una afirmación más confiable que alguien que llama al proyecto listo para producción sin explicar observabilidad, datos o recuperación.

Separa tres cosas que suelen mezclarse:

  1. No implementado: el proyecto todavía no hace algo.
  2. No verificado: el proyecto hace algo, pero la evidencia disponible no lo cubre.
  3. Fuera del objetivo: el proyecto nunca pretendió resolver ese problema.

Esta separación lleva a mejores preguntas. Para una API personal quizá no necesites tráfico real. Para una aplicación que promete evitar la pérdida de datos, necesitas saber qué escenario se probó y cuál sigue siendo solo una intención. La evaluación debe respetar el problema que el proyecto eligió.

Revisa también la propiedad de los materiales. En un portafolio pueden aparecer código de tutorial, forks, trabajo en grupo, datos privados y ayuda de IA. Usar una base existente no es el problema. El problema es permitir que el revisor atribuya al autor un trabajo que el repositorio no demuestra. El README debe distinguir la contribución, las dependencias y las partes adaptadas.

6. ¿Cómo convertir la lectura en una conversación justa?

No sumes puntos como si el portafolio fuera una prueba estandarizada. Registra cuatro observaciones: qué está claro, qué sostiene la evidencia, qué sigue abierto y qué pregunta podría reducir la incertidumbre. Así evitas premiar el diseño, el tamaño del repositorio o la cantidad de commits sin entender el trabajo.

Una conversación puede empezar así:

  • "¿Qué parte cambiarías si la entrada se duplicara?"
  • "Muéstrame un caso en que la verificación falla o no es suficiente."
  • "¿Qué decisión fue más difícil de revisar después de la primera implementación?"
  • "¿Qué delegaste y qué tuviste que reescribir?"
  • "¿Qué afirmación sobre el proyecto todavía no harías?"

Haz preguntas proporcionales al proyecto. Un portafolio de nivel inicial no necesita las operaciones de un servicio comercial. En cambio, alguien que afirma haber construido un sistema resistente debe explicar recuperación, observabilidad y límites de la prueba.

Si la revisión forma parte de un proceso de selección, acuerda antes qué se observará y cuánto tiempo tendrá la persona. No conviertas el checklist en una tarea oculta. Si es una revisión entre colegas, devuelve preguntas y evidencias, no solo una impresión sobre la persona.

Checklist final para revisar un portafolio

Antes de terminar, comprueba si puedes completar cada fila sin inventar una respuesta:

Área ¿Puedes señalar...?
Problema la necesidad, el usuario u operador y el límite del proyecto?
Contribución qué construyó, adaptó, delegó o reutilizó la persona?
Decisiones una elección técnica ligada a un riesgo o requisito?
Verificación un comando, prueba, eval o ejemplo que pueda fallar?
Operación cómo trata errores, datos sensibles, acceso o recuperación?
Límites qué todavía no está implementado o demostrado?
Conversación una pregunta concreta que reduzca la incertidumbre?

Si varias celdas quedan vacías, no llenes el hueco con suposiciones. Di qué evidencia faltó y pide una explicación breve. El valor del checklist está en hacer visible la incertidumbre.

Conclusión

Evaluar un portafolio de ingeniero de software consiste en seguir la distancia entre lo que el proyecto afirma y lo que permite verificar. Empieza por el problema. Busca decisiones ligadas a riesgos. Ejecuta o lee una prueba. Después pregunta por autoría, límites y siguientes pasos.

Este método no convierte un repositorio en un veredicto sobre una carrera. Mejora la conversación y evita dos errores habituales: confundir una demo pulida con ingeniería y descartar un proyecto pequeño porque no parece un producto completo. La mejor revisión termina con una frase precisa sobre lo demostrado y una pregunta honesta sobre lo que todavía no lo está.

Cómo se produjo este artículo

Samuel Fajreldines es responsable editorial de este artículo. La investigación comparó el cluster existente del sitio, resultados actuales en portugués, inglés y español, conversaciones públicas recientes, documentación de GitHub y OpenAI, y una investigación sobre evaluación de ingeniería en contextos permisivos con IA. El checklist es una síntesis editorial. No es el resultado de un estudio de contratación, un benchmark de candidatos, una entrevista real ni una evaluación de empleadores.

La asistencia de IA ayudó a descubrir fuentes, comparar, redactar un primer borrador, localizar, crear la ilustración SVG y revisar la consistencia. No evaluó candidatos, no probó los portafolios de personas reales ni aportó experiencia profesional que el autor no haya demostrado.

Fuentes consultadas