El portafolio del ingeniero de IA: qué mostrar

Tu portafolio de ingeniero de IA no es una galería. Es una prueba. Un reclutador y un tech lead lo miran con una sola pregunta en mente: “¿esta persona llevó a producción algo que aguante datos reales y usuarios reales, o solo juntó tutoriales?”. En 2026 cualquiera sabe llamar a la API de un modelo. La diferencia está en la ingeniería que rodea esa llamada: evals, observabilidad, decisiones, compromisos. Este artículo trata de qué mostrar exactamente y, no menos importante, de qué no mostrar.

De tres a cuatro arquetipos de proyecto que de verdad demuestran nivel

No necesitas diez proyectos. Necesitas tres, quizá cuatro, que juntos cubran distintos ejes de competencia. Repetir el mismo tipo de proyecto (otro chatbot, otro “chat con un PDF”) no añade señal: multiplica el ruido.

• Una app RAG con evals. No solo “sube un documento, haz una pregunta”. Muestra el chunking, la elección de embeddings, el reranking y, sobre todo, un conjunto de evaluación: 30-50 pares pregunta-respuesta con métricas de faithfulness, context recall y answer relevance. Este único proyecto separa a un ingeniero de alguien que pega código de tutoriales.
• Un agente que hace una tarea real. No una demo de “un agente habla con otro agente”. Algo útil: triaje de tickets, pull requests automáticos con correcciones, investigación con citas. Muestra el bucle de herramientas, el manejo de errores de las herramientas, los límites (máximo de pasos, presupuesto de tokens) y qué pasa cuando el agente se atasca.
• Un fine-tune o un harness de evaluación. O bien ajustaste un modelo más pequeño para una tarea acotada y demuestras que supera al baseline en tu conjunto, o bien construiste una herramienta de evaluación que compara modelos/prompts con métricas definidas. Cualquiera de las dos cosas demuestra que entiendes cómo se mide la calidad, no solo cómo se proclama.
• Un producto lanzado y con usuarios. Aunque sea pequeño. Aunque tenga diez usuarios. Lo que cuenta es que viva en producción: un dominio, monitoreo, control de costos y un historial de lo que se rompió y de cómo lo arreglaste. Un proyecto así pesa más que cinco proyectos que nunca salieron de localhost.

Por qué los “wrappers” siguen contando si la ingeniería es real

Circula cierto esnobismo: “solo es un wrapper sobre la API de OpenAI”. Ignóralo. La mayor parte del valor de producto de la IA en 2026 está justo en la capa que rodea al modelo. La pregunta no es “¿es un wrapper?”, sino “¿es real la ingeniería que hay dentro del wrapper?”.

Ingeniería real dentro de un wrapper significa: una capa de evals que detecta regresiones en los prompts; caché y fallbacks entre proveedores; control de costos por petición; manejo de rate limits y reintentos con backoff; validación de la salida antes de que llegue al usuario; registro de trazas de cada llamada. Si muestras eso, el “wrapper” es una señal de ingeniería potente. Si tu código son tres líneas con una llamada y nada de esto, entonces sí, con razón lo llamarán demo.

README que muestran decisiones y compromisos

El README es el archivo más importante del repositorio desde el punto de vista de la contratación. Quien lo lee pasa ahí sus primeros treinta segundos y, en función de eso, decide si abre el código o no. Un README de “cómo ejecutarlo” es necesario, pero no suficiente. Añade una sección de decisiones.

• Problema y contexto. Dos frases: qué resuelve y para quién. Sin eso, quien lo lee no sabe si está ante un juguete o ante una herramienta.
• Decisiones de arquitectura. “Elegí pgvector en lugar de una base de datos vectorial dedicada porque la escala es de decenas de miles de vectores y así hay un servicio menos que operar.” Esa frase dice más que un diagrama.
• Compromisos que decidiste no asumir. “Descarté el reranking porque en mi conjunto de evaluación subía el recall un 2% a cambio de 300ms de latencia.” Esto demuestra que mediste en lugar de adivinar.
• Qué harías con más tiempo. Una breve sección de “próximos pasos” demuestra que ves los límites de tu propia solución.

Cómo demostrar evals y observabilidad

Hoy es la señal más escasa y la más potente. La mayoría de los proyectos de IA de portafolio no tienen ni un solo número. Si el tuyo lo tiene, juegas al instante en otra liga.

