Escribo esto un domingo, como siempre. Y esta semana la tengo que ordenar alrededor de una pregunta bastante simple: ¿cuánto de lo que planificamos sobrevive cuando llega el momento de hacerlo?
De la computadora a la mesada
Hace dos semanas escribí sobre Marín y su idea de que el jefe define el qué y el cuándo, y el equipo encuentra el cómo. Esta semana me tocó el cómo. Y el cómo, en un laboratorio, se define en la mesada.
Durante bastante tiempo trabajamos sobre procedimientos, normas, equipos, cálculos y documentación. Estudiamos, consultamos bibliografía, usamos inteligencia artificial, hablamos con gente que sabe más que nosotros. Todo tenía una lógica bastante clara sobre el papel.
Después pusimos una muestra sobre la mesa.
Y ahí empezó otro aprendizaje. El recipiente que parecía perfecto no es tan cómodo. El filtrado necesita una adaptación. Los tiempos reales no coinciden con los imaginados. Hay que decidir dónde apoyar una muestra, cómo evitar contaminación cruzada, cómo limpiar, cómo registrar, cómo mover cada cosa y cómo asegurarse de que otra persona pueda repetir exactamente lo mismo.
Son detalles chicos. Pero uno detrás de otro terminan definiendo si existe un procedimiento o solamente una buena descripción de cómo debería hacerse.
La conclusión es casi obvia, y por eso conviene escribirla: la realidad agrega variables que desde un escritorio no se ven.
Comprar equipos es fácil
Esta semana hubo bastante orden y limpieza. Parece la parte menos importante de montar un laboratorio. Cada vez creo menos que lo sea.
Ordenamos elementos, muestras y espacios de trabajo. Y trabajamos bastante sobre cómo registrar lo que pasa durante cada ensayo. Porque comprar equipos es relativamente fácil. Construir un sistema repetible es otra cosa.
Que una muestra ingrese y quede identificada. Que sepamos quién la recibió. Que otra persona pueda ejecutar el procedimiento. Que los cálculos no dependan de quién estaba trabajando ese día. Que exista una revisión antes de emitir algo. Y, sobre todo, que si dentro de seis meses alguien pregunta por qué llegamos a un resultado, podamos reconstruir el camino.
Ese es el laboratorio que me interesa construir. Y cuanto más avanzamos, más claro tengo que probablemente no sea un laboratorio tradicional.
Quiero llevarlo hacia un modelo con la menor intervención humana posible en las tareas donde una persona no agrega valor. No para reemplazar gente porque sí: para reservarla para lo que necesita criterio. Una persona observa, interpreta, detecta una anomalía, decide, revisa. Si un sistema puede completar un informe, hacer los cálculos, controlar rangos y detectar inconsistencias, no tiene mucho sentido pedirle a alguien que lo haga a mano cientos de veces.
La idea empieza a ser algo así: menos trabajo repetitivo y más controles independientes. Una persona ejecuta. El sistema registra. Otro sistema verifica. Alguien con criterio técnico valida.
Estamos lejos de tenerlo resuelto. Pero ya sabemos hacia dónde caminar.
Cuando la mejor IA es una regla
Curiosamente, afuera del laboratorio estamos aplicando el mismo criterio.
Venimos construyendo nuestro pequeño equipo de agentes. Hoy tienen nombres, roles y responsabilidades distintas: Elvira, Baltasar, Ofelia, Anselmo, Florencio, Prudencio, Registrador. Unos trabajan sobre comercial, otros sobre finanzas, otros sobre tareas técnicas, marketing o control.
Pero nos impusimos una condición: el costo operativo incremental tiene que tender a cero. No queremos veinte agentes porque tecnológicamente sea posible. No queremos una demostración espectacular que después sea absurda desde lo económico. Queremos algo bastante menos emocionante: que funcione.
Y al auditar el sistema apareció una enseñanza incómoda. A veces, para automatizar bien algo, la mejor decisión es no usar inteligencia artificial.
Encontramos procesos sobredimensionados para nuestro volumen actual. Si una decisión se resuelve con una regla clara, una regla es mejor. Si pasa A, hacé B. No hace falta preguntarle a un modelo de lenguaje. Cada capa que agregamos suma costo, latencia, mantenimiento y nuevas formas de equivocarse.
Parece una contradicción viniendo de alguien que está metiendo IA en toda su empresa. Creo que justamente ahí está el aprendizaje: adoptar inteligencia artificial no significa usarla en todo. El objetivo es el sistema más eficiente posible, no el que tenga más IA. Y probablemente en los próximos años veamos bastante sobreingeniería solo porque tenemos herramientas nuevas y queremos usarlas. Nosotros incluidos.
Por eso auditar, simplificar y eliminar también empieza a ser parte del trabajo.
Le pedimos que destruyera su propia idea
Algo parecido pasó el fin de semana con otra conversación.
Le pedimos a una inteligencia artificial que buscara una oportunidad de negocio. La idea inicial sonaba muy bien. Después hicimos algo que quiero repetir bastante más seguido: le pedimos que intentara destruir su propia propuesta. No mejorarla. No venderla. Buscar por qué podía fracasar: quiénes eran los competidores, por qué alguien no pagaría, qué supuestos estábamos inventando, qué parte del atractivo venía simplemente de que la idea estaba muy bien escrita.
Después de algunas vueltas, una de las propuestas terminó siendo prácticamente un negocio que nosotros mismos habíamos explorado tiempo atrás y que habíamos decidido frenar porque no conseguimos validar ingresos suficientes.
Me pareció fantástico. Probablemente evitamos volver a enamorarnos de algo que ya habíamos aprendido.
La IA genera ideas, planes, nombres, arquitecturas y proyecciones extremadamente convincentes a una velocidad extraordinaria. Pero hay una pregunta que ninguna presentación puede esquivar: ¿alguien quiere pagar por esto?
De ahí sale algo que quiero aplicar con más disciplina: validar antes de construir. O, al menos, construir solamente lo indispensable para aprender. Los que somos técnicos tenemos una tendencia bastante típica —yo la tengo—: nos gusta construir, resolver, diseñar la herramienta, mejorarla, agregarle cosas. Y la pregunta comercial aparece después. Cuando quizás debería aparecer antes.
Sigo siendo consultor
Mientras todo esto pasa, sigo siendo consultor. Y esta semana la convivencia fue bastante visible: entre muestras, agentes e ideas nuevas también hubo que volver a sentarse frente a modelos, documentos y correcciones técnicas para WSP. Horas de trabajo tradicional. Geología. Modelado. Revisión. Informes.
Hay una tensión ahí. Por un lado trato de construir sistemas que dependan cada vez menos de mis horas. Por otro, sigo haciendo un trabajo donde buena parte del valor es justamente mi experiencia y mi criterio.
Durante mucho tiempo lo pensé como dos cosas opuestas. Ahora no estoy tan seguro. La consultoría genera caja, pero también genera problemas reales, relaciones, datos, errores, preguntas. Y muchas de las ideas que después intentamos convertir en tecnología aparecen porque primero vivimos esos problemas trabajando como consultores.
Quizás no se trate de dejar de ser consultor para convertirse en empresario. Quizás se trate de aprender qué cosas necesitan de mí y cuáles tengo que conseguir que funcionen sin mí.
Qué queda después
Eso conecta con una pregunta que me acompaña hace tiempo: cuáles son los verdaderos sí y, sobre todo, cuáles son los verdaderos no.
Decir que no parece sencillo cuando uno lo lee en un libro. Emprendiendo no lo es. Una oportunidad genera dinero, otra abre una relación, otra permite aprender, otra tiene un cliente interesante, otra podría volverse grande. Y de repente todas merecen un sí. El problema es que el tiempo sigue siendo finito.
Todavía estoy construyendo ese filtro. Pero cada vez me interesa más una sola pregunta: ¿qué queda después de hacer este trabajo?
Puede quedar dinero. Pero también un cliente, un procedimiento, tecnología, conocimiento, datos, recurrencia o una capacidad que podamos volver a usar. Cuando al terminar un proyecto solo quedan horas facturadas y hay que empezar de cero con el siguiente, quizás haya que mirarlo distinto. No significa rechazarlo. Significa saber qué estamos comprando con nuestro tiempo.
Al final, las historias de esta semana son la misma historia.
Un laboratorio físico donde probamos ensayos. Un laboratorio digital donde probamos agentes. Ideas de negocio que sometemos a crítica antes de avanzar. Y consultoría sobre problemas reales. En los cuatro hacemos lo mismo: probamos, medimos, nos equivocamos, corregimos, simplificamos, volvemos a probar. Y cuando algo funciona, intentamos convertirlo en un procedimiento.
Quizás, sin haberlo planificado así, GEXPLO se esté convirtiendo en un laboratorio bastante más grande que el que tenemos en la oficina: uno sobre cómo construir una empresa chica capaz de hacer cosas que normalmente requieren estructuras mucho mayores. Con inteligencia artificial, sí. Pero también con orden, criterio técnico y procesos simples.
Ni la teoría alcanza sola ni la prueba y error alcanza sola. La teoría evita empezar de cero. La experiencia muestra qué estaba mal en las hipótesis. Los datos separan percepción de realidad. Y el criterio aparece al decidir qué hacemos con todo eso.
Estudiar lo suficiente para empezar mejor. Ejecutar lo suficientemente rápido para encontrarse con la realidad. Cambiar lo suficientemente rápido cuando la realidad demuestra que la idea estaba equivocada.
Sirve para un ensayo. Para un agente. Para un negocio. Y probablemente también para una empresa.
Pedro Cardoso, CEO & Founder de GEXPLO