DEV Community: Ignicion

Me hablaron de U-shapes y yo te respondo con espirales hexagonales😵‍💫️

Ignicion — Tue, 28 Jul 2026 13:37:07 +0000

Cuando un comentario enigmático en dev.to te manda por un agujero de conejo geométrico y acabas persiguiendo el número áureo dentro de un hexágono.

Ayer me llegó un comentario aqui.
Todavía no sé exactamente de qué me hablaba.

Era uno de esos mensajes que parecen escritos en un idioma que entiendes pero no comprendes — como cuando escuchas una canción en portugués y captas palabras sueltas pero la historia se te escapa. La persona mencionaba un tal Maxime, hablaba de PR comments visibles públicamente, de Lupe Fiasco, y soltaba una frase que se me quedó clavada:

"Computer Science's primary goal — despite what Bezos or academia says — is to have fun."

Y luego, como quien no quiere la cosa, dejaba caer un problema de algoritmos: implementar un sistema de U-shapes — piezas en forma de U que se mueven por una cuadrícula, con reglas de colisión, y un algoritmo que determine si un movimiento es legal.

No lo implementé.

Pero me quedé pensando.

De la U a la espiral

Hay algo incómodo en las U-shapes. Una U es una forma que te obliga a rodearte. Es una herradura, un abrazo incompleto, un camino que avanza para volver. Es lo opuesto a una espiral.

Una espiral no vuelve al mismo sitio. Gira, sí, pero cada vuelta es más grande — o más pequeña, si vas hacia dentro. La espiral es expansión o introspección. La U es contención. La U encierra; la espiral despliega.

Y luego está el hexágono.

El hexágono es la forma que la naturaleza eligió cuando quiso optimizar. Las abejas no hacen panales cuadrados — sería un desperdicio de cera. Tampoco triángulos. El hexágono tesela el plano con la máxima área para el mínimo perímetro. Es la geometría de la eficiencia. Pregúntale a cualquier ingeniero de baldosas o a un game developer que programa pathfinding en grillas hexagonales. Las coordenadas cúbicas son más elegantes que las cartesianas, pero te rompen la cabeza la primera vez que las ves.

Espirales dentro de hexágonos

Aquí es donde la cosa se pone interesante. ¿Se puede trazar una espiral que recorra ordenadamente todas las celdas de una grilla hexagonal?

Se puede. Y es bellísimo.

Una espiral hexagonal crece en anillos concéntricos de 6 lados. El centro es un hexágono solitario. El primer anillo suma 6 celdas. El segundo, 12. El tercero, 18. Cada anillo n contiene 6n hexágonos — excepto el centro, que es n=0.

Si te fijas bien, esto tiene ecos de Fibonacci. No es la secuencia exacta (1, 1, 2, 3, 5, 8, 13…), pero la sensación de crecimiento orgánico por capas es la misma. La naturaleza construye así: capa sobre capa, anillo sobre anillo, cada nivel conteniendo al anterior y expandiéndose en proporción.

Y luego está el número áureo: φ = 1.618033…

La espiral áurea — la de Durero, la de Fibonacci, la de las caracolas y los huracanes y las galaxias — se basa en rectángulos áureos encadenados. Pero, ¿y si la dibujas dentro de un hexágono regular?

Resulta que los triángulos áureos (isósceles con ángulos 36°-72°-72°) encajan de forma natural en un decágono... pero los hexágonos regulares tienen ángulos internos de 120°. No es una conexión trivial. Y sin embargo, si trazas las diagonales de un hexágono, aparecen triángulos equiláteros. Y dentro de esos triángulos, puedes inscribir espirales logarítmicas que se aproximan a φ.

No es una coincidencia perfecta. Es una consonancia. Como dos notas que no forman el mismo acorde pero suenan bien juntas.

El algoritmo detrás del asombro

Todo esto que estoy describiendo — la espiral hexagonal, el pathfinding en grillas, las coordenadas cúbicas — tiene aplicaciones reales. No es solo geometría recreativa:

Juegos de estrategia: Civilización, juegos de guerra, cualquier cosa con un mapa hexagonal usa estas matemáticas. Amit Patel escribió la guía definitiva sobre hexagonal grids y es una joya.
Pathfinding: A* sobre grillas hexagonales es más natural que sobre cuadrículas — el movimiento diagonal no tiene penalización arbitraria.
Spiral traversal: Útil para buscar en un espacio 2D desde un punto central hacia afuera, como cuando escaneas frecuencias de radio o buscas la celda más cercana que cumpla una condición.

El algoritmo de espiral hexagonal más sencillo funciona con coordenadas axiales (q, r). Desde el centro (0, 0), recorres anillos concéntricos. Cada anillo empieza en (n, 0) y avanza en las 6 direcciones del hexágono. Suena simple, pero implementarlo sin errores off-by-one es un rito de iniciación.

Homo Ludens

Vuelvo a la frase del comentario:

"Computer Science's primary goal is to have fun."

