De tu commit a tu LinkedIn

En la voz del autor, con evidencia citable. Es lo que su audiencia ve en LinkedIn / X.com.

Un audit reveló 5 deudas de tipos en mi working tree que llevaban semanas ahí.

Ninguna se introdujo en el commit que estaba revisando. Todas se acumularon antes — cada vez que extendí un union type, cambié una API o moví una constante, sin correr el gate completo.

El gate son tres comandos:

pnpm typecheck
pnpm exec vitest run
pnpm build

Si los tres salen verdes, el código califica para "shipped". Si alguno falla, todavía no está listo — por más que funcione en mi máquina.

Lo importante: el gate no es "buena práctica". Es el piso compilatorio. Lo que está debajo no es código entregable; es código en progreso que aún no lo sabe.

El costo de correrlo ahora son 90 segundos. El costo de no correrlo es una sesión forense de 2 horas tres semanas después, intentando atribuir cuál de 18 commits introdujo la deuda.

Lo dejé escrito como lección permanente del proyecto — ver fuente.

En la voz del autor, con evidencia citable. Es lo que su audiencia ve en LinkedIn / X.com.

Detuve a mi agente 11 veces en una sesión para "aprobar el próximo paso".

Cada parada era una transición mecánica. El agente ya sabía qué seguía — yo era la pieza lenta del flujo.

Lo que cambió todo fue volver explícitas las únicas tres razones legítimas para detenerse:

E1 — contradicción irresoluble entre dos documentos del corpus.
E2 — input requerido que genuinamente no existe.
E3 — operación destructiva irreversible.

Si la parada no cae en E1, E2 o E3, no es una parada — es una solicitud de tranquilidad disfrazada de gobernanza. Y duplica el tiempo de cualquier task.

La versión sana: el agente corre la directiva end-to-end, decide cada juicio citando qué lección/spec/declarativa lo justifica, y emite un Decisions Log dentro del entregable. Yo reviso una vez, al final — acepto, o rechazo nombrando el modo de falla específico.

Es la diferencia entre dirigir un colaborador y supervisar un aprendiz.

En la voz del autor, con evidencia citable. Es lo que su audiencia ve en LinkedIn / X.com.

Tres consultas que dejé sin caché a propósito:

1. status del post (draft / scheduled / publishing / published).
2. scheduled_at de cada publicación.
3. publish_attempt_count.

Las tres son business state. Las tres son correctness-sensitive. Una lectura stale de status="scheduled" mientras el row ya pasó a "publishing" es exactamente cómo se generan publicaciones duplicadas.

Redis sirve para colas (BullMQ) y rate limiting. No para business data. La latencia que ganaría cacheando esos campos no compensa el costo de un solo double-publish: un cliente que ve su post dos veces en LinkedIn pierde confianza en el producto en segundos.

El claim atómico es una sola query:

UPDATE schedules SET status = 'publishing'
WHERE id = $1 AND status = 'scheduled'
RETURNING *;

Dos workers compitiendo por el mismo schedule no pueden ambos ganar. El que pierde recibe cero filas y cede. Cero duplicados, cero coordinación distribuida, cero capa adicional de software.

Lo barato no es Redis. Lo barato es Postgres haciendo su trabajo.

En la voz del autor, con evidencia citable. Es lo que su audiencia ve en LinkedIn / X.com.

Lancé mi feature de "fuentes" como librería: 35 items, filtros por repo, click para preview, un botón "Crear post" en cada detalle.

Abrir la pestaña se sentía igual todos los días. Los mismos 35 items. No podía distinguir lo nuevo de lo viejo. Lo que ya había usado no se diferenciaba de lo que tenía pendiente.

Después de tres semanas reescribí la pantalla como inbox:

— Estado por item (nuevo / archivado / guardado / en uso).
— Vista por defecto: solo los "nuevos".
— Cada fila ofrece un verbo primario (descartar, guardar, llevar al editor).
— Badge en el sidebar: número de items sin procesar.

Esa última línea fue la que cambió la sensación de uso. Pasó de "lista interminable" a "línea de meta". Cuando el badge baja a cero, terminé. Cuando vuelve a 5, sé exactamente qué hay nuevo.

Library thinking te hace abrir los mismos 35 items todos los días. Inbox thinking te da una promesa: si triagas, terminas.

Si tu colección crece más allá de un puñado de filas, la decisión no es "qué filtros agrego". Es "qué estados de triage tienen sentido".

En la voz del autor, con evidencia citable. Es lo que su audiencia ve en LinkedIn / X.com.

commitvoice corre en un VM de Hetzner de €15/mes. Postgres, Redis, API, web UI, almacenamiento de imágenes — todo en la misma máquina.

No es ascetismo. Es disciplina de moat.

Cada vez que evaluamos un servicio managed nos hacemos una pregunta: ¿qué moat me da que self-host no puede igualar?

— Postgres managed (Neon, Supabase) → branching + autoscale. No los necesito a mi escala. Self-host.
— Redis managed → alta disponibilidad multi-AZ. No la necesito todavía. Self-host.
— Storage S3/R2 → throughput global + lifecycle policies. Cuando el filesystem local sea un problema real, migro. Self-host.
— Make.com como puente de publishing a LinkedIn → compliance + OAuth review de LinkedIn. Moat real. Managed.

La regla simple: cada SaaS gerencial que agrego es una superficie más de riesgo, una factura más, un vendor lock-in más, una cuenta más que rotar credenciales. Lo agrego solo cuando el moat es genuino y nombrable.

No es "soy hardcore". Es que cada decisión managed tiene que defenderse contra una alternativa self-host concreta. La mayoría no lo hace.

En la voz del autor, con evidencia citable. Es lo que su audiencia ve en LinkedIn / X.com.

1/ Bun 1.2 sacó bundler con CSS nativo y benchmarks 3-4x vs Vite+esbuild en SPAs medianas.

Mi instinto: no migrar. Comparto por qué.

2/ Mi build local con Vite tarda 1.8s. Si bajara a 0.5s, el cambio sería invisible: ya estoy en HMR el 95% del tiempo, no en cold start.

El 3-4x suena enorme. En segundos absolutos: 1.3s ahorrados por build. ~5 builds frescos al día. ~7s diarios.

3/ El verdadero costo no es la migración técnica (que es chica). Es la superficie de bugs nueva.

Vite tiene 5 años de issues cerrados de mi stack específico (React + Tailwind + MDX + Astro plugins). Bun va a tener su propia lista — no peor, pero diferente.

4/ Cuándo sí migraría:
— Cold start de CI > 2 min (no es mi caso, 28s).
— Equipo grande donde el tiempo de build agregado > 1h/día.
— Necesito el runtime de Bun por otra razón (workers, FFI).

5/ Regla: una mejora 3x en algo que ya no es bottleneck es bait. Lo nuevo es interesante por lo nuevo, no porque te resuelva un problema real.

Cita del newsletter ↓