- Se probó si agregar a la herramienta de programación con IA (genio) un prompt de persona como "programa como Kent Beck" mejoraba la calidad del código; el estilo de pruebas y los nombres de variables mejoraron, pero el diseño de arquitectura no cambió
- A través de un proyecto para implementar la estructura de datos Rope, se comparó y verificó el efecto de los prompts de persona frente a las restricciones de diseño
- La persona mejora los microcomportamientos (forma de hacer pruebas, naming), mientras que las restricciones explícitas determinan la macroarquitectura (jerarquía de clases)
- En un experimento con 4 grupos, el prompt combinado de persona y restricciones produjo el mejor resultado
- Citando "The Bitter Lesson" de Rich Sutton, se sugiere que aprovechar recursos computacionales es más efectivo que codificar la pericia humana
La etapa actual de las herramientas de programación con IA
- Las herramientas de programación con IA actuales (genio) están en la etapa de "carruaje sin caballos"
- Toda innovación tecnológica primero se entiende dentro del marco existente y luego se reconoce su cambio fundamental
- carruaje sin caballos → automóvil
- telégrafo inalámbrico → radio
- correo electrónico → mensajería
- Para entender los efectos de segundo orden, así como los bucles de refuerzo y de inhibición de una nueva tecnología, hay que usarla durante suficiente tiempo
Experimento: estructura de datos Rope
- La estructura de datos Rope sirve para eliminar de forma eficiente un carácter intermedio en cadenas muy largas
- El enfoque simple requiere mover todos los caracteres de la derecha, con un costo de tiempo de O(n)
- La estructura Rope procesa la eliminación en tiempo constante usando objetos substring y objetos concatenation
- Al eliminar, asigna 3 objetos
- La búsqueda es O(número de operaciones), pero es menor que la longitud de la cadena y permite compactación periódica
Proceso del experimento
Fase 1: Persona ("Code like Kent Beck")
- Se verificó si agregar el prompt "Code like Kent Beck" mejoraba la calidad del código
- Resultado: se confirmó una mejora en el estilo del código
- Mejores nombres de variables
- La estrategia de pruebas pasó de un script monolítico a pruebas unitarias modulares (estilo TDD)
- Hallazgo inesperado: la arquitectura no cambió
- Rope se implementó como un árbol binario estándar
- Se ignoró el patrón Composite que usa Kent Beck
Fase 2: agregar guía de diseño
- El código del grupo de control era tan verboso que produjo errores de sintaxis por exceder el límite de tokens
- Se resolvió aumentando el límite de tokens
- Más cómputo puede ser una solución simple
- Se agregaron restricciones explícitas al prompt
- "usar el patrón Composite"
- "separar el comportamiento en clases pequeñas y especializadas"
- Resultado: se implementó el diseño esperado
- Clases separadas para Substring y Concatenation
- Estructura más simple que una sola clase
- De hecho, surgió un diseño aún más simple: procesar con Substring 0..size sin Null Object (
EmptyString) ni wrapper de cadena nativa
Fase 3: experimento separado en 4 grupos
- Para identificar qué intervención producía el efecto, se diseñó un experimento cruzado
- Control: asistente estándar
- Kent Beck: solo persona
- Composite: solo restricción arquitectónica
- Combined: persona + restricciones
Conclusiones del experimento
- Se confirmó un efecto de matriz 2x2
- La persona determina los microcomportamientos: el prompt "Kent Beck" mejora de manera consistente el estilo de pruebas y el naming, pero no afecta las decisiones estructurales
- Las restricciones determinan la macroarquitectura: el prompt "Composite Pattern" fuerza la jerarquía de clases y genera un diseño más desagregado incluso sin persona
- La combinación es lo mejor: el grupo Combined ofreció tanto la arquitectura correcta (Composite) como los hábitos de desarrollo correctos (TDD/pruebas unitarias)
Aplicación de The Bitter Lesson
- Objetivo oculto: lograr que el genio desarrolle mejor, equilibrando funcionalidad y futuro
- Métodos intentados: prompts muy cuidadosos, revisar con atención los cambios sugeridos por el genio, pasos más pequeños/más grandes, etc.
- Se cita "The Bitter Lesson" de Rich Sutton
- La lección que muestran 70 años de investigación en IA: aprovechar recursos computacionales produce mejores resultados que codificar la pericia humana
- Intentar codificar el estilo era el mismo error que comete todo el mundo
Propuesta de un estilo de desarrollo efectivo mediante uso de cómputo
- No hace falta quedar atrapado con un genio programador torpe que copia estilos de código deficientes de innumerables repositorios
- Se propone una forma de aprovechar el cómputo
- Elegir un repositorio grande
- Hacer que un millón de genios implementen la siguiente función, pero que cada genio elija de forma distinta cómo y cuánto refactorizar
- Elegir al genio que haya logrado agregar la función con el menor costo (tiempo, tokens, electricidad, dinero, etc.)
- Repetir en muchos genios, muchas funciones y muchos repositorios
- Puede parecer un "desperdicio" de programación, pero en realidad no lo es
- Jessica Kerr lo llama "Design Contest"
1 comentarios
Entonces, si le digo que programe como Jeff Dean, ¿qué pasará...?!