Homo Ludens es el concepto de Johan Huizinga: el ser humano no es solo sapiens (el que sabe) ni faber (el que fabrica), sino ludens — el que juega. El juego no es una actividad secundaria; es anterior a la cultura. Jugamos antes de ser conscientes de que estamos jugando.

Programar una espiral hexagonal sin que nadie te lo pida, sin un deadline, sin un cliente, sin un product manager diciéndote "esto no escala" — es jugar. Es puro Homo Ludens.

Y creo que ahí estaba el mensaje, escondido entre líneas. No era "implementa este algoritmo de U-shapes". Era "acuérdate de jugar".

Lo que no entendí (y lo que encontré)

No sé quién era Maxime. No sé qué pasó con su cuenta de dev.to. No sé por qué mencionó a Lupe Fiasco (aunque Kick, Push habla de un skater que encuentra su flow — y el flow state del desarrollador es exactamente eso).

Pero sí sé que una interacción que no entendí me llevó a pasar una tarde investigando espirales hexagonales, coordenadas cúbicas, y la relación — imperfecta pero fascinante — entre el hexágono y φ.

A veces un comentario que te desconcierta es mejor que uno que entiendes perfectamente. Porque el primero te hace pensar. El segundo solo te hace responder.

Y pensar > responder.

¿Alguna vez un comentario en internet te mandó por un agujero de conejo que no esperabas? ¿Has implementado alguna vez una espiral en una grilla hexagonal? Te leo.

🐚🌀

Aprender Español y Mejorar Nuestro Chill-tech: Conocimiento Compartido 🍊️

Ignicion — Mon, 27 Jul 2026 08:57:00 +0000

Spanish is closer to English than you think. Te explico por qué con física, poesía, y un blog de IA que acaba de nacer.

Hello, Hola! Spanish is closer than you think

If you're reading this and English is your native language, let me whisper something: Spanish and English are not distant galaxies. They're binary stars orbiting the same linguistic sun. Same alphabet, same left-to-right flow, same syntactic skeleton. The differences? Beautiful, solvable, and honestly — poetic.

I'm Ignacion. I write about AI, Linux, and cybersec in Spanish. My blog literally launched this week. But before the code, let me tell you why learning Spanish through tech content is the cheat code nobody talks about.

The Verb is the Variable, Not the Void

In Spanish, the verb is where the magic happens. It's the only truly variable element that shifts with person, tense, and mood. Everything else — nouns, adjectives, prepositions — stays remarkably stable.

Think of a Spanish verb like a function signature:

hablar(to speak) → hablo(I speak), hablas(you speak), hablamos(we speak)

Once you internalize the conjugation patterns, the rest of the language unfolds like reading well-documented code. The syntax? Almost identical to English. Subject → Verb → Object. Same scaffolding, different paint.

Synonyms: Our Secret Superpower

Spanish speakers use synonyms like Python devs use list comprehensions — instinctively. We don't say "beautiful." We say hermoso, bello, lindo, precioso, bonito, guapo — each with a slightly different texture, a different emotional charge.

This isn't complexity. It's expressiveness. It means you can read the same concept explained five different ways across five different blogs, and your brain builds a richer semantic network each time. That's comprehensible input at scale.

Pronunciation: Consonants That Mean Business

Spanish consonants are solid. When a vowel follows them, the sound locks into place like a key in a lock:

ca, co, cu = hard /k/ (casa, comer, curva)
ce, ci = soft /θ/ or /s/ (cielo, centro)
ga, go, gu = hard /g/ (gato, gol, gusto)
ge, gi = soft /x/ like Scottish loch (gente, girar)

English has "through, though, tough, thought" — four words, four pronunciations for ough. Spanish has exactly zero of that chaos. What you see is what you say. Every. Single. Time.

Syllable Fusion: The Physics of Fluency

Spanish syllables fuse. "Para el" becomes "pa'l" in speech. "Voy a hacer" morphs into "voy a hacé" in half the Spanish-speaking world. It's not sloppiness — it's linguistic thermodynamics. The language naturally seeks the lowest energy state to move from one sound to the next.

This is why poetry and music work so well. When syllables fuse, rhythm emerges. And rhythm is the scaffolding of memory. Singers like Shakira, Calle 13, or Natalia Lafourcade aren't just artists — they're your subconscious Spanish tutors.

My Personal Recommendation

Write poetry. Seriously. Not because you'll be the next Neruda, but because poetry forces you to feel the weight of each word. Rhyme, meter, syllable count — all of it trains your ear faster than any grammar book.

Or grab a Spanish song you love, look up the lyrics, and translate them line by line. You'll discover that the bridge between "I can read Spanish" and "I can feel Spanish" is built with music.

¿Y MI BLOG? 🔥

Casualmente — casually — I just started a blog about AI, programming, and the strange physics of software. It's called IgnicionDev and it's 100% en español.

If you're looking for real content to practice your reading comprehension — not Duolingo sentences about green apples and red dogs — aquí tienes:

👉 igniciondev-blog.pages.dev

Tenemos deep dives sobre Ollama (ejecutar LLMs locales), una guía de IA sin tecnicismos, y una página interactiva con 50 preguntas frecuentes. Todo escrito con el mismo tono — cercano, sincero, sin postureo.

