Creo que haber pasado los 40 y ahora tener un hijo (hola Dodo) me está haciendo notar detalles que durante mi vida se mantuvieron como un vibe flotante alrededor de lo que hago y lo que opino. Uno de estos detalles es una sensación horrible de que al usar la mayor parte del software, este te dice cómo tenés que pensar, te modifica a su gusto.

Hace no mucho tiempo logré entender que el momento a momento del uso de cualquier herramienta está directamente relacionado con las decisiones de diseño que tomaron los creadores, y que al usar sus herramientas, uno se convierte un poco en ellos. Suena a ciencia ficción, pero es literalmente así. El uso de las herramientas modifica tu cerebro.

Esta tensión la sentí usando Windows cuando tenía 12, y me instalé Linux y me enamoré de como dicen todos a mi alrededor "la pantalla negra con letras esa". Milité el software libre desde entonces. Odié Unity desde el minuto uno en Nastycloud y Hidden People Club, y disfruté mis días de Moai SDK y haciendo motorcitos en C++ o Rust.

No soy ingenuo, entiendo que gran parte del valor del software es que se puede redistribuir y reutilizar fácilmente, que el costo de hacer workflows complejos, bien hechos, es altísimo. Esta fue nuestra realidad durante todos estos años. El software libre habilitó una ventana, aunque sea pequeña, de posibilidad de adaptación del software, pero la dificultad de hacerlo volvió esa promesa algo poco práctico. Sólo grandes empresas con muchos desarrolladores pudieron aprovechar esto, justo los que menos lo necesitaban. Más allá de eso, el trade-off era más o menos claro: adoptar las decisiones de otros era el precio que había que pagar para poder hacer algo con una computadora.

Encuentro un eco en esto en el artículo en el que escribí que la productividad es una colonización de lo técnico sobre lo humano. El software no es más que una instancia más de esto. Pero creo que a partir de ahora la cosa cambió.

Software Idiosincrático

Si estuviste prestando atención al último año, te habrás dado cuenta de que la inteligencia artificial está hasta en la sopa, con grandes promesas de revolucionarlo todo. La realidad es que hasta ahora lo único que yo creo que revolucionó en serio es la forma en que producimos software.

Los agentes de código patearon el tablero, y ahora lo que siempre consideramos el esfuerzo de un equipo de 10 personas por meses, lo puede hacer un desarrollador solo en una semana (si está con fiaca). De golpe todo el conocimiento adquirido de "project management" voló por los aires y nos enfrentamos a tener que volver a responder preguntas muy básicas como si conviene pagar por software o hacerlo uno.

Yo quiero ponerle nombre a lo que anda dando vuelta en mi cabeza: software idiosincrático. Es el software que materializa tu opinión sobre cómo debería funcionar algo. En contraposición con el software ajeno, ese que nunca se siente del todo bien. No es software casero por lo humilde, ni personal por privado y no compartible. Es software terco. Tiene una opinión adentro, como todos, pero la opinión es tuya.

No es del todo nuevo esto, otras personas nombraron conceptos cercanos, como home-cooked software (Sloan), personal/malleable software, barefoot development, etc. Mi término está alineado, probablemente contenido en estos o conteniéndolos. Pero me gusta el foco que plantea la palabra idiosincrático, me sirve para que, al diseñar, diseñe tomando las decisiones que realmente me satisfacen y que si no lo hacen, se cambien.

Algunos Ejemplos

Las decisiones de diseño están en muchas capas, la más obvia es el costo. Por ejemplo, en Beezwax usábamos Render para hacer entornos de prueba de los cambios que hacemos al sitio web. Estábamos pagando casi 2000 USD por mes por esto, una locura. Me puse terco. Lo reemplacé en tres días con Dokku y una app en Sinatra vibeando con Claude Code. Algo que en otro momento hubiese sido impensado (armar todo ese sistema de cero), hoy se puede hacer en tres días. La ventaja competitiva de Render se fue al piso.

