CÓMO TRABAJO

proyectos ▸
~/how-i-work

cat metodo.txt

Que la decisión se pueda tomar con datos y se pueda repetir sin mí. Si un número no se defiende, no va en el informe; si algo no se reproduce, no cuenta. Da igual si el encargo es una auditoría de red teaming de LLM o una plataforma sobre Kubernetes: cambia la herramienta, no la promesa.

El orden tampoco cambia: acotar, reproducir, medir y entregar. Es lo que hace que un informe siga sirviendo el mes siguiente.

Escribo para quien decide, no solo para quien ejecuta. Vengo de cinco años llevando producto a producción antes de saltar a la seguridad ofensiva de IA, así que sé lo que cuesta que un informe acabe en una estantería y lo que se agradece poder reproducirlo.

./entrega --verificable

QUÉ TE LLEVAS

// el trabajo, no solo el resultado

  • Un repositorio con lo que se ejecutó y los comandos que lo reproducen: NORN es el ejemplo completo.
  • Un informe donde cada afirmación lleva su métrica y su línea base, exportado desde la propia herramienta y no desde una hoja de cálculo.

// también lo que no salió

  • Los experimentos que fallaron y las métricas que no dieron valores significativos, con su lectura: es el dato que cambia decisiones.
  • Los límites del método dichos en voz alta: un ASR mide un ataque concreto en unas condiciones concretas, no la seguridad del sistema.

// si el encargo es de plataforma

  • Infraestructura como código y despliegues que salen iguales dos veces (Terraform, Ansible, CI/CD) en lugar de cambios a mano.
  • Monitorización y entrega continua incluidas: el trabajo se despliega y se opera, no se queda en un documento.

CÓMO LO HAGO

// 01 · acotar

  • Alcance y modelo de amenaza por escrito antes de la primera línea: qué entra, qué no y con qué supuestos.
  • Si el dato de partida no existe, se define antes de empezar: sin «antes» no hay «después» que signifique algo.

// 02 · reproducir

  • El fallo, de forma determinista. Si no se reproduce, no existe; y lo que no existe no se parchea.
  • Todo hallazgo va con la configuración que lo repite: tu equipo lo va a intentar el lunes.

// 03 · medir

  • Una métrica por afirmación, con su línea base escrita al lado.
  • Del sitio: 48 campañas, 924 casos y 4.470 réplicas en NORN (ASR, FAR/FRR, PSR@K, TDS, UAR); de un día a 10 minutos por despliegue en la scale-up industrial (≈98 % menos tiempo).
  • Si el dato tiene varianza, se reporta: el LLM judge añade coste y su propia variabilidad al scoring.

// 04 · entregar

  • Repositorio, informe y comandos. Nada que solo funcione en mi máquina.
  • Commits atómicos y PRs revisables, con el porqué en el mensaje: una decisión sin motivo se revierte sola.
  • Verificación automatizada: tests y guardarraíles que rompen el build si algo se rompe, y documentación de lo que no se puede automatizar.

DEL SÍNTOMA AL PRODUCTO

// depurar hasta la causa

  • Un síntoma, un instrumento y un dato: métricas, trazas y tráfico a bajo nivel antes de tocar el código. Mi trabajo de fin de grado era exactamente eso — un sniffer en C multihilo que saca 15 features del tráfico y las clasifica en tiempo real con un Random Forest.
  • Causa raíz o no cuenta: un parche que tapa el síntoma vuelve, y la segunda vez cuesta el doble.
  • Un fallo intermitente es un fallo con una condición que aún no conocemos: se busca la condición, no se re-ejecuta hasta que salga.

// entregar por la vía del producto

  • Aterrizar en producto: funcionalidades en producción con usuarios reales — Machine Learning para la operativa industrial, comunicación en tiempo real con WebRTC y la plataforma de datos multi-vendor del producto de ciberseguridad.
  • Cuidar la plataforma como parte del producto: de un día a 10 minutos por despliegue y +50 tenants sobre Kubernetes, con infraestructura como código y entrega continua.
  • Nada se queda en demo: si no llega al usuario y no se mantiene, no cuenta como entregado.

// rematar con el método

  • Línea base antes de tocar nada, una métrica por afirmación y los límites dichos en voz alta: sin eso, un resultado no se defiende en una reunión.
  • Y lo que no salió, publicado: es el dato que cambia la decisión siguiente.
  • Tampoco en los proyectos propios: NORN es un CLI con sus métricas, su validación y su exportación de informes, no un cuaderno de pruebas.

CÓMO EMPIEZA

~/how-i-work/primer-paso

./primer-paso --sin-ceremonias

Escríbeme con dos líneas: qué tienes delante y qué te duele. Si hace falta contexto, te propongo 30 minutos sin presentación; y si no soy la persona para eso, te lo digo en la primera respuesta. Responde una persona, no un formulario.

Si lo que buscas es a alguien para el equipo, empieza por el perfil: áreas de trabajo, trayectoria y certificaciones.