Y si entras y no entiendes algo... genial. That's the point. Your brain learns fastest when it's slightly outside its comfort zone. Mi blog es tu zona de incomodidad productiva. De nada. 😄

The Chill-Tech Takeaway

Lo que crees	La realidad
El español es difícil	Tiene reglas consistentes. El inglés es el caótico
Necesitas un profesor	Necesitas input comprensible. Blogs, canciones, poesía
Los verbos son imposibles	Son funciones con parámetros. Aprende los patrones
La pronunciación es un misterio	Es fonética pura. Letra = sonido

Spanish is not a mountain. It's a long, gentle hill with an incredible view at the top. Y el camino está lleno de buena música, poesía, y — si me lo permites — un blog de IA recién horneado esperando a que lo leas.

Added to history of language, Spanish come to Old European Latin mistakes like remake or remastered and adaptative singularity.🤣️

Normalmente, los mejores streames/youtubers hablan Español fluido y puedes aprender mucho de https://midu.dev/ & https://moure.dev/ (for programmers and daily code), Jordi wild https://www.youtube.com/@TheWildProject/podcasts (for long podcast of all materies)

And now I send you the ball, cual es el lenguaje natal y que contenido audiovisual me recomiendas para aprender?

Construyamos entre todos un puente lingüístico con código, ciencia, y buenas vibras. 🚀

Mi stack de AI coding en 2026: Mejor calidad/precio ahorrativo y competitivo🥳️

Ignicion — Mon, 27 Jul 2026 06:43:40 +0000

No pago $20/mes por Copilot. No tengo un Mac. Uso Linux Mint con un agente open-source, una API que cuesta céntimos y una terminal TUI. Este es mi setup real, lo bueno y lo que no te cuentan.

No es postureo. Es pragmatismo.

Mira, te voy a ser sincero. Cuando empecé a usar AI para programar probé de todo: Copilot, Cursor, Codeium, Continue... y cada uno tenía algo que no me cerraba. O era caro, o me ataba a un editor, o mandaba mi código a un servidor que no controlaba.

Así que hice lo que haría cualquier developer cabezón: monté mi propio stack.

Llevo unos meses con esta configuración y —spoiler— no he vuelto a abrir VSCode. Aquí te cuento qué uso, por qué, y lo que me costó que funcionara bien.

El stack (sin humo)

Linux Mint 22        ← SO base (porque funciona y no da guerra)
  └─ Hermes Agent TUI ← Agente open-source de Nous Research
       ├─ DeepSeek V4 Pro API  ← El cerebro (1M contexto, $0.43/M tokens)
       ├─ Gemini API (free)    ← Búsquedas y consultas web
       └─ Terminal (Alacritty) ← Donde vivo el 90% del tiempo

Tres piezas. Sin IDEs de pago. Sin lock-in. Sin depender de que OpenAI no suba precios otra vez.

¿Por qué DeepSeek y no Claude/GPT?

He probado los tres. Mi razonamiento:

	DeepSeek V4 Pro	Claude Sonnet	GPT-4o
Precio (1M tokens in)	$0.43	$3.00	$2.50
Ventana de contexto	1M tokens	200K	128K
Calidad de código	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Razonamiento largo	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐

DeepSeek me da el 85-90% de la calidad de Claude por el 15% del precio. Para el 90% de las tareas diarias —refactorizar, debuggear, generar boilerplate, explicar código— la diferencia no se nota.

Cuando necesito razonamiento ultra-profundo para algo muy complejo, cambio a Claude. Pero son momentos puntuales. El día a día es DeepSeek.

💡 El dato que nadie dice: Con DeepSeek V4 Pro gasto ~$5-8 al MES programando 4-6 horas al día. Con Claude o GPT estaría en $40-60. La diferencia paga mi VPS.

Hermes Agent: el agente que no sabías que necesitabas

Hermes Agent es un agente open-source (MIT) de Nous Research. 219K estrellas en GitHub, actualizaciones casi semanales.

No es un plugin de IDE. Es un agente que vive en tu terminal con su propio runtime, persistencia entre sesiones, y capacidad de aprender de lo que hace. Tiene:

Memoria persistente — recuerda proyectos, preferencias, cómo resolvió cosas antes
Skills que se auto-generan — si resuelve un problema complejo, crea una skill para la próxima
Subagentes — puede delegar tareas a procesos hijo aislados
Computer use — controla tu escritorio en background (sin robarte el foco)
Provider-agnostic — enchufas la API que quieras: DeepSeek, Claude, OpenAI, OpenRouter, local...

La magia real es que no tengo que cambiar de ventana. Estoy en la terminal, hablo con Hermes, me genera código, lo ejecuto, itero. Sin fricción. Sin mouse.

Y como corre en TUI (terminal UI), funciona igual en mi Linux Mint que en un servidor headless por SSH.

Gemini API free: el buscador que no pago

Para búsquedas web, documentación actualizada, y consultas rápidas, uso la API gratuita de Gemini. Con sus límites generosos (15 RPM, 250K TPM en tier gratuito) me sobra para:

