Has heredado una base de código de aplicación web — Laravel, Symfony, un servicio Node o Python, en lo que sea que el equipo estuviera construyendo — que el equipo ya no puede razonar. Los tests fallan de formas que nadie puede rastrear; la misma operación tiene cuatro grafías y cuatro puntos de llamada. Yo leo el repositorio, escribo el diagnóstico y me pongo al teclado cuando decides que el informe por sí solo no basta.
CTOs y lead developers con una base de código de aplicación web — PHP/Laravel/Symfony, Python, una capa JavaScript/TypeScript o Node, o las costuras donde el daño del LLM las atraviesa — en la que el equipo lleva medio año o más aterrizando PRs asistidos por IA, y que hoy nadie del equipo describiría ya como "fácil de razonar".
Reescrituras greenfield. Arreglos de un solo archivo. Repositorios donde el equipo está contento con el código y solo quiere más, más rápido.
Triage de medio día. Diagnóstico escrito con la hemorragia priorizada. Opcionalmente, un encargo de seguimiento para la reparación real, por hora o por proyecto — tu decisión después de leer el diagnóstico.
La cobertura era del 72%, ahora del 18%, y nadie en el equipo puede señalar las PRs que la bajaron. Los umbrales de CI se han relajado dos veces este trimestre para mantener la pipeline en verde.
Controladores por encima de 1.500 líneas. Clases de servicio que importan veintidós colaboradores. La autora o el autor ya no está en la empresa y la intención original no se puede recuperar de git blame.
getUser, fetch_user, Customer::find, UserRepository::byEmail. Cuatro puntos de llamada, cuatro formas de retorno ligeramente distintas, un bug que nadie consigue reproducir.
Funciona en local. Rompe en staging de maneras que cambian con cada deploy. El equipo culpa a los tests flaky; los tests están bien. Se han colado en silencio race conditions y consultas n+1, en PRs que se leen como generados.
Treinta minutos, sin factura, sin pitch deck. Traes el repositorio o una descripción; te digo lo que veo y lo que haría. El diagnóstico es a tarifa plana de medio día, acordada antes de empezar. La reparación es por hora o por proyecto, alcanzada desde el diagnóstico, nunca abierta.
Una revisión te entrega una lista. Un encargo de limpieza la cierra. El diagnóstico es prosa revisada que explica, archivo por archivo, cuál es el daño y cuánto costaría repararlo; el encargo opcional de seguimiento es la reparación en sí. El documento de diagnóstico es tuyo, sigas o no.
No. El trabajo es limpieza de aplicaciones web en general. Es más afilado en PHP, Laravel, Symfony, JavaScript/TypeScript, Node y Python — los stacks en los que tengo más horas — y otras bases de código (un servicio Go, un backend Django o FastAPI, Ruby, etc.) las tomo caso por caso. Un diagnóstico débil es peor que ningún diagnóstico, así que te diré en la llamada de triage si una base de código queda fuera de donde puedo aportar valor.
Una tarifa plana de medio día, acordada en la llamada de triage antes de empezar a trabajar. La llamada en sí es gratis y dura treinta minutos. Sin obligación de continuar al diagnóstico tras la llamada, ni a la reparación tras el diagnóstico.
Sí. NDA mutuo antes de que el código cruce mi mesa es lo estándar; firmo el tuyo o te envío uno breve. El acceso al repositorio es de solo lectura por defecto, limitado a la duración del encargo.
Un formulario corto. Sin newsletter, sin plataforma, sin secuencia de seguimiento. Un ingeniero senior lee lo que envías y responde en un día laboral.