En un post anterior planteaba una pregunta: Si una IA pudiera construir software completamente sola, ¿en qué lenguaje programaría?
Pero después apareció una pregunta todavía más interesante.
Quizás estamos suponiendo algo que no tiene por qué ser cierto.
Quizás una IA ni siquiera necesitaría un lenguaje de programación.
¿Y si pudiera tomar directamente una historia de usuario, comprender su intención y transformarla en software?
Algo así:
Historia de usuario
↓
IA
↓
???
↓
Código máquina
La pregunta entonces es: ¿Qué debería existir en ese espacio entre la intención humana y el código máquina?
¿Por qué no programar directamente en ensamblador?
Si una IA no tiene las limitaciones de un humano, podríamos pensar: Bueno, que programe directamente en ensamblador.
Después de todo, para una IA escribir esto:
mov eax, [rbp-8]
add eax, 1
no debería ser especialmente difícil.
Incluso podríamos ir un poco más arriba:
- LLVM IR
- JVM Bytecode
- .NET IL
- WebAssembly
Una IA podría trabajar directamente sobre una representación intermedia y olvidarse completamente de Java, Python o Rust. Pero hay un problema.
Estas representaciones están demasiado lejos de la intención original.
Una historia de usuario podría decir: Como usuario, quiero transferir dinero entre dos cuentas.
Y el ensamblador termina hablando de:
- registros
- direcciones de memoria
- saltos
- instrucciones
- calling conventions
Nada de eso tiene que ver realmente con una transferencia de dinero.
Son detalles de implementación.
Y probablemente una IA no querría tomar esas decisiones demasiado pronto.
La pregunta no es: ¿Qué registro debería usar?
La pregunta es: ¿Qué significa transferir dinero?
Hoy el proceso es relativamente conocido:
Código fuente
↓
Parser
↓
AST
↓
IR / Bytecode
↓
Optimización
↓
Código máquina
Y tiene una propiedad extremadamente importante: Es determinista.
Si tenemos:
Código fuente
+
Compilador
+
Configuración
esperamos obtener el mismo resultado.
Eso nos da cosas fundamentales:
- reproducibilidad;
- debugging;
- auditoría;
- control de versiones;
- seguridad;
- testing.
Podemos congelar una versión del software.
Podemos volver atrás.
Podemos comparar cambios.
Podemos saber exactamente qué fue desplegado.
Y si reemplazamos el código por una historia de usuario?
Imaginemos esto:
Historia de usuario
↓
IA generativa
↓
Código máquina
Suena increíble.
Pero aparece un problema.
Supongamos que la historia dice: Como usuario quiero transferir dinero entre dos cuentas.
La primera vez, la IA podría generar:
TransferService
↓
PostgreSQL
↓
Transacción ACID
La segunda vez:
Event Sourcing
↓
Kafka
↓
Consistencia eventual
Y quizás ambas soluciones sean técnicamente correctas.
Pero hay un detalle importante. No son el mismo software.
Incluso aunque la entrada sea exactamente la misma.
Un compilador tradicional no "interpreta" el código cada vez.
No vuelve a pensar qué quiso decir el programador.
Las reglas ya están definidas.
Pero una IA generativa trabaja de otra manera.
Puede existir variabilidad.
Puede cambiar el modelo.
Puede cambiar el contexto.
Puede cambiar la temperatura.
Puede cambiar la recuperación de información.
Puede aparecer una nueva versión del modelo.
Entonces imaginemos algo así:
Historia de usuario
↓
IA versión 1
↓
Software A
Un año después:
La misma historia de usuario
↓
IA versión 2
↓
Software B
Y quizás Software B sea incluso "mejor".
Pero no necesariamente sea compatible con A.
Ni tenga los mismos comportamientos.
Ni las mismas garantías.
Entonces, ¿podemos realmente llamar a eso compilación?
Otra posibilidad interesante sería:
Historia de usuario
↓
Embedding
↓
Espacio vectorial
↓
IA
↓
Código máquina
La idea sería que el software no estuviera representado principalmente como texto.
No guardaríamos solamente:
class TransferService
Sino algo más cercano al significado: Una operación que mueve una cantidad positiva de dinero desde una cuenta hacia otra preservando determinadas invariantes.
Una IA podría trabajar sobre representaciones semánticas.
Buscar conceptos similares.
Relacionar patrones.
Encontrar soluciones previamente utilizadas.
Incluso reutilizar conocimiento sin necesidad de importar una librería de la manera tradicional.
Es una idea poderosa.
Pero también peligrosa.
Porque una base vectorial responde muy bien a una pregunta como: ¿Qué se parece a esto?
Pero el software muchas veces necesita responder: ¿Esto es exactamente esto?
Y esas son preguntas muy diferentes.
Supongamos estas dos reglas:
Un usuario puede acceder al documento.
Un administrador puede acceder al documento.
Para un modelo semántico, ambas frases podrían ser muy similares.
Pero desde el punto de vista del software, la diferencia puede ser crítica.
O estas:
El usuario puede retirar hasta $10.000.
El usuario debe retirar exactamente $10.000.
Una palabra cambia completamente el comportamiento.
Por eso una representación vectorial no debería ser la fuente final de verdad.
Podría ayudar a la IA a:
- encontrar conocimiento;
- recuperar patrones;
- relacionar conceptos;
- reutilizar soluciones;
- comprender contexto.
Pero en algún momento necesitamos algo más preciso.
Algo que podamos versionar.
- Comparar.
- Verificar.
- Congelar.
Quizás el futuro tenga dos etapas. Y acá aparece una arquitectura que me resulta mucho más interesante.
La primera parte puede ser generativa.
La segunda debe ser determinista.
```text
┌──────────────┐
│ HUMANO │
│ │
│ Historias de usuario │
│ Conversaciones │
│ Requisitos │
└────┬─────────┘
↓
┌─────────────┐
│ IA GENERATIVA │
│ │
│ Interpreta │
│ Pregunta │
│ Propone │
│ Diseña │
│ Explora alternativas │
└────┬───────┘
↓
🔒 SE CONGELA
↓
┌───────────────────────┐
│ REPRESENTACIÓN SEMÁNTICA │
│ │
│ Entidades │
│ Reglas │
│ Tipos │
│ Contratos │
│ Invariantes │
│ Propiedades │
└────────┬──────────────┘
↓
┌────────────────────────┐
│ COMPILACIÓN DETERMINISTA │
└──────────┬─────────────┘
↓
┌────────┼────────┐
↓ ↓ ↓
x86 ARM WASM
Y para mí, ese punto donde se congela la intención es fundamental.
Antes de ese punto, la IA puede ser creativa.
Puede explorar.
Puede probar arquitecturas.
Puede buscar alternativas.
Puede decidir si algo debería ser:
- una transacción;
- un evento;
- una cola;
- una función;
- una tabla;
- un servicio distribuido.
Pero después de ese punto, ya no debería cambiar de opinión.
Quizás el futuro de la programación no sea:
Humano
↓
Código
↓
Compilador
↓
Máquina
Sino:
Humano
↓
Intención
↓
IA
↓
Especificación
↓
Compilador
↓
Máquina
La IA sería responsable de responder: ¿Qué quiso decir el humano?
La especificación respondería: Esto es exactamente lo que el sistema debe hacer.
Y el compilador respondería: Entonces esto es lo que voy a ejecutar.
Quizás esa sea la verdadera frontera
Hoy usamos IA para generar código.
Le damos un prompt y obtenemos:
@Service
public class TransferService {
...
}
Pero eso quizás sea solo una etapa intermedia.
Tal vez en el futuro ni siquiera queramos revisar Java. Ni Python. Ni Rust.
Queramos revisar directamente algo como:
ENTITY Account
INVARIANT
balance >= 0
OPERATION transfer
FROM source
TO destination
AMOUNT amount
REQUIRES
amount > 0
source.balance >= amount
ENSURES
source.balance decreases by amount
destination.balance increases by amount
Eso sería mucho más cercano a la intención que al código.
Y después podríamos dejar que el sistema decida si eso termina convertido en:
- Rust;
- Java;
- SQL;
- WebAssembly;
- bytecode;
- ensamblador.
Entonces, ¿qué debería ser generativo y qué debería ser determinista?
Creo que esa puede ser la verdadera división.
Generativo:
- Comprender requisitos
- Resolver ambigüedades
- Diseñar
- Explorar alternativas
- Optimizar
- Buscar patrones
Determinista:
- Representar la especificación
- Verificar reglas
- Validar invariantes
- Compilar
- Ejecutar
Porque si dejamos que una IA generativa vuelva a interpretar la intención cada vez que "compilamos", entonces algo extraño ocurre.
Ya no estamos compilando el software. Estamos volviendo a diseñarlo cada vez.
Y eso puede ser fantástico durante la creación.
Pero sería aterrador en producción.
No hay comentarios.:
Publicar un comentario