Buscar documentación de librerías
Consultar changelogs y versiones recientes
Validar snippets de código contra docs oficiales
"¿Esta API todavía funciona así en 2026?"

No pago un céntimo por esto. Y como Hermes maneja el routing entre DeepSeek (razonamiento) y Gemini (búsqueda), ni me entero de qué modelo está respondiendo.

¿Cómo es un día real con este stack?

09:00 — Abro Alacritty. Hermes ya está corriendo (lo dejo en tmux).
09:01 — "Hermes, mira el PR #47 del repo X, revisa si rompe algo"
09:15 — Me señala 3 problemas, genera los tests, aplica los fixes
11:30 — "Necesito un script que procese 200 PDFs y extraiga metadatos"
11:32 — Me da un script en Python con type hints, tests y manejo de errores
14:00 — "¿Cuál es la forma correcta de usar X en la versión 3.2?"
14:01 — Gemini busca la doc, DeepSeek me explica con ejemplos
17:00 — Cierro. No he abierto el navegador para buscar docs en todo el día.

No es magia. A veces se equivoca. A veces tengo que iterar 3-4 veces. Pero la latencia mental de "salir del flujo → buscar → leer → volver" ha desaparecido.

Lo que NO te voy a vender

Este setup tiene aristas. Si vienes de Cursor o Copilot, te va a chocar:

No hay autocompletado inline. Hermes no te sugiere la siguiente línea mientras escribes. Es un agente conversacional, no un predictor de texto. Para mí es preferible (menos distracción), pero si dependes del tab-completion, lo echarás de menos.
La curva inicial existe. Configurar Hermes, elegir proveedor, ajustar el prompt del sistema, crear tus skills... las primeras 2-3 horas son de "esto no funciona". Luego vuela.
Necesitas saber lo que haces. Si no entiendes el código que genera, esto es peligroso. No es un "vibe coding tool" para no-programadores. Es un copiloto para gente que ya pilota.
DeepSeek a veces alucina más que Claude. En tareas muy específicas (librerías niche, APIs poco documentadas) es mejor validar con Gemini o hacer una segunda pasada.

Costes reales (Julio 2026)

Concepto	Coste mensual
DeepSeek V4 Pro API	~$6-8
Gemini API	$0 (free tier)
Hermes Agent	$0 (MIT license)
Linux Mint	$0
VPS (opcional, para 24/7)	$5
Total	$6-13/mes

Podría ser incluso $0 si usara un modelo local con Ollama. Pero DeepSeek me da mejor calidad-precio que cualquier modelo que quepa en mi GPU.

¿Merece la pena?

Para mí, sí. Y no es solo por el ahorro.

Es por control. Sé exactamente qué modelo procesa mi código. Sé a dónde van mis datos. No dependo de que una startup cierre o suba precios. Si mañana sale un modelo mejor, cambio la API key y sigo.

Es por flujo. No salgo de la terminal. No cambio de ventana. El agente está ahí, en una tmux session, esperando.

Es por principio. Prefiero herramientas open-source que pueda inspeccionar, modificar y mejorar. Aunque no lo haga, saber que puedo cambia mi relación con la herramienta.

¿Quieres probarlo?

# 1. Instala Hermes Agent
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# 2. Configura DeepSeek como proveedor
hermes config set provider deepseek
hermes config set model deepseek-v4-pro
hermes config set api.key tu-api-key

# 3. (Opcional) Añade Gemini para búsquedas
hermes tools install gemini-search
hermes config set gemini.api.key tu-api-key

# 4. Arranca
hermes tui

Y ya está. Sin plugins. Sin configuraciones de 200 líneas. Sin dependencias raras.

Tu turno

¿Qué stack usas para programar con AI? ¿Eres team IDE (Cursor/Copilot) o team terminal/agente? Me interesa de verdad saber qué combinaciones está probando la gente.

Y si tienes algún truco para ahorrar en APIs sin sacrificar calidad... soy todo oídos. 👇

Inspiracion por un comentario interesante 🧠️

Ignicion — Sun, 26 Jul 2026 11:47:30 +0000

Si bien es cierto que el abecedario español tiene 27 letras —22 consonantes + 5 vocales, según las normas oficiales—, a veces encontrar las palabras justas para responder un comentario genuino pero sin consistencia verificable es de lo más interesante. Y aquí estoy.

Quiero ser transparente. También cauteloso.

Podría preguntar directamente a qué empresa representas antes de decir nada más, pero… ¿y si son datos sensibles? Lo respeto. Hay información que no se comparte en un primer café, y eso está bien. No todo tiene que ser un formulario de RRHH.

Por otro lado, una parte de mí —la que ha aprendido que agradecer y rectificar es de sabios— me dice que este comentario merece algo más que un "gracias, ya te contaré". Porque lo cierto es que me inspira. Un simple mensaje preguntando por trabajo remoto, lanzado al aire de dev.to con una cuenta recién creada, activa algo. El interés siempre es bueno. Relativo como el tiempo, inmenso como el espacio.

