La complejidad esencial es el punto único de venta del desarrollador
La complejidad esencial es única ventaja del desarrollador
En mi publicación anterior, resalté la diferencia entre eficiencia y eficacia y cómo se relaciona con la inteligencia artificial versus la inteligencia humana. Hacer las cosas rápido y con el mínimo desperdicio es el dominio de los algoritmos deterministas. Pero saber cuándo estamos construyendo lo correcto (eficacia) es nuestro dominio. Es un desafío resbaladizo y subjetivo, ligado a la confusa realidad de tratar de hacer la existencia humana más cómoda con la ayuda del software.
Hoy quiero hablar sobre la complejidad esencial. Un programador de IA completamente autónomo necesitaría que se le dijera exactamente lo que queremos y por qué, o debería estar lo suficientemente sintonizado con nuestros valores como para llenar los vacíos. Lamentablemente, todavía no podemos confiar en la IA para conectar los puntos de manera confiable sin ayuda y correcciones humanas. No es como decirle a un vehículo autónomo a dónde quieres ir. Eso tiene un objetivo muy simple, y todavía no estamos cerca de una implementación infalible.
La complejidad esencial se trata de “depurar la especificación”, descubrir lo que nosotros, las personas, necesitamos y por qué lo necesitamos. La complejidad accidental es una consecuencia de las alternativas que elegimos para implementar estas ideas. La distinción duradera de Frederick Brooks entre complejidad esencial y complejidad accidental es análoga a los ámbitos de la inteligencia humana versus la inteligencia de máquina, similar a la distinción de eficacia/eficiencia de la publicación anterior.
Dado que la producción de software completamente autónomo por parte de los empresarios solo funcionaría si declaran exacta y sin ambigüedades lo que quieren, los desarrolladores concluyen con suficiencia que sus trabajos están seguros. No estoy tan seguro de que esas especificaciones perfectas sean una condición necesaria. Quiero decir, no lo son ahora. ¿Quién pospone la codificación hasta que tenga especificaciones completas, no ambiguas y finales? Programar significa desarrollar la especificación en tu IDE a partir de una hoja de ruta lo suficientemente clara, completando los detalles a medida que avanzas. No es solo una implementación; es colocar los ladrillos para el primer piso mientras aún estás ajustando el dibujo del techo. Parece ineficiente, pero resulta que no podemos imaginar nuestra casa de ensueño perfectamente a menos que estemos a medio camino de construirla, al menos en lo que respecta a hacer software.
La IA ya está muy calificada para lidiar con gran parte de la complejidad accidental que encuentras en el camino. Deberíamos usarla tanto como podamos. Sé que dediqué tres artículos al examen de Java OCP 17 (enlace aquí para la Parte 1, Parte 2 y Parte 3), pero creo (y espero) que el conocimiento de rutina de detalles arcanos desaparezca. La IA se encarga del uso idiomático, puede hacer cumplir un código limpio, buenas convenciones de nomenclatura e incluso escribir documentación de origen. Y cada vez será mejor en eso. Incluso puede realizar migraciones completas de código heredado a nuevas versiones de lenguaje y marcos. Estoy a favor de eso. Migrar una bestia de Java 4 EJB2 a microservicios de Spring Boot 3 a mano no es mi idea de diversión.
- Cómo uso ChatGPT como ingeniero LLM para crear proyectos rápidamente
- OpenAI presenta la tercera iteración de DALL·E
- Transformadores de Visión en Agricultura | Innovación en la Cosecha
Si dentro de cinco años, el estado del arte en la asistencia de código aún te deja impresionado al escribir código, probablemente no sea debido a alguna complejidad accidental que la máquina no pueda manejar. Es muy probable que sea la complejidad esencial con la que no puede lidiar. Si tu calculadora de hipotecas muestra una tasa de interés hipotecaria del 45.4% y el copiloto no te advierte que probablemente confundiste un punto decimal, es porque nunca ha comprado una casa y no se dará cuenta de que la cifra es una orden de magnitud demasiado alta.
La complejidad esencial se puede expresar en cualquier VoAGI; no necesariamente tiene que ser código informático. Una vez que sabes exactamente cómo debería funcionar algo, la mayoría de los desafíos de programación se vuelven fáciles en comparación, siempre y cuando seas competente en tu lenguaje de elección. Entonces, desglosamos dominios complicados en fragmentos manejables y hacemos crecer el producto, mejorándolo y expandiéndolo con cada iteración. Eso no siempre funciona. A veces, la complejidad esencial no puede reducirse y necesitas un golpe de genialidad para avanzar.
Toma, por ejemplo, el intercambio de claves asimétricas, un problema tentador que atormentó a las mentes matemáticas más grandes durante décadas, si no siglos. Alice y Bob pueden comunicarse usando una clave de cifrado irrompible, pero si no saben que Eve la ha interceptado, todo está al descubierto. Si solo pudiéramos tener un par de claves, de modo que puedas cifrar un mensaje con la clave A pero solo puedes descifrarlo con la clave B y no hay una forma práctica de deducir una clave a partir de la otra. Si luego entregas una parte de la clave a todos y proteges la otra parte de tu vida, has resuelto el intercambio de claves.
Es lo suficientemente simple declarar hacia dónde quieres llegar, pero apenas es una especificación desde la cual comenzar a codificar. Ni siquiera es una tarea de programación. Es la búsqueda de inventar un algoritmo que puede que ni siquiera sea posible. En el Scrum Poker, sacarías la carta del infinito. Los algoritmos que Whitfield Diffie y Martin Hellman finalmente idearon caben en la proverbial servilleta. Sería trivial traducirlo a código en comparación. Pero nunca podrían haber llegado a la solución de forma incremental detrás de un teclado. O lee la fascinante historia de cómo se descifró el cifrado Enigma por el equipo de Bletchley Park. Una tarea aún más desalentadora porque literalmente había una guerra que ganar.
No puedes crear una obra maestra por encargo, ni en el arte ni en la ciencia. Si supiéramos qué hace una buena canción, podríamos replicar el proceso, si no usando software, al menos mediante algún método formulado. Pero eso no produce clásicos. La creatividad es un proceso de aciertos y errores, y pocos artistas producen consistentemente obras de genio. No hay razón para esperar grandes avances de IA en ese departamento. Pero podemos esperar mejores herramientas para estimular la creatividad. Los compositores utilizan un diccionario de rimas y un tesauro en busca de inspiración. Eso no es hacer trampa.
Afortunadamente, a menos que estés trabajando en una universidad o instituto de investigación, el desarrollo y mantenimiento de software empresarial no consiste en resolver acertijos matemáticos centenarios. Sin embargo, deberías reflexionar más profundamente sobre lo que queremos y necesitamos, en lugar de aprender un nuevo y genial marco de trabajo o obtener otro certificado de AWS. Descubrir la complejidad esencial no es solo trabajo de los analistas de negocios en la organización. No puedo esperar a que las herramientas de próxima generación nos ayuden a lidiar con ello, porque eso sería un copiloto genuino en lugar de un piloto automático.
