Una historia honesta como desarrollador en solitario: el detonante, los tropiezos técnicos, la trampa clásica de todo fundador, y un hallazgo que no esperaba.
La conversación que lo empezó todo
Hace unos meses, un conocido me escribió por LinkedIn. Llevaba medio año buscando trabajo, actualizaba su CV todos los días, y no dejaba de quejarse del mercado y de los reclutadores. Le ofrecí ayuda: le pasé su CV a un reclutador que conozco. El rechazo llegó casi al instante — su experiencia no encajaba con el puesto. Y lo curioso es que él lo sabía perfectamente, lo habíamos hablado — pero eso no aparecía en su CV.
Se lo dije directamente. Me escuchó… y siguió quejándose del mercado y de los reclutadores.
Lo que me sorprendió no fue que culpara a factores externos — eso es de lo más normal. Lo que me sorprendió fue que no lograba conectar la causa con el efecto en una situación que acababa de pasar delante de sus propios ojos.
Y no fue un caso aislado. Empecé a notar un patrón: gente con experiencia real que pierde sistemáticamente en los procesos de selección — no porque sean malos profesionales, sino porque no saben describir ni presentar esa experiencia.
De dónde salió la idea
Yo mismo me preparaba para entrevistas usando distintos modelos de lenguaje. Funcionaba, pero con limitaciones molestas: los modelos perdían el contexto a mitad de la sesión, la calidad de las preguntas variaba de una vez a otra, y no había ninguna estructura de feedback.
Decidí unir dos herramientas en una: análisis de CV — para llegar a la entrevista — y un entrenador de entrevistas — para superarla. Cuatro modos: entrenamiento por stack y grado, por temas concretos, análisis profundo de la experiencia a partir del CV, y live coding al estilo de una entrevista real.
Formato: bot de Telegram. Sin registro, sin app nueva que instalar. Solo /start.
El primer tropiezo: CVs y GDPR
El primer problema técnico apareció donde menos lo esperaba: en el parseo de los CVs.
Desde el inicio tomé una decisión de principio — no guardar los archivos de los usuarios. Esto reduce el riesgo con datos personales, simplifica la arquitectura y elimina de raíz toda una categoría de preguntas sobre GDPR. El archivo se procesa, se extrae lo necesario, y se elimina.
El problema: al borrar los datos personales del texto, junto con nombres y contactos se estaban recortando también cargos y nombres de empresas. Las expresiones regulares o se pasaban de listas o dejaban cosas sin limpiar. Necesité varias iteraciones hasta que el comportamiento se volvió predecible.
La lección es simple pero útil: en procesamiento de texto, la solución "obvia" casi siempre rompe algo que no lo era.
La parte más difícil: encontrar el tono correcto
Técnicamente, el bot funcionaba con relativa fluidez. Lo verdaderamente difícil fue otra cosa.
Los modelos de lenguaje, en el rol de coach, tienden a comportarse todos igual: elogian cualquier respuesta, evitan la crítica directa, suavizan cada observación hasta que pierde sentido. Es agradable, pero inútil. Una entrevista real no funciona así.
Pero el extremo contrario — un análisis duro después de cada respuesta — tampoco era la solución. Desmotiva y no refleja el formato real.
Hice cientos de sesiones a mano: respondía yo mismo las preguntas y observaba cómo reaccionaba el bot ante distintos tipos de respuestas — completas, superficiales, parcialmente correctas, incorrectas pero dichas con total seguridad. Esto no se podía delegar: los agentes tienen sus propios patrones de comportamiento, no son usuarios reales.
Al final encontré el equilibrio: si la respuesta está incompleta, el bot hace una pregunta de seguimiento en vez de evaluar de inmediato, y el análisis final es concreto y sin rodeos, pero sin dureza innecesaria. Esto me llevó más tiempo que el resto de la parte técnica junta.
La trampa clásica en la que caí de todos modos
Hay un error que conoce cualquier desarrollador de producto con experiencia. Yo también lo conocía. Y aun así caí en él.
Funciona así: aparece una idea que parece obviamente buena. Tu cabeza ya visualiza cómo va a funcionar, cómo la gente la va a amar. No quieres parar — quieres construir. Y construyes.
Implementé varios bloques de funcionalidad que en su momento me parecían extensiones lógicas del producto. Los testers lo dejaron claro: no hace falta, satura, no se entiende. Todo eso tuvo que salir.
Lo más doloroso de eliminar fue la gamificación con logros: insignias por progreso, todo un sistema visual de recompensas. Los logros los había dibujado una diseñadora — a mano, uno para cada escenario. Preciosos.
Las pruebas mostraron que distraía del flujo principal y añadía complejidad justo donde no debía haberla. Lo eliminé.
Tengo la esperanza de retomarlo algún día, pero con otro enfoque: primero entender si los usuarios realmente lo necesitan, y solo después ponerse a dibujar.
El hallazgo que no estaba buscando
Durante las pruebas empecé a medir el consumo de tokens en distintos tipos de diálogo. Encontré algo que no esperaba: según el idioma en el que estuvieran escritas, las mismas instrucciones de sistema podían consumir entre un 18% y un 40% más tokens. Esperaba una diferencia de hasta un 20%, no tanto.
Esto se explica por cómo los tokenizadores de los modelos de lenguaje actuales manejan distintos alfabetos: hay idiomas cuyo texto, en promedio, se divide en más tokens que otros para transmitir el mismo contenido. Para mensajes cortos la diferencia es insignificante. Para prompts de sistema, que se envían en cada solicitud, se nota bastante.
Reescribí todas las instrucciones de sistema en el idioma más eficiente en tokens. Solo quedaron algunos ejemplos puntuales en otro idioma, donde la formulación exacta era importante. Los usuarios no notan nada de esto — el bot sigue generando las respuestas en el idioma de cada usuario de todas formas.
El momento que se me quedó grabado
Uno de los primeros usuarios reales me escribió después de varias sesiones:
«La verdad es que entrena muy bien dar respuestas más completas. Y también la habilidad de presentarte a ti mismo.» — Uno de los primeros usuarios
Esto no habla de las funciones del producto. Habla de que algo cambió en cómo esa persona piensa y habla sobre su trabajo. Era justo lo que quería lograr desde el principio — solo que no estaba seguro de conseguirlo.
Lo que sé ahora
Algunas cosas que no esperaba aprender en el camino:
- La parte más difícil de un producto con IA no es la arquitectura ni los prompts. Es encontrar el tono correcto entre la honestidad y la dureza. Eso no se le puede enseñar al modelo directamente — solo se llega ahí iterando a mano.
- Las decisiones tomadas por principio suelen resultar técnicamente correctas. No guardar los archivos de los usuarios no es solo una cuestión de seguridad — es simplicidad arquitectónica.
- Detenerte y eliminar algo en lo que invertiste tiempo es una habilidad. No llega sola, aunque hayas leído sobre ella mil veces.
- El primer feedback real vale más que cualquier analítica al inicio. Es lo que te dice si diste con una necesidad real o no.