• Un conjunto de evaluación en el repositorio. Un archivo con casos de prueba (entrada, comportamiento esperado, métrica). Incluso treinta casos bastan para demostrar que piensas en términos de medición.
• Métricas, no sensaciones. “Faithfulness de 0.87 en un conjunto de 40 preguntas” en lugar de “funciona bastante bien”. Presenta los números como el resultado en un conjunto concreto, no como una verdad universal.
• Observabilidad. Demuestra que registras trazas (por ejemplo, con una herramienta como Langfuse o con un logger propio): costo por petición, latencia p95, número de tokens, versión del prompt. Una captura del dashboard en el README vale más que mil palabras.
• Un test de regresión de prompts. Demuestra que cambiar un prompt dispara el conjunto de evaluación en CI. Es una rareza que grita “esta persona ha trabajado en serio con LLM”.

Higiene en GitHub

Tu perfil de GitHub es tu tarjeta de presentación antes de que nadie lea tu CV. Tres cosas arruinan la impresión más rápido que ninguna otra: un node_modules subido al repo, secretos en el historial de commits y veinte repos esqueleto sin README. Haz limpieza.

1. Fija tus 3-4 mejores repositorios. El resto, hazlo privado o archívalo.
2. Commits descriptivos, no “wip” ×40. El historial de commits es una prueba de tu forma de pensar.
3. Cero secretos en el historial. Escanea el repo (por ejemplo, con gitleaks) antes de hacerlo público. Una API key en git log es una señal de alarma para cualquiera que contrate.
4. .gitignore, una licencia y un README limpio: higiene básica.
5. Un README de perfil con un solo párrafo: quién eres y en qué estás trabajando ahora.

Un sitio personal, y la escritura y la enseñanza como multiplicador

Un sitio personal no tiene que ser una obra de arte. Tiene que responder en treinta segundos: quién eres, qué construiste y cómo contactarte. Una lista de proyectos con una descripción de una frase y un enlace al repo y a la demo. Con eso basta.

El multiplicador es escribir y enseñar. Si cuentas cómo construiste el conjunto de evaluación de tu app RAG, o por qué abandonaste el fine-tune en favor de un prompt mejor, demuestras una profundidad que el repositorio por sí solo no puede transmitir. Un buen artículo técnico en un blog o un hilo con una conclusión de ingeniería real vale más que diez “reflexiones sobre la IA”. También es una señal de que sabes comunicar, una habilidad por la que los equipos pagan un plus.

Antipatrones que hunden un portafolio

• Clones de tutoriales. Si se reconoce el curso del que salió un proyecto, la señal es nula o negativa. Toma la idea de un tutorial, pero cambia el dominio, añade evals y ponlo en producción: entonces pasa a ser tuyo.
• Sin métricas. Un proyecto de IA sin un solo número equivale a decir “no sé si esto funciona”. Es el mayor error que se ve en los portafolios de IA.
• Sin despliegue. “Funciona en local” significa “nunca me enfrenté a costos, latencia, secretos ni rate limits”. Pon en producción al menos un proyecto.
• Solo notebooks. Un montón de archivos .ipynb sin ninguna aplicación sugiere a alguien que experimenta, no a un ingeniero. Convierte al menos un notebook en un servicio.
• Un README que pesa más que el código. Un README largo y generado sobre un proyecto vacío se percibe al instante como una fachada. Menos promesas y más código que funcione.

Una checklist concreta

1. 3-4 proyectos que cubran ejes distintos: RAG con evals, un agente, un fine-tune/harness y un producto lanzado.
2. Cada proyecto tiene un conjunto de evaluación en el repo y al menos una métrica con un número.
3. Al menos un proyecto vive en producción con su propio dominio.
4. Cada README tiene una sección de decisiones y compromisos, no solo instrucciones de ejecución.
5. La observabilidad está a la vista: costo por petición, latencia, versionado de prompts.
6. Perfil de GitHub limpio: 3-4 repos fijados, cero secretos, commits descriptivos.
7. Un sitio personal con una lista de proyectos y un contacto claro.
8. Al menos un artículo técnico que describa una decisión de ingeniería real.
9. Cero clones de tutoriales reconocibles por su nombre.

TL;DR

En 2026, el portafolio de un ingeniero de IA es una prueba, no una galería. Muestra 3-4 proyectos en ejes distintos: una app RAG con evals, un agente que hace una tarea real, un fine-tune o un harness de evaluación y al menos un producto lanzado. Los “wrappers” cuentan si hay ingeniería real alrededor de la llamada al modelo. Los README deben mostrar decisiones y compromisos. La señal más potente y más escasa son las evals y la observabilidad: números en lugar de sensaciones. Limpia tu GitHub, monta un sitio sencillo y escribe un buen artículo técnico. Evita los clones de tutoriales, la falta de métricas y la falta de despliegue.