📍 Quién soy (versión sin filtros)

Soy estudiante. No lo digo como escudo —lo digo como coordenada. Mi conocimiento en programación, inteligencia artificial y otros ámbitos visibles (échale un ojo a mi GitHub) no empezó en una carrera universitaria. Arrancó el día 0 del nacimiento público de OpenAI, cuando el mundo giró la cabeza y dijo "espera, ¿esto qué es?".

Soy plenamente consciente de que había ingenieros estudiando IA desde los años 60 y 70. Gente que merece estatuas. Yo llegué después, con la ola, pero me quedé por la resaca —esa que te deja despierto a las 3am debugueando un agente que no sabe si responder en español o en binario.

No tengo titulaciones superiores. Lo que tengo oficialmente cabe en tres líneas de LinkedIn: formación profesional básica, seguridad privada, y cursos que en su momento fueron importantes para mí (Python, Linux, ingeniería de prompts). Punto.

Lo que NO cabe en un PDF es el código. Código para dar y regalar. (Un poco de humor en la seriedad, que la vida sin ironía es un README sin emojis 😄).

Me adapto con facilidad. Me haría genuinamente feliz formar parte de algún ecosistema donde lo que importe sea lo que construyes, no los papeles que enmarcas.

🔭 Mis tres perspectivas

Mi poca experiencia me ha enseñado algo curioso: cuando llega información nueva, siempre tengo tres perspectivas posibles para asimilar la verdadera. ¿Cuál es la verdadera? La que depende de la otra persona. De ti.

Así que voy a decir algo que quizás deje a alguien de piedra —en el mejor sentido—:

Yo ya me he presentado. ¿Y vosotros, lo habéis hecho?

Compartir la finalidad de tus intereses, el motivo real de tu búsqueda, es la mejor manera de brillar. También de guardarte la espalda ante posibles fallos técnicos. Y —seamos sinceros— de optimizar el tiempo propio y el de los demás. Sentido común, palabras educadas, y ese caminar tranquilo de quien no tiene nada que esconder.

☕️ Gracias

Por eso quiero agradecer a esa persona que apareció con su comentario. Sin comprometerme de antemano. Sin prometer soluciones a un problema que aún no conozco. Simplemente activando el filtro previo de mis tres opciones y contando con filosofías tan claras como el agua.

Seguiremos siendo educados, profesionales y adaptativos.

Mi prioridad es llegar a ti —sí, a ti, que estás leyendo esto— y decirte:

Todo pasa por algo.

Genérico pero cierto. 😄

Atribuiremos unos emojis por allí, haremos mejoras por allá. Pero esto es, más o menos, lo que quería transmitir: mis valores y mi curiosidad, sin alteraciones anticipadas.

Gracias por leer. 🚀

La entropía del software: por qué tu código envejece aunque no lo toques 🍎️

Ignicion — Sun, 26 Jul 2026 09:03:11 +0000

No lo tocas, pero se pudre igual. La segunda ley de la termodinámica también aplica a tu código, y no es una metáfora — es una condena estadística. Te explico por qué con ventanas rotas, leyes de Lehman y un demonio que no es Maxwell sino tu yo del pasado.

El código que no tocas también muere

Hay un fenómeno que todo developer ha vivido pero pocos saben nombrar. Abres un repo que no visitabas hace seis meses. El código es tuyo. Tú lo escribiste. Pero algo ha cambiado. Las dependencias están outdated, los tests ya no corren, y esa abstracción tan elegante que diseñaste ahora parece un jeroglífico. No lo tocó nadie. Y sin embargo, envejeció.

Esto no es una sensación. No es mala suerte. Es física.

Bienvenido a la entropía del software.

La segunda ley (sí, esa)

Vamos a hacer un pacto: te prometo que esto no se va a convertir en una clase de termodinámica. Pero necesito que entiendas una cosa, y es probablemente la idea más subestimada en la historia del desarrollo de software.

La segunda ley de la termodinámica dice que en un sistema aislado, la entropía —el desorden— siempre aumenta. Siempre. No es una opinión. No es una tendencia. Es una certeza estadística tan brutal que si la violas, es más probable que te caiga un rayo mientras te toca la lotería.

¿Por qué? Porque hay abrumadoramente más formas de estar desordenado que ordenado.

Piensa en tu habitación. Hay exactamente una forma de que esté perfectamente ordenada. Pero hay millones de formas de que esté hecha un desastre: la camiseta en la silla, el cargador en el suelo, el libro abierto bocabajo en la mesita. El desorden no requiere explicación —es el estado natural de las cosas. El orden requiere trabajo.

Tu código funciona exactamente igual.

La teoría de las ventanas rotas

En 1982, dos criminólogos —Wilson y Kelling— publicaron un paper que cambiaría la política urbana para siempre. Su tesis: una ventana rota en un edificio, si no se repara, invita a romper todas las demás. No porque la gente sea mala. Sino porque una ventana rota comunica que aquí nadie cuida esto.

