Edu González — Ingeniero en Data & Cloud. Documento decisiones técnicas.

Publico sobre las decisiones que los tutoriales oficiales no explican: por qué se eligió esta arquitectura y no la otra, qué trade-offs se asumieron, qué falló en producción que nadie documentó.

A veces el artículo responderá tu pregunta directamente. Otras veces te dará la respuesta incómoda que te obliga a resolverlo tú — porque en ingeniería no hay respuestas correctas universales, solo decisiones que se acoplan mejor o peor a un caso de uso.

También publico por gusto. Dedico fines de semana a explorar cosas que me interesan sin un objetivo claro, como cuando empecé. Esos artículos son los que más disfruto escribir.

Cuando tengo que resolver algo, la primera pregunta que me hago es: ¿alguien ya ha dedicado años a construir una solución validada para esto? Casi siempre la respuesta es sí.

Aprender a leer código de producción real — entender por qué existe cada decisión de diseño, no solo cómo funciona — es lo que más me ha enseñado. Requiere humildad, especialmente en cosas que parecen triviales.

En los últimos dos años he aplicado esta metodología en proyectos reales: un transpiler para migrar ETL legacy a Apache Spark, con el que automaticé la conversión a escala en producción.

Estamos en un punto de inflexión. La IA está automatizando el trabajo técnico repetitivo a velocidad récord — se estima que el 46% del código de usuarios de GitHub Copilot es generado directamente por IA.

El problema es que la IA acelera todo: lo bueno y lo malo. Una arquitectura mal diseñada explotará mucho antes hoy que hace cinco años, porque meter features es casi gratuito. Todo lo que tú no decidas lo decidirá la IA — y la IA rellena con lo estadísticamente plausible, no con lo estratégicamente adecuado.

El valor ya no está en generar miles de líneas de código. Está en los fundamentos que no cambian desde hace décadas, en entender el negocio y sus necesidades reales, y cada vez más, en entender a las personas. El software es una herramienta para resolver problemas del mundo real — cuando no responde a uno real, es sobreingeniería.

La IA es reactiva. El ingeniero es activo. El valor hoy está en ser la persona en quien confían para tomar decisiones técnicas y estratégicas — alguien que entiende el negocio, entiende la tecnología, y usa la IA como recurso propio, no como consultor externo al que se delega el criterio.

Publicaré con regularidad, sin promesas de calendario. Trabajo en consultoría, tengo una vida fuera de la pantalla, y priorizo la salud mental sobre la constancia forzada. Lo que sí puedo garantizar es que cuando publique, habrá algo concreto que llevarse.

Si hubiese empezado este blog hace tres años, estaría lleno. Dadme tiempo. Puedes seguir el blog por RSS — no hay newsletter ni notificaciones.

Si estás trabajando en algo interesante o quieres discutir alguno de los temas del blog, escríbeme a edunavata@gmail.com . Leo todo, aunque no siempre respondo rápido.