Con AI como Deep Coder ahora usando fragmentos de código para escribir programas, ¿cuánto tiempo hasta que la inteligencia artificial supere los trabajos de codificación de entrada?

Si lee el artículo en sí, descubrirá que los artículos vinculados son muy sensacionalistas y algo imprecisos.

Primero, la “IA” solo opera en un dominio estrecho muy específico de listas de números y aritmética simple. Específicamente, solo puede “escribir” programas que toman una entrada de un número, lista de números, lista de números y listas de números, etc., y producen resultados en el mismo formato.

Crea programas no en un lenguaje de propósito general, sino en un DSL creado por los investigadores específicamente para este dominio. Este DSL no es completo de Turing, por lo que incluso dentro de ese dominio, solo es posible resolver en él un subconjunto de todos los problemas “computables” (es decir, los que se pueden resolver utilizando un lenguaje de propósito general).

La “IA” en cuestión no puede leer de ninguna manera las especificaciones, solo usa entradas y salidas de ejemplo para inferir lo que se supone que debe hacer el programa.

Realmente no “reutiliza el código”, ya que obviamente no hay ningún código preexistente “acostado” que esté escrito en el DSL que los investigadores inventaron para el propósito de este estudio, la “mentira “bit” es millones de programas generados de manera más o menos aleatoria como parte del proyecto de investigación, que son utilizados por el sistema de aprendizaje automático como un conjunto de capacitación.

El resultado final es que la IA puede “resolver problemas de dificultad comparables a los problemas más simples en sitios web de competencia de programación”, en ese dominio específico. Posiblemente eso sea impresionante dado el estado de la investigación en esa área en particular (no sigo el campo, por lo que no tengo opinión), pero no es terriblemente impresionante en comparación con lo que se podría esperar que haga incluso un programador de nivel de entrada.

Más importante aún, tiene muy poco que ver con el desarrollo del software comercial de la vida real, que es comprender y modelar dominios (comerciales y técnicos), y mapear estos modelos con características idiomáticas de la pila de tecnología seleccionada (modismos de lenguaje de programación, entidades de bases de datos) , protocolos, formatos de datos, etc.) Esta investigación de ninguna manera aborda estos problemas, pero estas son las partes que serían potencialmente difíciles de automatizar. Las partes que se pueden automatizar, como han notado otros respondedores, se están automatizando todo el tiempo a partir de la década de 1950. Escribir el tipo y la cantidad de software que se está escribiendo hoy usando técnicas de ingeniería de software de antaño (tarjetas perforadas, lenguaje ensamblador, material de elaboración manual manejado hoy por bibliotecas y marcos), habría llevado un esfuerzo desmesurado. Sin embargo, al menos hasta ahora, la respuesta a este aumento en la productividad no ha sido menos trabajo para los programadores, sino que se ha creado más (mucho más) software.

En primer lugar, la mayoría de las personas crean programas con código que encuentran por ahí. Eso es básicamente lo que son las bibliotecas y todos usan una pila de ellas para cada proyecto. Las bibliotecas y los marcos “automatizaron” una gran cantidad de codificación de nivel básico hace un tiempo. Incluso lenguajes como Java y Python son una forma de “automatización”.

En segundo lugar, la parte difícil de la programación rara vez es la codificación real real. Es determinar cuáles son realmente los requisitos del proyecto y qué quiere y necesita realmente el cliente.

Tercero, este programa solo funciona en incrementos de 5 líneas. Eso es como un bucle for.

A continuación, vaya al artículo vinculado y encontrará la cita:

“Podría permitir a los no codificadores simplemente describir una idea para un programa y dejar que el sistema lo construya”

Por lo general, no describen sus ideas en un lenguaje que un humano pueda entender. Mucha gente me presenta ideas de aplicaciones y web y no estoy realmente seguro de lo que están tratando de decir, ya que ellos mismos no tienen más que un simple concepto. Ni siquiera han imaginado una interfaz de usuario. Si Deep Coder puede tomar una idea mal formada y escupir una aplicación, también podrá reemplazar todo, desde el médico hasta el abogado.

No por un tiempo todavía. La parte difícil de la codificación es desarrollar la especificación. Una vez que sepa exactamente qué debe hacer el programa, el resto es trabajo de pala. Antes de poder construir un programa con IA, necesita un arnés de prueba que cuantifique qué tan cerca de una solución tiene la IA. Eso en sí mismo es una tarea no trivial. Necesita el arnés de prueba para detectar cada posible error en el programa. Todos ellos. No solo los que podrían no ser completamente obvios para un probador humano a primera vista. E incluso los que solo ocurren a las tres en punto de un viernes cuando hay una R en el mes y el programa ha estado funcionando durante al menos tres semanas. Eso es relativamente fácil si está produciendo un algoritmo como el cálculo de correcciones de curso de naves espaciales. Pero imagine hacerlo para un programa como Word.

Porque lo único que no puede hacer fácilmente con el código producido por AI es hacer que un humano lo depure. Incluso si la IA escribe la documentación completa, la depuración de un humano requerirá al menos el doble de tiempo que si la escribieran ellos mismos.

Y el software gasta órdenes de magnitud más tiempo de mantenimiento que de escritura, incluso si está libre de errores. Si la máquina no puede mantener su propio código, es mejor que no se moleste.

Entonces, en lugar de trabajar en la escritura del código, pronto podremos trabajar en la escritura de especificaciones de prueba; Tendremos que decirle a la computadora qué debe producir en lugar de cómo debe producirla. Por supuesto, esa es la definición de un lenguaje declarativo, y los tenemos ahora.

Plus ça change, plus c’est la même eligió.

Si bien es una pequeña demostración genial, no va a robar trabajos en el corto plazo. Según el artículo, parece que el programa estaba compuesto de código recortado y reutilizado. No puede construir proyectos a gran escala a partir de código reutilizado.