Por otro lado, a mi me pone un poco nervioso que otras empresas tengan muchos datos míos. Por ahora no puedo escaparle a los agentes de código porque no tengo el hardware ni el dinero necesario para usar modelos locales. Pero donde puedo, lo hago. Whispr Flow es un ejemplo, una app de dictado de voz con IA que la rompe. La experiencia de usar Whispr Flow vs cualquier otro dictado de voz es notable. Lo que vi es que no era más que un buen modelo de Speech To Text (STT) con un LLM en el medio corrigiendo. Pero siempre me sentí nervioso usándolo sobre todo cuando me mostró estadísticas de para qué lo usaba, ese fue el colmo. Bueh, vibecodeé un reemplazo en 4 horas, con whisper.cpp, un modelito local, y una llamada a haiku. La verdad es que viendo la vida digital suceder, no querer darle tus datos a un random es un poco terco. Y se siente tan bien.

Estos son dos ejemplos recientes de software que usaba y que reemplacé, ahora tengo los botones que quiero, los prompts que quiero, y ninguno de los features basura que no quiero. Yay!

Si estos dos servicios que consideraba intocables los reemplacé en tan poco tiempo ¿qué otros estamos pagando sólo porque antes construirlos era mala idea?

skulk

De golpe me encontré con un problema nuevo. Tenía cerca de 20 tabs en mi terminal abierta, todas con sesiones de Claude Code trabajando en múltiples proyectos y varias tareas a la vez en cada uno. Mi instinto fue bajarme cosas como Conductor, o Omnara, pero sentí esa fricción de las decisiones ajenas muy rápidamente. Encima aparecen cien por semana, todos prometiendo ser la solución definitiva. Todos pésimos. Así que me subí a la filosofía UNIX y creé el mío. En una tarde.

skulk es un CLI muy simple para administrar agentes de código que corren remotamente. Internamente es muy simple, usa SSH y tmux, crea git worktrees automáticamente y ya. Hace una sola cosa y la hace bien: administrar sesiones de Claude Code remotas.

Una consecuencia divina: al ser un CLI, toda la orquestación de agentes la puede hacer un agente corriendo en mi computadora, y para eso hice una skill de Claude Code.

$ skulk --help

Usage: skulk [OPTIONS] <COMMAND>

Commands:
  list         List all running agents on the remote server
  pull         Update the base clone on the remote server to latest main
  new          Create a new agent with worktree isolation
  destroy      Destroy a specific agent
  destroy-all  Destroy all agents at once
  init         Set up skulk for this project
  doctor       Verify the runtime environment is correctly set up
  gc           Clean up orphaned tmux sessions, worktrees, and branches
  connect      Attach to an agent's live tmux session
  diff         Show git diff between the default branch and an agent's branch
  disconnect   Detach all clients from an agent's tmux session
  logs         View an agent's terminal output
  send         Send a prompt to a running agent
  push         Push an agent's branch to `origin`
  archive      Archive an agent — kill its tmux session but keep worktree and branch intact
  restart      Restart an agent in its existing worktree with a fresh Claude session
  replay       Re-run an agent's original prompt on a fresh agent
  git-log      Show `git log` of commits on an agent's branch not in the default branch
  ship         Push an agent's branch and open a PR with a Claude-authored description
  transcript   Dump an agent's full tmux scrollback for archive or review
  status       Show detailed status for a single agent
  wait         Block until an agent has finished its current turn
  update       Update skulk to the latest version
  help         Print this message or the help of the given subcommand(s)

No se si skulk es mejor que todos los orquestadores del mercado, porque mejor es subjetivo, pero para mí lo es porque anda rápido y cada uno de esos comandos hace lo que yo quiero que haga y cómo yo quiero que lo haga, sin necesidad de consenso con las dinámicas de inversores o mercados que nada tienen que ver conmigo. Por si te da curiosidad, está hecho en Rust, que para mí es el mejor lenguaje/entorno de programación moderno para agentes.

cuentitos

Desde 2020 que tengo un problema. Todos los motores de narrativa para videojuegos dan pena. Hay menciones honoríficas como Ink, que hacen las cosas bien pero tienen decisiones de diseño con las que no estoy de acuerdo. En Hidden People Club intenté resolver este problema diseñando un lenguaje al que llamamos cuentitos. Avanzó rápido, pero el costo de desarrollo del motor más un juego se volvió prohibitivo. No conseguimos financiamiento y tuvimos que cerrar todo.

En su momento fracasó, no por falta de ganas o ideas, sino porque la escala excedía lo que podíamos hacer como equipo.

Ahora estoy escribiendo la versión 0.3 de cuentitos, diseñándolo con un flujo pensado en agentes de código: estoy haciendo lo que llamé compatibility tests, una suerte de TDDs del lenguaje. Uso Markdown para armar los tests, hay un comando que los corre, todo escrito desde cero, con agentes, y permitiéndome que el workflow sea como yo quiero que sea.

Ahora implementar un feature en cuentitos es muy simple: tengo una sesión de diseño con el agente, le pido que me escriba los compatibility tests, los leo y los dejo como me guste a mí, y después tengo otra sesión de diseño de la arquitectura interna para satisfacer esos tests. Mando al agente a trabajar y cuando termina hago code review.

El workflow de desarrollo está basado en CLIs en la terminal, como todo lo que hago, por eso los agentes la pasan bomba sin MCPs, computer use, ni nada de todo eso.

# Basic Two Options

Simple choice between two options, selecting the first option.

## Script
```cuentitos
What do you want to do?
  * Go left
    You went left
  * Go right
    You went right
```

## Input
```input
1
s
```

## Result
```result
START
What do you want to do?
  1. Go left
  2. Go right
> Selected: Go left
You went left
END
```

frantufro@everlong cuentitos % ./bin/run-compat
..........................................................................................................................................................................................................................................................................

Total: 266 | Failed: 0 | Pending: 0
frantufro@everlong cuentitos %

Este loop le dio a mi side project la posibilidad de existir, porque tengo muy poco tiempo, y no podría dedicarlo a esto ahora. Sin embargo, entre una cosa y otra, le mando un prompt, horas después reviso, le pido otra cosa, y se convirtió en algo que está ahí avanzando en el background sin un esfuerzo descomunal.

No todo lo que brilla...

Obvio que todo esto no es gratis ni mágico. Hay consecuencias muy concretas: ya no hay a quien tocarle la puerta si algo se rompe. Render se asegura el uptime ponele, ahora tengo que asegurarme yo. Hay un riesgo real en reinventar la rueda y hacerlo mal, ni que hablar cuando uno se pasa de rosca y hace código que no termina de entender porque lo hizo un agente.

Por otro lado, esto lamentablemente no es para todos, por lo menos por ahora tenemos que saber, y mucho, de programación y de computación para lograr software de buena calidad con agentes, esto no se puede evitar por ahora, por eso ahora, más que nunca, los programadores tenemos super poderes.

También es importante notar que no estoy diciendo "construí todo vos mismo". Por ejemplo, yo a Fastmail le pago y le voy a seguir pagando feliz, el email bien hecho es realmente difícil y lo que me cobran es mucho menos que los dolores de cabeza de hacerlo yo mismo (sé muy bien lo que es administrar servidores de email de mis primeros años en Fundition, nunca más). Lo que sí estoy diciendo es que las respuestas no cambian inmediatamente, lo que cambió fue el criterio de selección.

Antes "esto me llevaría mucho tiempo" justificaba los 10, 15, 30 USD al mes de casi cualquier SaaS. Ahora veo cómo mucho software es una carga más que una solución. Si en poco tiempo podemos tener algo que funciona suficientemente bien, y es minimalista para nuestro caso de uso, ¿por qué pagar un premium por casos de uso de otros que ni nos afectan?

La heurística

Yo no te voy a decir cómo decidir, porque sería muy meta en un artículo hablando de la imposición de criterios de diseño, pero yo estuve desarrollando una heurística.

¿El valor de X software, proviene de la dificultad intrínseca del problema que resuelve o de que alguien ya lo hizo y ya? ¿Cuánto me importa tener mi propia opinión expresada en este caso de uso?

Si el valor es "ya está hecho" y encima tengo opiniones fuertes sobre cómo se tendría que hacer (y esas opiniones contradicen el software existente), me lanzo a hacerlo yo.

Si el valor está en la dificultad real (Fastmail) o estoy de acuerdo con la mayor parte de las decisiones de diseño (esto lo veo usando el software intuitivamente y no encontrando irracionalidades), pago sin dudarlo.

Último balbuceo

Me encuentro a diario con esta sensación de impaciencia, de que la vida es el momento a momento y que hay miles de tomadores de decisiones en todos los espacios digitales en los que habito. Tal vez este post sea un manotazo de ahogado de ese idealista que a los 12 años pensó que Linux era el fin de Microsoft y que el terreno está dado para satisfacer la utopía de la computación como espacio propio, moldeado por nuestras opiniones, no por las de otros. Pero tengo una sensación de que por primera vez en mucho tiempo podemos hacer que la máquina se adapte a nuestra forma de pensar, en lugar de que sea al revés.