En la conferencia Build de Microsoft, el CTO de Microsoft, Kevin Scott, habló sobre un proyecto experimental en el que una IA, capacitada en código en GitHub, en realidad crea programas: genera contenido de función basado en un comentario descriptivo y firma. (Ir a 29:00 desde el video.) Un trabajo de investigación no relacionado informa a lo largo de la misma línea traducción desatendida de programas de un idioma a otro; de hecho, probablemente sea una tarea más simple que la traducción al lenguaje natural.

La demostración de Microsoft es, bueno, una demostración, y el trabajo de investigación es un trabajo de investigación. La IA de Microsoft pudo proporcionar cuerpos de métodos para algunas funciones relativamente simples; fue claramente bastante limitado. Se plantea la pregunta de exactamente cómo escribir el comentario diciéndole a la IA qué hacer; ¿Estamos simplemente reemplazando una descripción en un lenguaje de programación preciso con una descripción en un lenguaje humano ambiguo e inexacto? Estoy seguro de que entrenar el modelo cuesta más que contratar a un desarrollador para que escriba algunas funciones cortas. Y aunque puedo creer fácilmente que el software puede traducir un código simple de COBOL a Rust, solo puedo imaginar que estaría terriblemente confundido por la multitud de trucos que los programadores utilizaron para interactuar con las computadoras en los años sesenta y setenta. esos estándares modernos, pequeños recuerdos. Los comandos de programación no desaparecerán mañana.

Aprende más rápido. Excavar más hondo. Ver más

Sin embargo, es importante para nosotros pensar qué puede significar la automatización para el futuro de la programación. ¿Es esta una visión del futuro, y si es así, qué nos dice? qué podemos aprender de eso? La programación está cada vez más automatizada; y como alguien que comenzó a escribir ensamblador en un PDP-8, puedo decirle que la programación ya está altamente automatizada, y un buen compilador de optimización ya es un sistema avanzado de inteligencia artificial que registrará sus sugerencias y las colocará cambios en el código de trabajo

La programación no va a «desaparecer» ni a «quedar desactualizada». Sin embargo, el significado cambiará. Anteriormente he escrito sobre trabajadores de cuello azul y trabajadores de cuello blanco: programadores que conectan cosas y programadores que diseñan cosas que están conectadasy construir las herramientas para conectarlos. Estas son habilidades diferentes (aunque muy superpuestas). Y aunque la demostración de Microsoft puede demostrar que los programadores pueden finalmente liberarse de la tarea de codificar funciones simples, el motor generador de código ciertamente fue construido por un equipo de programadores, y posiblemente uno grande. Los programadores que escriben herramientas de nivel superior, como el propio motor de codificación de Microsoft, pueden dar un suspiro de alivio. Al igual que los programadores que diseñan API porque aún tiene que proporcionar las firmas de función / método.

¿Y los programadores de trabajadores que conectan las cosas? Aunque esta demostración podría escupir características, vi pocas señales de que podría construir sistemas más grandes a partir de las características que escribió. Aunque tenía la capacidad de invocar funciones que había escrito, no podía compilar un programa grande a partir de una especificación escrita. Puede escupir una factura simple, pero ciertamente no puede escupir un sistema de facturación completo. ¿Un proyecto para futuras investigaciones? Indudablemente, pero probablemente fue hace décadas. Los programadores que conectan las cosas, los plomeros del mundo digital, también están seguros.

Pero este logro aún plantea la cuestión de qué queremos decir con programación. En el video, Kevin Scott habla sobre cómo reducir el tiempo que los programadores dedican a tareas aburridas y repetitivas. Sí, eso es lo que todos decimos sobre IA: reducirá el tiempo dedicado a tareas aburridas y repetitivas y liberará más tiempo para el trabajo creativo. Sin embargo, analicemos eso. La mayor parte de la programación especifica, en un detalle insoportable, cómo se debe realizar un proceso en particular. Eso puede ser aburrido, a menudo es repetitivo y ciertamente es propenso a errores. Y realmente necesitamos pensar más sobre qué programación debería ser – estar. ¿Cuáles son, para usar la palabra de Scott, los aspectos «creativos» de la programación?