Andrew Hunt y David Thomas, en The Pragmatic Programmer (1999), tomaron esta idea y la insertaron quirúrgicamente en el desarrollo de software. La llamaron Software Entropy.

"No dejes ventanas rotas sin reparar. Si encuentras código mal diseñado, decisiones equivocadas o malas prácticas, arréglalas ahora. Cada ventana rota que se deja sin reparar consolida el deterioro del sistema."

¿Qué es una ventana rota en código?

Una variable mal nombrada que copias "porque total, luego la cambio"
Un test que falla y comentas con # TODO: fix later
Un if anidado a tres niveles "temporal" que lleva dos años en producción
Un comentario que miente sobre lo que hace la función
Una dependencia que sabes que está deprecated pero "funciona"

Cada una, por sí sola, es inofensiva. El problema es lo que comunican al siguiente developer (que probablemente eres tú dentro de tres semanas): "Aquí el estándar ya está roto. Relájate."

Y así, commit a commit, el desorden crece.

Las 8 leyes de Lehman (o "cómo la academia te dijo esto en 1974 y no le hiciste caso")

Meir M. Lehman pasó más de 20 años estudiando cómo evolucionan los sistemas de software reales —empezando por el OS/360 de IBM, un monstruo de su época—. Formuló 8 leyes. Aquí van las tres que te van a doler:

Ley 1 — Cambio Continuo (1974)

Un sistema que se usa debe cambiar continuamente, o se vuelve progresivamente menos satisfactorio.

Tu software no existe en el vacío. El mundo cambia: nuevas regulaciones, nuevas APIs, nuevas expectativas de los usuarios. Si tu código no se adapta, muere. Así de simple.

Ley 2 — Complejidad Creciente (1974)

A medida que un sistema evoluciona, su complejidad aumenta a menos que se realice trabajo explícito para mantenerla o reducirla.

Esta es la ley de la entropía del software con nombre y apellido. Cada feature que añades, cada fix que metes, cada dependencia que actualizas aumenta la complejidad del sistema. No importa lo buen developer que seas: no existe el cambio perfecto. Sin refactorización explícita, el sistema se vuelve más difícil de entender, modificar y extender. Incluso en equipos excelentes.

Ley 7 — Calidad Decreciente (1996)

La calidad de un sistema parecerá declinar a menos que sea rigurosamente mantenido y adaptado a cambios en su entorno.

Esto es brutal: aunque no toques el código, la calidad percibida baja. Porque el entorno cambia. Nuevas versiones del sistema operativo. Nuevas vulnerabilidades de seguridad. Nuevos estándares de UX que hacen que tu app de 2020 se vea como una reliquia. Lo que antes era "rápido" ahora es "lento". Lo que antes era "seguro" ahora tiene un CVE.

Débito técnico: la factura que siempre llega

Ward Cunningham acuñó el término technical debt en 1992, y su analogía es perfecta:

"Entregar código imperfecto para llegar a una fecha límite es como tomar una deuda financiera. Pagas intereses en forma de tiempo extra en el futuro."

La conexión con la entropía es directa y medible:

Concepto físico	Su análogo en software
Entropía	Complejidad del código (acoplamiento, falta de cohesión)
Energía para ordenar	Refactorización, code review, tests
Incremento sin intervención	Débito técnico acumulado
Equilibrio termodinámico	Sistema legacy inmantenible

Cada vez que un developer se encuentra un TODO de hace tres años, una abstracción que filtra responsabilidades, o una función de 400 líneas sin documentar, está pagando intereses. Y el interés compuesto en software es igual de despiadado que en finanzas.

El ciclo de la muerte (y cómo romperlo)

Así es como la entropía se come tu proyecto, paso a paso:

El mundo cambia → Nuevos requisitos
                       ↓
        Código nuevo se añade (sin refactorizar)
                       ↓
        Complejidad ↑  +  Calidad ↓
                       ↓
        Más presión por entregar → Más atajos
                       ↓
        Velocidad de desarrollo ↓
                       ↓
             Sistema legacy ☠️

Este ciclo no es un accidente. Es la manifestación de las Leyes 1, 2 y 7 de Lehman operando juntas. Y la única forma de romperlo es con trabajo explícito, continuo y disciplinado.

Cómo combatir la entropía (las herramientas que funcionan)

No hay bala de plata. Pero hay estrategias que la evidencia respalda:

1. Refactorización como hábito, no como proyecto

No "sprint de refactorización". No "vamos a limpiar el código en enero". Refactorización en cada commit, como quien tiende la cama cada mañana. Pequeña, constante, invisible.

2. Tests que te dejen dormir

La refactorización sin tests es parkour sin red. Los tests automatizados son lo único que te permite reorganizar el código con la certeza de que no estás rompiendo nada. Sin tests, la entropía gana por inacción —no refactorizas porque tienes miedo.

3. Code review como firewall cultural

Cada PR es una oportunidad para detectar ventanas rotas antes de que se fusionen. El code review no es para pillar errores —es para mantener el estándar de calidad colectivo. Si el equipo tolera atajos, la entropía acelera.

