Introducción#
Cada mañana abría el correo con una sensación conocida: demasiados mensajes, demasiado ruido y cero ganas de abrir Gmail; necesitaba una forma de separar el grano de la paja en segundos.
GizTUI nació de una necesidad muy concreta: gestionar mi correo, pero sobre todo hacerlo de forma extremadamente rápida, separando el grano de la paja en segundos y adaptado a mi flujo de trabajo. En mi día a día recibo mucho más de lo que envío; mi problema no es tanto componer correos como consumir información y organizarla sin perder tiempo.
La revolución de la IA en programación no está solo en acelerar tareas, sino en que ha tirado por los suelos los costes de desarrollo. Eso cambia las reglas del juego: ahora puedes permitirte hacer desarrollos de usar y tirar, construir herramientas hiperpersonalizadas a tus necesidades en cuestión de horas, y refinar sobre la marcha. Esa combinación, costes mínimos + personalización extrema, es lo que realmente lleva la productividad a otro nivel.
No soy ingeniero de software. GizTUI no pretende ser “producto” en sentido estricto, sino un proyecto de aprendizaje acelerado. Aun así, ha acabado teniendo bastante pegada: resúmenes de correo y procesamiento IA en local (u otros providers como Bedrock), búsquedas avanzadas con queries guardadas, gestión ágil de etiquetas y movimiento de mensajes, atajos de teclado estilo Vim que multiplican la velocidad, e incluso la posibilidad de responder invitaciones de calendario sin salir de la terminal.
Y como guinda, las integraciones con Slack y Obsidian, que convierten al cliente en parte natural de mi flujo diario de trabajo.
Why: por qué me metí en esto#
Permitidme daros un poco de contexto y algunas condiciones de contorno que os ayudarán a entender mejor este proyecto. En mi empresa, el terreno de juego está bastante acotado: solo está permitido usar el cliente nativo de Gmail, IMAP está deshabilitado por políticas de administración de Google Workspace, y clientes clásicos como neomutt o alpine no funcionan correctamente con la API de Gmail.
A todo esto hay que sumarle un factor personal: siempre he sido un geek del terminal, muy fan de herramientas como k9s o el propio VIM. La idea de tener un cliente de correo en la terminal no era solo un capricho estético, sino una forma de trabajar que encajaba conmigo.
Y, sobre todo, buscaba un espacio de aprendizaje práctico. Para mí, el “hands-on learning” es la manera más efectiva de asimilar nuevas ideas. Quería un proyecto que no fuese un juguete trivial, sino algo que resolviera un problema real de mi día a día y que me obligara a aprender en el proceso. GizTUI acabó siendo exactamente eso.
Productividad: iteración que engancha#
Este proyecto me llevó unas cuatro semanas de trabajo y terminó con más de 400 commits. Para ponerlo en perspectiva: si hubiera intentado hacerlo por mi cuenta, sin ayuda de la IA, probablemente me habría llevado un año entero, y eso suponiendo que hubiera tenido la constancia de no abandonarlo por el camino.
La adicción a la velocidad#
Esa es la primera gran conclusión: la productividad adictiva que te da la IA. Te acostumbras a un ritmo de avance tan alto que volver atrás parece imposible.
En mi caso, lo noté sobre todo en dos áreas:
- Los atajos estilo Vim aplicados en modo bulk (ej. d3d, a5a), que convirtieron tareas repetitivas en gestos mínimos.
- El acceso directo a la librería de prompts, que me permitió aplicar resúmenes, análisis y acciones en cadena con una rapidez brutal.
Además, durante el proceso de desarrollo, la IA no solo ejecutaba: también me hacía buenas preguntas. Preguntas que me ayudaban tanto a entender mejor el problema como a plantear soluciones más avanzadas de las que yo mismo hubiera imaginado de primeras.
UI: el infierno necesario#
No todo fue un camino de rosas. La UI fue tediosa: definir interacciones, estados y layouts llevó muchas iteraciones, y las pruebas fueron especialmente pesadas. Aquí la multimodalidad ayudó mucho: poder pasar capturas de pantalla al modelo para señalar desalineados, recortes o comportamientos inesperados aceleró el diagnóstico y me permitió pedir cambios muy concretos (“ajusta el background de este panel”, o “mira cómo se corta este widget”).
En la práctica, adjuntar imágenes para anclar el contexto visual reduce ambigüedad y evita desvaríos del modelo, sobre todo cuando el problema es puramente de presentación. Este flujo funciona tanto con Claude (visión) como con otros modelos multimodales modernos, y marca la diferencia cuando estás puliendo detalles de UX.
Vigilar al copiloto#
Además, hay un punto clave al trabajar con un modelo: tienes que vigilarlo de cerca. Al principio, la velocidad a la que progresa es tal que cuesta seguirle el ritmo y entender todo lo que va modificando. Y en mi caso, que no soy un gurú de la programación, eso significaba aceptar ciertos cambios casi por fe.
Claro que, cuando el modelo se encuentra con un reto que no sabe resolver, la situación se invierte: ahí tienes que ser tú quien lo ayude a hacer troubleshooting. Afortunadamente, esto no me pillaba de nuevas: en mis roles anteriores, como responsable de equipos de delivery, mi pan de cada día era precisamente ayudar a programadores a entender de dónde venían los problemas. Esa experiencia fue clave para no perderme en los callejones sin salida del modelo.
Vibe Coding: programar acompañado#
Durante el desarrollo de GizTUI utilicé principalmente dos herramientas: Cursor y Claude Code. Aunque, cuando estaba trabajando dentro de Cursor, casi siempre prefería usarlo con el modelo de Claude, al menos hasta que se me acababan los tokens y tenía que pasar al modo automático. También probé con el GPT-5 de OpenAI, y aunque es verdad que se nota que es algo más “espabilado”, la diferencia no me pareció espectacular como para cambiar mis flujos principales.
¿Por qué Cursor? Porque está muy bien integrado en el IDE y, para otros flujos de trabajo, me resulta una herramienta con una relación calidad-precio difícil de batir. Con Cursor puedes ver los cambios directamente en los ficheros, aprobarlos, modificarlos o revertirlos de una forma muy natural. En términos de UX integrada, Cursor me parece que todavía está un paso por delante.
Pero gracias a un consejo de un amigo (gracias, Víctor 🙌), le di una oportunidad a Claude Code y no me decepcionó. Eso sí, enseguida comprobé que la suscripción Pro se queda corta si quieres hacer algo medianamente serio. Al final pasé al plan Claude Code Max (100€/mes) para poder trabajar con continuidad. Ahora me toca valorar si mantengo la inversión, porque tampoco soy un “hard developer” en el sentido clásico.
Lo que más me gustó de Claude Code fue su modelo de configuración con Claude.MD ( documentación), que me parece mucho más intuitivo que el sistema de scopes que utiliza Cursor con las reglas .mdc. En mi caso incluso preparé dos custom commands que se pueden ver en el repo:
- feature-implement: con todo lo que debe tener en cuenta cuando le pido implementar una funcionalidad.
- feature-debug: con las mejores prácticas que recopilé para depurar bien.
Respecto a las reglas, tanto en Cursor como en Claude.MD me pasa lo mismo: cuando las hago largas o demasiado detalladas, la consistencia se resiente. No siempre consigo que se cumplan todas las instrucciones al pie de la letra, lo cual obliga a iterar.
En cuanto a comparativa general, mi sensación es:
- Claude Code: más eficiente y consistente en términos de desarrollo.
- Cursor: mejor experiencia de usuario integrada en el IDE.
Ingeniería de software: disciplina en la era de la IA#
Construir GizTUI me recordó algo fundamental: aunque trabajes con IA, separar diseño de implementación sigue siendo clave. Antes de tocar una sola línea, hay que entender bien el espacio del problema, definir una solución razonable y solo después entrar en la fase de implementación.
¿Por qué? Porque en modo fluido, si no sabes cuál es el plan del LLM para resolver el reto que le has puesto delante, corres el riesgo de que se vaya por los cerros de Úbeda y te entregue algo que no necesitas. Un ejemplo concreto: tenía un problema con emojis que ocupaban más espacio de lo normal y descolocaban la pantalla. Lo razonable era sustituirlos por otros más seguros. El modelo, en cambio, se lanzó a crear un sistema de validaciones y funciones que complicaban el código innecesariamente. Sin plan, la soluciones pueden ser un poco overkill.
Planificación asistida por LLMs#
Mi contramedida a esto fue usar la planificación asistida por IAs como disciplina:
- En Cursor, pidiéndole al modelo que me explique lo que ha entendido y qué va a hacer.
- En Claude Code, aprovechando el modo de planificación con Shift+TAB.
- Para funcionalidades grandes, le pedía que escribiera el plan en un fichero (ej. FEATURE_X.md) para luego validar que no quedaban cosas a medias.
- Junto al plan, también le exigía un test plan: así podía ponerme el gorro de QA y validar la funcionalidad (más sobre esto en los siguientes párrafos).
Esto evitó perder el rumbo cuando, entre iteraciones, pruebas y correcciones, el contexto original se diluía.
Documentación viva#
Para luchar contra el arms of chaos, creé una serie de documentos de referencia,desde ARCHITECTURE.md hasta TESTING.md o KNOWN_ISSUES.md, que funcionaban como un registro de decisiones de arquitectura. Aunque la IA no siempre los tuvo en cuenta (curvas del olvido), servían como documentación viva y punto de anclaje en refactors posteriores.
TODO.md como pulso del proyecto#
Un hábito que me resultó clave fue mantener un TODO.md. No era solo una lista de tareas, sino una especie de roadmap vivo: lo que quería, lo que faltaba, lo que aparcaba. Ese fichero funcionó como brújula del proyecto y me dio claridad en medio del caos natural del desarrollo asistido por IA.
Commits y ramas#
Otro hábito que se volvió imprescindible: semantic commits y una rama por feature. Prefiero ir comiteando con cada tirada de codigo y luego iterar. De lo contrario, en mitad de un troubleshooting puedes ensuciar el código y, al volver atrás, ya no hay un estado limpio. Con commits pequeños y reversibles, pude retomar el camino correcto sin dramas.
Refactorización y deuda técnica#
De vez en cuando hay que dar un paso atrás y pedirle al modelo que vuelva a analizar el repositorio para detectar mejoras y deuda técnica acumulada. Hacia el final del proyecto, esto lo reforcé con agentes especializados en Claude, cada uno con un rol concreto:
- architecture-validator: revisa arquitectura y separación de responsabilidades.
- config-consistency-maintainer: asegura coherencia entre configs, docs y ejemplos.
- feature-documentation-validator: verifica que cada feature está bien documentada.
- feature-parity-validator: comprueba paridad entre atajos de teclado y comandos.
- test-generator: genera suites completas de pruebas (unitarias, integración, edge cases).
Test plan#
Los tests duelen, tanto escribirlos como mantenerlos. Pero integrarlos desde la definición de funcionalidades (usando mis propios comandos feature-implement y feature-debug) marcó la diferencia. El test plan funcional, junto con tests unitarios, evitó regresiones tontas en áreas críticas como threading o atajos.
Simplificar vs sobrecomplicar#
Los LLMs tienden a los extremos:
- A veces sobre-simplifican: recuerdo cuando, atascado con un problema de linters en una release, el modelo me sugirió directamente desactivarlos.
- Otras veces sobre-complican: como con los emojis, creando arquitecturas innecesarias para un problema sencillo.
El reto está en encontrar el equilibrio: validar constantemente que la solución es proporcional al problema.
Prompt & Context Engineering: más allá del prompt#
Uno de los mayores aprendizajes de GizTUI es que no basta con escribir buenos prompts: hay que ser intencional con el contexto en el que los usas. Algunos lo llaman context priming o context crafting.
En la práctica, esto significa preparar al modelo con la información adecuada antes de pedirle nada. En mi caso, una técnica recurrente era algo tan simple como:
“Explícame cómo funciona la feature X. Ahora quiero algo parecido, pero que además haga Y y Z.”
Ese tipo de preparación le daba al modelo un marco de referencia y evitaba que reinventara la rueda cada vez.
Esto, combinado con dos pilares más, me permitió mantener coherencia:
- Prompt engineering: a través de comandos personalizados como feature-implement o feature-debug, que encapsulaban buenas prácticas y checklist de lo que no podía faltar.
- Context priming documental: usando los docs de decisiones de arquitectura como recordatorio vivo (aunque el modelo no siempre los tuviera presentes, eran una guía de consistencia a la que volver en refactors).
La segunda derivada de todo esto es que hay que hacer una gestión activa de la ventana contexto. Las sesiones largas acaban estirando la ventana de memoria del modelo y este empieza a olvidar detalles importantes. Ahí entra el comando compact en Claude: básicamente te permite resumir el estado actual de la conversación y refrescar el contexto antes de seguir. Aprendí que lo más efectivo no es esperar a que lo lance automáticamente, sino usarlo proactivamente cuando ves que el hilo se está inflando demasiado.
En resumen: los prompts son la chispa, pero el contexto es la leña que mantiene el fuego. Y si no cuidas esa leña, el modelo se dispersa, olvida o reinventa.
Conclusiones y reflexiones#
La primera conclusión es obvia: IA cambia el juego. El coste de construcción es prácticamente nulo en comparación con hace unos años. Eso significa que lo verdaderamente escaso no es la capacidad de programar, sino tu capacidad de decidir bien dónde poner foco.
La segunda es que estamos entrando en la era de la hiperpersonalización y el código efímero. Igual que hoy tenemos clústeres de Kubernetes de usar y tirar, ahora también podemos permitirnos aplicaciones usar y tirar. Prototipos hechos a medida, en horas o días, que resuelven un problema muy concreto, se adaptan como un guante y luego desaparecen. Eso te permite iterar más rápido, aprender más deprisa y adaptarte con agilidad a un entorno cambiante donde muchas veces ni siquiera conoces el problema completo al inicio.
La tercera conclusión es que los viejos hábitos siguen siendo vigentes. Los modelos no son deterministas: se van a equivocar, se van a dispersar y se van a olvidar de lo que estaban haciendo. Por eso es clave poner guardarraíles. Yo lo comparo con Ulises atándose al mástil para resistir el canto de las sirenas: necesitas disciplina para no dejarte llevar por “soluciones brillantes” que en realidad no quieres. A lo largo del artículo he compartido las prácticas que a mí me han funcionado como esos guardarraíles: planificación, test plan, commits pequeños, documentación viva…
La cuarta es más personal: volvería a hacerlo sin dudarlo. GizTUI no se quedó en un experimento de laboratorio; es una herramienta que ya utilizo en mi día a día. Me da un plus de productividad real y, sobre todo, me libera del coste de oportunidad que antes me comían los correos. Ese tiempo y esa energía ahora los dedico a tareas donde aporto más valor a mi empresa y me vuelvo más competitivo. Win–win.
¿Lo haría igual? Claro que no. Con todo lo aprendido, hoy diseñaría algunas partes de otra manera. Pero esa es precisamente la esencia de este tipo de proyectos: construir, aprender, refinar.
Si quieres ver el listado completo de funcionalidades que salieron de este proceso, lo tienes documentado en detalle en el propio repositorio de GizTUI GitHub Repo.
Me encantará saber qué te parece o qué otras ideas se te ocurren al respecto.
Mi invitación es sencilla: atrévete a experimentar.
Hoy la IA nos da la posibilidad de crear herramientas hiperpersonalizadas a una velocidad y coste impensables hace unos años. No necesitas ser un ingeniero experto para empezar; solo tener un problema real y las ganas de aprender.