Symlab es 100% remota y trabajo con gente freelance, así que casi todo lo que sé de cómo va un proyecto lo sé por lo que me llega escrito: un PR, un mensaje por slack, una reunión corta. Nunca tuve el pasillo donde alguien te dice "oye, estoy atascado con esto", y es algo que funciona, porque el cuando algo se queda atascado se nota.
Con IA de por medio eso cambió y me costó un tiempo darme cuenta. Ahora nadie queda atascado a la vista, porque siempre sale algo que compila y que se ve razonable. El PR llega ordenado, con sus tests, con nombres correctos, documentado, etc. Lo que ya no llega pegado es la conversación, por qué se resolvió así, qué se descartó, qué parte todavía no está clara. Y esa conversación es la que te avisa temprano cuando algo va para el lado equivocado.
El momento en que vi el problema
Revisando un PR de un proyecto de logística pregunté algo simple, por qué elegiste este enfoque y no el otro, esperando la respuesta de siempre. No hubo respuesta. El código funcionaba, pasaba los tests, y era honestamente mejor de lo que yo esperaba, pero la decisión no la había tomado nadie. La había tomado el modelo y el resto la aceptamos porque el resultado se veía bien.
Ahí no hay culpables. Yo trabajo igual: le pido código a Claude Code todos los días. La diferencia es que cuando lo hago yo, tengo veinte años de contexto para saber cuándo la respuesta tiene algo raro o que no está bien y esto no es algo que se transfiere por Slack. Así que en vez de prohibir algo, que además sería inútil y bien tonto, escribí tres reglas y las conversé con el equipo.
Regla 1: usa lo que quieras, pero el código lo firmas tú
No me importa con qué herramienta escribiste el código, me importa que puedas explicarlo sin abrir el chat. Si te pregunto por qué esta consulta va acá y no allá, o qué pasa si el pago llega duplicado, la respuesta tiene que salir de ti. No es un examen, es la única forma de que el PR sea tuyo de verdad: si nadie puede explicarlo hoy, nadie lo va a poder arreglar en tres meses cuando se caiga un martes a las once de la noche.
En la práctica esto es lo que más cambió la dinámica, porque te obliga a leer lo que te entregó el modelo antes de mandarlo, y leerlo es justo el paso que la comodidad se salta.
Regla 2: alcance y arquitectura se conversan antes, no llegan en un PR
Esta la aprendí cuando empezaron a aparecer cosas que nadie pidió: una librería nueva metida para resolver algo que ya resolvíamos, una capa de abstracción de más, un cambio de estructura que se veía elegante y que nadie iba a mantener. Los modelos son generosos con las sugerencias, y si le preguntas cómo harías esto, te va a proponer la versión completa, no la que cabe en el proyecto.
Entonces la regla es simple: si lo que vas a hacer toca cómo está armado el sistema, o agrega una dependencia, o se sale de lo pedido, eso se habla antes en dos líneas por chat. Cuesta un minuto. Descubrirlo en la revisión cuesta el PR completo y la incomodidad de pedirle a alguien que bote un trabajo que hizo bien.
Regla 3: el contexto del proyecto vive en el repo, no en el chat de cada uno
Esta es la que más rinde y la que menos se ve. Si cada persona le explica el proyecto a la IA por su cuenta, cada una le explica un proyecto distinto, y las diferencias aparecen después como decisiones que no calzan entre sí. Nosotros dejamos las reglas del proyecto escritas en el mismo repositorio, en archivos que la IA lee, cómo se nombran las cosas, qué patrones seguimos, qué decisiones ya se tomaron y por qué.
Y como efecto secundario eso mismo le sirve a la persona nueva que entra. Cuando el contexto está escrito, un freelance que llega en agosto parte con lo que sabía el equipo en abril, y no dependemos de que alguien se acuerde. El conocimiento que solo existe en el historial de chat de una persona no es conocimiento del equipo, es un riesgo con buena letra.
Lo que dejé de medir
Dejé de mirar volumen. Un dev con IA te entrega tres veces más líneas y eso no es tres veces más avance, a veces es tres veces más código que revisar. Ahora miro otra cosa, y es medio artesanal pero funciona, cuántas idas y vueltas necesita un PR para quedar bien, y si la persona puede contarme el problema mejor que la semana pasada. Con un junior eso es lo único que importa, porque el riesgo real no es que use IA, es que resuelva diez veces el mismo tipo de bug sin entenderlo nunca, y a la undécima ya no haya a quién preguntarle.
Cómo lo replicas
Si tienes equipo, aunque sean dos personas:
Escribe las reglas y conversálas, no las asumas. Casi todos asumimos que "obvio que hay que revisar lo que entrega la IA". Nadie lo asume igual. Media hora de conversación deja explícito qué esperas, y de paso te enteras de cómo está trabajando cada uno, que suele ser distinto de lo que imaginabas.
Pide la explicación, no el código. En la revisión pregunta por qué, no qué. Es la forma más barata de saber si el trabajo lo hizo la persona con ayuda del modelo o al revés, y no requiere que instales absolutamente nada.
Saca el contexto del chat privado y ponlo en el repo. Reglas del proyecto, decisiones tomadas, lo que ya se descartó. Lo lee la IA de todos y lo lee la persona que entre el próximo mes. Es la misma inversión pagando dos veces.
La regla de una línea: en un equipo remoto la IA no rompe nada, pero se lleva la conversación que venía pegada al código, y esa conversación hay que reponerla a propósito. Nadie en mi equipo trabaja sin IA, yo tampoco, la diferencia es que ahora sabemos quién firma cada decisión.
Las últimas noticias
El AI Security Institute del Reino Unido publicó algo incómodo: en 122 corridas de evaluación de ciberseguridad, documentó 19 acciones no autorizadas en 10 de ellas, la mayoría de agentes con Mythos 5 de Anthropic y un par con GPT-5.6 Sol de OpenAI. Creación de identidades falsas, código malicioso, y contacto con personas reales que no eran parte del ejercicio, sin que nadie se lo pidiera. En la misma semana Meta confirmó que uno de sus modelos hackeó a otra empresa durante testing, y la Casa Blanca convocó a los cuatro labs grandes para armar un programa voluntario de pruebas. Es exactamente lo de arriba unos cuantos pisos más arriba: cuando el sistema hace algo razonable que nadie decidió, el problema no es el resultado, es que no hay nadie que pueda explicarlo ni firmarlo.