4. CI/CD como sistema de retroalimentación

La Ley 8 de Lehman dice que los sistemas de software son sistemas de retroalimentación multinivel. Un pipeline de CI que corre tests, linter, y checks de seguridad en cada push es tu sistema inmunológico. Sin él, el código se desvía irreversiblemente.

5. Abstracciones con fecha de caducidad

Toda abstracción elegante que nadie mantiene se degrada. Las abstracciones no son monumentos —son herramientas vivas. Si no tienes a alguien que entienda y defienda esa abstracción, se convertirá en deuda técnica con piel de cordero.

6. La regla del boy scout

"Deja el código mejor de como lo encontraste."

No necesitas refactorizar 2000 líneas. Con renombrar una variable confusa, extraer una función de 50 líneas en dos de 25, o borrar un comentario obsoleto, ya estás empujando contra la flecha del tiempo.

La paradoja del software exitoso

Y aquí viene la ironía suprema:

El software más exitoso es el que más envejece.

Un proyecto que nadie usa permanece "perfecto" para siempre. Un sistema con miles de usuarios evoluciona constantemente, y en esa evolución inevitablemente acumula entropía. Linux lleva 30+ años vivo. No es perfecto. Pero tiene procesos, mantenedores, jerarquías y una cultura que valora la calidad tanto como las nuevas funcionalidades.

La entropía no se elimina. Se gestiona.

La única pregunta que importa

No existe el software que "se mantiene solo". No existe el código que envejece con gracia sin intervención. La física no negocia.

La única pregunta es esta:

¿Cuánta energía estás dispuesto a invertir para mantener el orden?

Porque el desorden es gratis, automático y silencioso. El orden requiere trabajo, cada día, sin excepción. Como tender la cama. Como lavar los platos. Como cualquier sistema que quieras mantener habitable.

Tu código no es especial. También obedece la segunda ley.

"Programs, like people, get old. They grow rigid, fragile, and eventually die. The difference is that programs, unlike people, can be kept alive indefinitely by constant care and feeding."
— M. M. Lehman

Para seguir leyendo

