Estos últimos meses escribí una novela y construí una aplicación, más o menos al mismo tiempo.
La novela es un thriller literario sobre un fenómeno inexplicable en Seattle. La app convierte apuntes de universidad en canciones para estudiar. No tienen nada que ver la una con la otra excepto por que las dos son proyectos de texto que otra entidad tiene que compilar. En un caso lo hace el ordenador. En el otro la compila un lector. Y la sensación de estar construyendo algo que itera constantemente es exactamente la misma.
En los dos casos hice planes detallados antes de empezar, tanto tecnológicos como conceptuales. Sin tener una planificación previa no habría tenido un punto de partida sólido como para saber qué estaba rompiendo cuando las cosas dejaban de funcionar. El plan no predice, sirve para construir un marco donde la improvisación tenga dónde apoyarse.
Pero lo que realmente conecta ambos procesos es lo que viene después: la brecha que se abre entre lo que imaginaste y lo que existe cuando terminas de construirlo.
En programación esa brecha tiene un nombre muy preciso: debugging. Abres los logs y aparece un error de autenticación. Lo corriges y muta en otro error. Corriges ése y descubres que la documentación de la API del proveedor externo estaba obsoleta. Cada capa que resuelves revela la siguiente. En la novela el debugging es la revisión editorial: inconsistencias temporales, objetos que aparecen sin haber sido introducidos, escenas duplicadas porque ampliaste un capítulo sin recortar el que venía después. La mecánica es sorprendentemente similar.
Pero hay una diferencia que me parece importante. En la app, el error tiene una causa identificable. El log te dice qué falló y dónde. La cadena causal es rastreable. En la novela, muchas veces el problema no es técnico sino de experiencia: la escena está bien escrita, la lógica interna es coherente, no hay ningún error factual y, sin embargo, no funciona. No produce lo que debería producir en el lector. Y diagnosticar eso es enormemente más difícil, porque no hay logs. No hay un mensaje de error. Solo hay una intuición de que algo falla, y la tarea de articular qué es exactamente sin tener un sistema que te lo diga.
Es el mismo proceso que recoger feedback de un usuario sobre una funcionalidad que técnicamente funciona pero que no resuelve lo que debería resolver. El lector que lee una escena y no la siente es el usuario que usa una feature y algo no le encaja aunque no sepa explicar qué. En los dos casos, el problema está en la experiencia del otro al recibirlo. Y en los dos casos, esa información solo aparece cuando alguien de fuera entra en contacto con lo que hiciste.
Pero fue la IA la que me ayudó a detectar uno de los problemas más importantes de la novela.
En una conversación sobre el ritmo y la tensión del libro, Claude identificó que el antagonista, construido a lo largo de más de veinte capítulos exclusivamente a través de una investigación realizada por otros personajes, llegaba al clímax sin que el lector hubiera tenido una sola experiencia directa con él. Faltaba el cuerpo. Faltaba la presencia. Añadí escenas breves que cambiaron lo que se siente al llegar al final. Y el origen de esa intervención fue, en esencia, un code review: alguien que revisa tu pull request antes de hacer deploy y te dice que hay un problema estructural que tú no ves porque llevas demasiado tiempo dentro del código.
Eso complica la distinción que parecía clara. En la app, la IA escribió y revisó el código. En la novela, escribió y revisó el texto. En los dos casos ocupó roles que normalmente asociamos con personas: el desarrollador y el editor. Y en los dos casos su contribución fue real. Pero también en los dos casos lo que la IA hacía era operar dentro del proyecto, dentro de la brecha entre intención y resultado: acelerar, señalar, ejecutar. Cuando la aplicación o el libro llegue a los lectores/usuarios continuaré descubriendo distancias entre lo que construí y lo que el otro experimenta al recibirlo. Al final, crear producto y, quizás también escribir ficción, es un ejercicio de acortar esa distancia, iteración tras iteración, sin la certeza de que alguna vez se cierre del todo.
La tecnología resuelve cada vez más pasos del proceso y la ejecución técnica. Lo que queda es la capacidad de construir algo, exponerlo, escuchar y corregir el rumbo.
Los dos proyectos siguen abiertos. La novela necesita más cuerpo. La app necesita un modelo económico que funcione. Los dos se parecen bastante a lo que imaginé al principio. Pero no había un camino previsto para llegar hasta aquí. Lo que hubo fue la decisión de definir, en cada momento, el proceso adecuado para avanzar.
Construir cosas consiste en saber adónde vas y en decidir, en cada momento, cuál es el proceso adecuado para acercarte.
–
¿Te gustan los thrillers y quieres ser betatester de mi novela?
Escríbeme y te la envío.
–
Sígueme en LinkedIn para estar al tanto de nuevas publicaciones.
–