No estoy seguro de si «creativo» es la palabra correcta. En los años sesenta y setenta, se hizo referencia a más programadores como «analistas». Ese título de trabajo todavía se usa, pero no es tan común: Puerta de vidrio muestra aproximadamente 10,000 trabajos para «analista programador», 44,000 para «programador» y 100,000 para «ingeniero de software». Muestra muestra aproximadamente 20,000 para «analista programador», 300,000 para «programador» y 170,000 para «ingeniero de software».

Si bien el trabajo puede haber sido un poco diferente de lo que es hoy, veamos qué significa «analista». Los analistas analizan un problema; piensan sobre cuál es el problema y cómo resolverlo de manera efectiva. Están pensando en dividirlo en partes. Incluso pueden considerar si debe resolverse; pueden pensar en cómo resolverlo, qué problemas éticos plantea y cómo abordar esos problemas. ¿Se puede usar mal el software? ¿Si es así, cómo? ¿Qué pasos se pueden tomar para prevenir el abuso? Y los analistas tienen que pensar en cómo las personas usarán el software: ¿cuál es la interfaz de usuario, cuál es la experiencia del usuario, puede ser utilizada por personas con discapacidades?

En O’Reilly’s Fundamentos de arquitectura de software Superstream, Rebecca Parsons de Thoughtworks dijo que los «analistas» esencialmente hicieron arquitectura de software: tomar grandes decisiones sobre lo que el software debe hacer y cómo debe construirse. Los analistas y arquitectos necesitan entender el caso de negocios. Tienen que presentar las decisiones sobre los sistemas de software a la administración de una manera comercial. Ella utilizó la necesidad de probar una estrategia de respaldo como ejemplo: en lugar de decirle al CEO sobre los detalles técnicos, simplemente diga: «Esta prueba nos mostrará cuánto tiempo llevará volver a estar en línea si el sistema falla en el día de compras más concurrido del año «. Eso es lo que hace un analista.

Nuestro énfasis en escribir código y medir la productividad a través de «líneas de código» es miope. Solo mire todas las herramientas maravillosas (y absolutamente necesarias) que tenemos para construir, probar, archivar e implementar código. Pero esas herramientas, esenciales y revolucionarias como son, no abordan el problema real: ¿resolvemos los problemas correctos? Hay miles de aplicaciones que pasan cada prueba unitaria, cada prueba de integración y cada prueba de aceptación, pero aún son horribles de usar. Y aprendemos que hay nuevas dimensiones de software en las que rara vez hemos pensado: ¿hay grupos que necesitan usar nuestro software y no pueden? ¿Su software admite accesibilidad? ¿Puede ser utilizado por personas que no tienen acceso confiable a computadoras y redes? El trabajo de una organización como Código para América No es técnicamente profundo o profundo. ¿Qué tiene de radical un producto como GetCalFresh fue el acto de rediseñar el sistema para que sea utilizable por las personas que lo necesitan. Y necesitamos mucho más de ese tipo de análisis.

La programación es mucho más que solo código de péndulo y funciones de escritura. Las partes principales del trabajo no tienen nada que ver con escribir un resumen rápido en la pizarra en una entrevista. Hay mucho en que pensar; y actualmente, los programadores pasan demasiado tiempo apresurando el código para obtener una fecha de lanzamiento de lo que pasan pensando en el panorama general. Ese es casi siempre el trabajo de otra persona. Pero ya sea que entre en producción o no, la investigación de Microsoft nos da la oportunidad de pensar en lo que realmente significa la programación. ¿Cuál es el trabajo real? ¿Qué estamos realmente tratando de lograr?





Source link