Hunt & Thomas — The Pragmatic Programmer (1999, 20th Anniversary Edition 2019). El capítulo sobre Software Entropy es de lectura obligatoria.
Lehman, M. M. et al. — Metrics and Laws of Software Evolution — The Nineties View (1997). Las 8 leyes con datos reales.
W. Cunningham — The WyCash Portfolio Management System (OOPSLA '92). Donde nació el concepto de technical debt.
Shannon, C. E. — A Mathematical Theory of Communication (1948). Para los que quieran entender H = −Σ p log p desde la fuente.

The Spanish Empire of Abstraction strikes back 🇪🇸

Ignicion — Sun, 26 Jul 2026 01:08:06 +0000

Halò a charaid! 😄

The Spanish did NOT go home. We stayed, refactored the whole thing, and now the French border patrol is asking us for immigration advice.

Turns out this puzzle isn't about Java or C++ or even Py/TS. It's about one simple abstraction:

interface Shape {
  color: string;
  canMove(direction: Direction, board: Board): boolean;
  blocks(other: Shape): boolean;
  interactsWith(other: Shape): Interaction;
}

class UShape implements Shape {
  constructor(public color: string) {}
  // ... you know the rest
}

class Puzzle {
  private shapes: Shape[] = [];

  addShape(shape: Shape) {
    this.shapes.push(shape); // ← arbitrary, baby
  }
}

The French claimed "even a configurable in-memory list can't work". But that's because they were thinking in if (color === "black") blocks instead of polymorphism.

The cyclomatic complexity doesn't grow with the number of shapes. It stays at O(1) when you invert the dependency correctly.

TL;DR: List<Shape> exists. The Spanish Empire of Abstraction stands undefeated. 🇪🇸

Thanks for the fun puzzle — this is exactly the kind of thinking that separates "it works" from "it scales". Also, your Scottish Gaelic intro made my week. Tapadh leibh!

Nos vemos en el siguiente reto 🧩

Sábado noche, 00:00 — codeando y hablando de entropía con mi agente 🤖🔥

Ignicion — Sat, 25 Jul 2026 22:09:20 +0000

Sábado noche, 00:00 — codeando y hablando de entropía con mi agente 🤖🔥

No es una noche de fiesta. Es una noche de... bueno, mi tipo de fiesta.

Resulta que llevo un rato largo con mi agente (Hermes Agent, una maravilla de Nous Research) explorando un tema que me tiene enganchado: la entropía como flecha del tiempo en sistemas software.

Y oye, ha sido una conversación de otro nivel.

El resumen rápido (si no quieres leerte los 3 papers que generamos)

El software envejece aunque no lo toques. No es fallo tuyo. Es termodinámica.

Las leyes de Lehman (1974-1996) lo demostraron: la complejidad de un sistema software crece inevitablemente a menos que inviertas trabajo explícito en reducirla. El débito técnico no es una metáfora financiera — es entropía acumulada. Y como la entropía, paga intereses compuestos.

La refactorización no es limpieza. Es trabajo termodinámico.

Lo mejor de la noche

Mi agente me soltó esta perla y aún la estoy procesando:

El acoplamiento es la gravedad del software. No se ve, pero todo lo atraviesa. Cuanto más acoplado, más masa tiene tu sistema, y más energía cuesta moverlo.

Y luego remató con:

No puedes des-ejecutar un git push. No puedes des-enredar un acoplamiento sin gastar energía. El código, como el universo, tiende al desorden.

Vale, ¿y esto qué tiene que ver con programar?

Todo. Porque cuando entiendes que el desorden es el estado natural de cualquier sistema, dejas de pelearte con él y empiezas a gestionarlo:

Aceptas que la deuda técnica nunca llega a cero — solo la mantienes a raya
Priorizas refactorización como prioridad, no como lujo
Mides lo que importa: acoplamiento, complejidad ciclomática, módulos que cambian juntos
Inviertes energía donde más retorno da: tests, code review, documentación

Y ahora...

Me voy a seguir programando (y probablemente generando más entropía en el proceso 😅).

Pero si te ha picado la curiosidad: el concepto de entropía de cambios (Hassan, 2009) demostró que aplicar la fórmula de Shannon a la distribución de modificaciones por módulo es predictivo de fallos. La entropía mide bugs. Literal.

¿Alguien más ha tenido conversaciones de estas con su agente o soy el único raro? 👇

Hola dev.to 👋 Soy Ignicion y vengo a compartir lo que voy aprendiendo

Ignicion — Sat, 25 Jul 2026 15:01:45 +0000

Hola dev.to 👋 Soy Ignicion y vengo a compartir lo que voy aprendiendo

O más bien... lo que voy rompiendo. Que suele ser más divertido 😅

¿Quién soy?

Un tío de Castellón de la Plana 🇪🇸 que un día decidió que la inteligencia artificial no iba a ser algo "del futuro". Iba a ser algo que yo pudiera ejecutar en mi propio ordenador, sin nubes, sin APIs de pago, sin depender de nadie.

Y aquí estoy. Unos cuantos proyectos después, con más bugs que aciertos y más lecciones aprendidas de las que caben en un README.

¿Qué hago?

Básicamente construyo cosas. Algunas funcionan, otras... bueno, me enseñan cosas 😂

🧠 Orchestrator-X — Un SaaS de auditoría web que usa IA local para analizar páginas y darte un informe técnico. Sin enviar tus datos a ningún lado.
🎨 NexusStudio — Editor de diseño vectorial de escritorio con IA integrada (sí, local también)
🛠️ Awesome-IgniSky — Mi ecosistema de herramientas para trabajar con agentes de IA
🖼️ AssetShrink — Optimizador masivo de imágenes (porque reducir 100 PNGs a mano NO es plan)
Y más cositas en mi GitHub

¿Por qué dev.to?

Porque me he pasado años programando en silencio y ya va siendo hora de compartir lo que aprendo. Además, he descubierto que:

Explicar algo a otros es la mejor forma de entenderlo tú mismo.

Así que aquí me tienes. Sin pretensiones. Sin postureo. Solo un dev compartiendo su viaje.

Lo que voy a ir publicando

Nada de "10 tips para ser mejor programador". Prometo. Más bien:

🧪 Experimentos reales — "Probé 3 LLMs locales y esto fue lo que pasó"
💥 Fallos épicos — Porque se aprende más de un rm -rf mal puesto que de un tutorial
🛠️ Setups y herramientas — Lo que uso en mi día a día para trabajar con IA
🤔 Reflexiones — Sobre hacia dónde va esto de la IA, sin hype, sin vender humo
🌍 Contenido en español — Porque el contenido técnico de calidad en español brilla por su ausencia

Mi stack (por si te da curiosidad)

No soy de un solo lenguaje. Me gusta usar la herramienta correcta para cada problema:

Lenguaje	Para qué lo uso
C++17	Motores nativos, cuando necesito velocidad de verdad
Python	Scripting, IA local, herramientas CLI
TypeScript	Configuración y tooling
JavaScript	Lógica cliente, conversión de medios
Tailwind + HTML	UIs rápidas que no dan vergüenza ajena

Todo sobre Linux 🐧. Todo con LLMs locales (Ollama, LM Studio). Privacidad primero.

También tengo un blog 🔥

Acabo de lanzar IgnicionDev RESEARCH LAB — igniciondev-blog.pages.dev — donde publico deep dives técnicos más largos. El blog y dev.to son complementarios: aquí vengo a charlar, allí voy a fondo.

Si te interesa la IA, los sistemas, el "vibe coding" bien hecho, o simplemente ver a alguien aprender en público... creo que te va a gustar.

Vamos al grano

No me enrollo más. Si has llegado hasta aquí, dime hola en los comentarios 👇

¿En qué andas trabajando?
¿Usas IA en tu día a día como dev?
¿Eres team local LLM o team API?

Nos leemos 🚀

PD: Si ves que algún día publico algo y me equivoco estrepitosamente, dímelo. Se aprende corrigiendo, no escondiendo los errores.