La mayor parte de lo que se escribe sobre software vive dentro de una sola capa. Un post de frontend, un post de bases de datos, un post de LLMs. El trabajo al que yo vuelvo siempre pasa entre capas, donde una decisión en un lugar cambia en silencio la economía de otro.
Un dispositivo GPS sale con un protocolo de 2011. El servicio de ingesta lo normaliza. La base de datos guarda posiciones a una resolución que el producto puede pagar. Un motor de reglas decide cuáles de esas posiciones son interesantes. Solo entonces un modelo puede razonar sobre lo que pasó. Mueve una frontera y la factura, la latencia o el modo de falla cambian en un lugar donde no estabas mirando.
Esa costura es donde los sistemas suelen romperse, y es la parte que más me interesa. También es la razón por la que desconfío de la arquitectura que empieza por el modelo. Un modelo es un componente con una curva de costo, una distribución de latencia y un modo de falla. Tratarlo como el centro del sistema es cómo terminas con demos que no sobreviven un martes.
De qué quiero escribir
- La ingeniería debajo de los agentes: presupuestos de contexto, evaluación, ruteo y qué hacer cuando el modelo se equivoca con confianza.
- Infraestructura en tiempo real que tiene que sobrevivir flotas reales, no tráfico de benchmark.
- Herramientas para developers que hagan la siguiente feature más fácil que la anterior.
- Los sistemas poco glamorosos — facturación, ciclo de vida de dispositivos, puentes contables — que convierten un proyecto en negocio.
No tengo un calendario de publicación. Tengo una lista de cosas que explico una y otra vez, y escribirlas una vez sale más barato que explicarlas dos.
Si quieres la versión corta de cómo construyo: arquitectura antes que hype, IA donde el razonamiento realmente ayuda, y aburrido pero depurable antes que listo e inexplicable.