Kodex empieza a tener forma
Tabla de contenidos
Durante bastante tiempo, Kodex fue más una idea que un sistema.
Había piezas de proyectos anteriores, decisiones de diseño tomadas en distintos momentos, código que todavía tenía sentido y código que claramente pertenecía a otra época. El objetivo inicial era relativamente sencillo: recuperar kazztor.net sin arrastrar todo el peso de lo que había existido antes.
Pero en algún punto de las últimas semanas el trabajo cambió.
Ya no estamos simplemente reconstruyendo el sitio.
Estamos definiendo cómo funciona.
Recuperar primero, diseñar después
Una de las decisiones más útiles fue evitar la tentación de rehacer todo desde cero.
Cuando un proyecto lleva años acumulando versiones, frameworks, estilos y experimentos, empezar otra vez parece atractivo. También puede convertirse en una manera elegante de repetir los mismos errores.
Kodex tomó otro camino.
Primero recuperamos lo que todavía tenía valor. Después empezamos a separar las decisiones accidentales de las decisiones que realmente queríamos conservar.
Eso obligó a responder preguntas bastante básicas.
¿Qué debe pertenecer al sitio?
¿Qué debe pertenecer al sistema de diseño?
¿Cómo deben almacenarse los artículos?
¿Dónde viven sus imágenes?
¿Qué parte de la infraestructura necesita conocer el contenido y qué parte debería permanecer completamente ajena a él?
Son preguntas poco vistosas, pero probablemente son más importantes que elegir un framework o escribir un nuevo componente.
El diseño dejó de ser una colección de números
Uno de los cambios más interesantes ocurrió con la tipografía.
Durante años es fácil terminar ajustando un sitio de la manera tradicional: un tamaño aquí, un margen allá, unos cuantos px hasta que algo se ve bien.
Funciona.
Hasta que cambia el ancho de la pantalla.
Entonces empiezan los parches.
En Kodex hemos empezado a tratar la tipografía como un sistema continuo. El tamaño del texto, el ancho de lectura, el espaciado y el ritmo vertical tienen que responder juntos al espacio disponible.
Eso significa volver a herramientas como clamp() y calc(), pero no simplemente porque sean modernas.
La idea es que el diseño pueda respirar entre distintos tamaños de pantalla sin depender de una colección interminable de breakpoints.
La comparación con sitios como Medium también resultó útil, no para copiarlos, sino para medir algo que a veces resulta difícil describir: el ritmo.
Cuánto espacio hay entre una idea y la siguiente.
Qué tan larga resulta una línea.
Dónde empieza a sentirse pesado un párrafo.
Cuándo una página parece documento y cuándo empieza a sentirse como interfaz.
Esas pequeñas decisiones terminan definiendo gran parte de la experiencia de lectura.
Style Foundation encontró su propósito
Otra pieza que empieza a acomodarse es Style Foundation.
Originalmente podía parecer simplemente otro repositorio con estilos compartidos. Ahora su función es mucho más clara.
Kodex no debería decidir por sí mismo cada tamaño tipográfico, cada escala o cada regla responsiva. Esas decisiones pertenecen a una capa inferior.
Style Foundation puede convertirse precisamente en eso: una base visual reutilizable, independiente del contenido particular de kazztor.net.
Cuando encontramos un problema de ritmo tipográfico en Kodex, la pregunta ya no es únicamente:
“¿Cómo arreglo esta página?”
También podemos preguntar:
“¿Este problema revela algo que debería corregirse en el sistema?”
Ese cambio de perspectiva es pequeño, pero importante.
Resolver un problema una sola vez vale mucho más que resolverlo página por página.
El contenido también necesita arquitectura
Algo parecido ocurrió con las imágenes.
En un blog tradicional es muy fácil terminar con una enorme carpeta de medios donde conviven imágenes de artículos completamente diferentes.
Funciona al principio.
Después aparecen archivos llamados cosas como:
hero-final-2-real.webp
Kodex está tomando una dirección más simple: cada artículo puede ser dueño de sus propios recursos.
Texto e imágenes forman parte de la misma unidad conceptual.
Si un artículo desaparece, resulta evidente qué archivos le pertenecían. Si se mueve, sus recursos pueden moverse con él. Si queremos entender cómo está construido, no necesitamos recorrer medio proyecto.
No es una gran innovación tecnológica.
Es simplemente orden.
Y el orden empieza a importar mucho cuando queremos que tanto una persona como un agente de IA puedan entender el proyecto sin reconstruir mentalmente toda su historia cada vez.
Codex cambia la manera de construir
Ahí aparece probablemente el cambio más grande de todos.
Kodex se está desarrollando en una época en la que escribir código ya no es necesariamente la parte más lenta del proceso.
Podemos pedir a Codex que investigue un problema, lea un issue, revise una implementación y prepare cambios.
Eso cambia el cuello de botella.
El trabajo importante pasa a ser definir correctamente el problema, conservar el contexto y establecer qué decisiones pertenecen a cada parte del sistema.
Un agente puede escribir una función en segundos.
Pero si no sabe por qué existe, dónde debe vivir o qué principio intenta proteger, simplemente producirá código más rápido.
Por eso la arquitectura de Kodex empieza a incluir algo que antes probablemente habría considerado documentación secundaria: decisiones explícitas.
Issues que explican problemas.
Repositorios con responsabilidades claras.
Convenciones para los recursos.
Reglas que puedan ser entendidas antes de modificar el código.
La documentación ya no sirve únicamente para recordar el proyecto dentro de seis meses.
También sirve para que una inteligencia artificial pueda trabajar hoy sin inventarse la mitad del contexto.
Incluso el servidor forma parte del diseño
La recuperación de la infraestructura también terminó siguiendo el mismo principio.
El servidor existente ya tenía responsabilidades. Traefik estaba al frente y otros servicios dependían de esa arquitectura.
La solución fácil habría sido ocupar directamente los puertos públicos y hacer que kazztor.net funcionara cuanto antes.
La solución correcta fue entender primero lo que ya existía.
Kodex tendrá su propio servidor web detrás de Traefik, sin interferir con los demás servicios.
Otra vez aparece la misma idea:
no destruir una estructura que funciona solamente porque queremos agregar algo nuevo.
Entender primero.
Separar responsabilidades después.
Implementar al final.
El proyecto ya no necesita demostrar que funciona
Ese quizá sea el cambio más importante.
Al principio había que demostrar que Kodex podía existir.
Que el contenido podía recuperarse.
Que el nuevo stack podía funcionar.
Que kazztor.net podía volver a tener una base moderna.
Esa etapa prácticamente terminó.
Ahora las preguntas son otras.
¿Cómo queremos escribir durante los próximos años?
¿Cómo hacemos que agregar un artículo sea trivial?
¿Cómo mantenemos el diseño consistente sin congelarlo?
¿Cómo logramos que las mejoras hechas para una página beneficien a todas las demás?
¿Cómo construimos un proyecto que siga siendo comprensible cuando buena parte del código haya sido escrita con ayuda de agentes?
Son problemas bastante mejores que los del principio.
Porque significan que Kodex ya dejó de ser una reconstrucción.
Está empezando a convertirse en un sistema.
Categoría: Desarrollo