Turing test para herramientas generadoras de código

El otro día vi este trabajito para programadores freelance . El trabajo consistía en generar MySQL DDL scripts para un conjunto de diagramas de clase UML por alrededor de 55$ (oferta media).

En seguida pensé que esto seria un trabajo fácil para todos aquellos programadores con acceso a una herramienta de generación de código apropiada para este escenario (como mi servicio UMLtoDB 🙂 )

La pregunta sería entonces, si esta solución sería aceptable por parte del “cliente”. Imagina que tu eres ese cliente, confiarías suficientemente en la herramienta como para aceptar directamente el código que la herramienta ha generado? Te sentirías estafado (por aquello de qué “el freelance ha apretado sólo un botón”)? Crees que la calidad conseguida por las herramientas de generación de código puede estar al mismo nivel que la de los programadores profesionales? Como mínimo para este escenario? (UML->DB)?

Para solucionar estos posibles conflictos, me gustaría proponer un turing test para herramientas generadoras de código . Las herramientas que pasen el test habrán demostrado que la calidad del código que generan es comparable a la de los humanos y que, por lo tanto, podrían usarse en su lugar. De forma similar al turing test clásico para IA , el turing test para herramientas de generación de código es como sigue:

Un juez humano examina el código generado por un programador y por una herramienta generadora de código a partir de la misma especificación formal. Si el juez no puede determinar con certeza quién ha hecho qué, la herramienta pasa el test.

Sé que mi definición no es muy precisa pero creo que haremos un gran salto adelante en la adopción de herramientas MDD el día en qué las herramientas pasen este test. Esto, de hecho, no quiere decir que las herramientas generen código de muy buena calidad sino simplemente que generan código de forma parecida a como lo hacen los programadores profesionales. Tengo la sensación que la adopción de MDD a veces depende de factores más psicológicos (como el hecho de que el código generado parezca “familiar”) que no puramente de calidad

Si te ha gustado esta entrada, puedes subscribirte a este Software Modeling blog y/o seguirme en twitter y/o a través de la lista de distribución del portal Y si realmente te ha gustado ayúdame a hacerlo llegar a otros utilizando los bookmarks que tienes a continuación: