Programando con IA, mi experiencia

A lo largo de mi vida he tenido la fortuna de hacer lo que mas me apasiona en la vida, programar, desde aquellos lejanos tiempos de programar en basic para PET commodoro , pasando por Mainframe IBM en sistemas 36 y 43, haciendo uso de micro procesadores con lenguajes tan vario pintos como assembler, python, c, c++, gw basic, cobol, RPG, PL1 pascal , foxpro, harbour, ruby, java, solidity, entre otros, en todos encontré cosas geniales , buenas y también malas, pero la esencia nunca cambio, para cualquier maquina o modelo de desarrollo (MVC, DAO, secuencial, paralelo, multi-hilo, eventos etc) y lenguaje hay que tener claro lo que uno quiere hacer, el lenguaje viene por añadidura, ya que como dicen cada cosa en su lugar y un lugar para cada cosa, es decir no existen tanta variedad de lenguajes y tecnologías porque alguien que no tenia nada que hacer se puso creativo, la realidad es que cada propuesta tecnológica tiene un fin , o trata por lo menos de resolver un problema puntual, por eso pienso que tener una mente abierta a los nuevo sin olvidar lo viejo es una media saludable.

Con el advenimiento de la inteligencia artificial, para mi es como afrontar el reto de otra tecnología, con sus propuestas buenas y malas como todo en la vida.

Dado su auge , es menester afrontar el reto de aprender a usarla para mis propósitos específicos, y puestos a la obra, toca explorar , desde luego lo convencional open IA, Gemeni, Cloud y desde luego Qwen 2.0 ,Minimax 1, Kimi 1.5 Deep seek y los diferentes sabores de copilot y afines todos ofrecen diferentes aristas desde el punto de vista de su uso, en lo que me compete como es la programación , unos generan mejores prompt, otros ayudan a crear mejores diseños gráficos , estructurales o funcionales, abordan diferentes lenguajes de una forma u otra alguno muy bien otros no tanto, crear micro servicio y probar programas, eso ya de por si es un gran plus , porque en verdad lo es.

Pero como como digo todo tiene su luz y sombras, usar IA para programar no es ninguna pera en dulce o no para mi por lo menos.

En este trasegar por todas estas herramientas, me convenzo cada vez mas que detrás de un proyecto con IA o cualquier otra herramienta, por lo menos hasta donde se actualmente, se necesita una mente maestra humana que diseñe, controle , cree pruebas en resumen que sea el arquitecto del proyecto así el mismo cuente con muchos recursos humanos y tecnológicos, dejar la responsabilidad del control y vigilancia de cada paso puede llevarnos al desastre total, y al final decir que la IA no sirve, craso error.

La IA como cualquier tecnología esta al servicio de quien la use, no al revés, en muchos casos, no pocos he visto personas, empresas incluso abrazar esta tecnología como si fuera una panacea que todo lo puede y todo lo resuelve, no hay tal, es una inmensa ayuda si, pero es solo una herramienta muy buena pero limitada a la capacidad de quien y como la use.

En general he visto y lo digo con respeto, ni mas faltaba con los programadores , pero algunos y no pocos he visto, que quieren hacer el análogo de una persona que maneja una moto pasar a manejar un formula 1, lo casi inevitablemente es un choque.

En lo que me ha tocado de forma puntal he visto como dije que uno puede usar la IA, para que te ayude a generar o dar luces de como debería verse un proyecto, y hacer variaciones y manejo de conceptos de una forma ágil y rápida , ahí está que ni pintada, en algunos casos para generar modelos de front-end , es todo un descreste sin lugar a dudas, desarrollar módulos de pruebas o propuestas funcionales es excelente.

Pero como he dicho todo tiene luces y sombreas, y la sombra mas larga que la programación tiene con IA es precisamente lo que la hace interesante, su modelo creativo llamado no predictivo (mas o menos es como decir que nunca se sabe que va hacer), que como algunos ya habrán notado es materialmente imposible que bajo un mismo prompt, partimos que esta super bien elaborado , el resultado sea el mismo, a veces ni se acerca, aunque el resultado sea el mismo.

Entonces si el resultado es el mismo, cual es el problema, al final pensaran algunos, el resultado es el que cuenta o no?

Pues depende, si estas haciendo un programa para tu uso personal, todo bien, todo bien como decía el PIBE, pero si es para un cliente o una propuesta corporativa, ahí la cosa cambia, porque tomemos un ejemplo sencillo , un prompt que elabora un diseño un front-end, y resulta que deseas cambiar un color de fondo negro a uno con azul oscuro, nada mas, pues ya estas en serios problemas, porque es seguro que al ver el front end, con el cambio propuesto tal y como quieres, al revisar el código te darás cuenta que el que el mismo es totalmente diferente al inicial, o por lo menos con cambios de lo mas exóticos, entonces tienes 2 opciones, o te resignas al nuevo código, o te adentras en el código inicial y por tu cuenta le cambias el color que quieras, y puedo decirte, suerte con eso, porque el programa generado no esa hecho para ser mantenido por cualquier programador, y el problema se pone se pone mas peliagudo si deseas compartir ese código para ser usado o mantenido por un staff tecnológico.

El uso de variables esotéricas, rutinas y tecnologías de punta de las que es casi seguro ni tenias idea que existía, no son la excepciones sino la reglas.

Es entonces donde el programador antes de lanzar un prompt se tiene que cerciorar de tener en cuenta todas y cada una de implicaciones de su desarrollo para poder tener un cierto control sobre lo que la IA va a crear.

Ahora esta de moda la ingeniería de prompt, interesante propuesta, pero yo sigo pensando que si uno no sabe para donde va, va a llega a cualquier parte, con o sin ingeniería de prompt.

Por eso es primordial crear un escenario de desarrollo lo mas claro posible, y darle a la IA, las cosas muy, muy claras en tecnología a usar, forma de definir las funciones y variables, alcances y profundidad es decir todo lo que garantice en cierta medida que se tenga un control mediano sobre lo que la IA , pude proponer.

Y casi con seguridad vas a quedar a un 70 u 80% del resultado final, lo cual no es poca cosa sobre todo en el tiempo en que esto se consigue, eso si, es un avance , si lo generado esta bajo control y sabes exactamente lo que hizo y como lo hizo, sino, bueno has perdido mucho tiempo y esfuerzo.

En mi caso especifico, en el desarrollo de módulos corporativos , en lugar de lanzar requerimientos genéricos, he optado en hacer módulos funcionales totalmente controlados en todos los aspectos y perfectamente documentados, los cuales puedo usar con o sin IA , como piezas de un montaje, me ha costado lo confieso, y me ha sacado la piedra incontables veces, pero ya tengo digamos un set de módulos que responden mas o menos bien y a los cuales puedo meterle mano sin temor a que se me haga un daño de la madona

Un ejemplo de un inicio de un prompt mio luce algo como lo siguiente:

Prompt para la Generación del Sistema de Gestión de información Generico CRUD para administrar diferentes entidades.

A continuación se presenta un prompt detallado para generar el código HTML, CSS y JavaScript (Vanilla JS) de un sistema de gestión con funcionalidades CRUD completas.

Este sistema está diseñado para ser responsive y uso de la api Rest ful apiHandler().

En todo el diseño gráfico mantener hasta donde sea posible las recomendaciones pwa, WCAG 2.2 (nivel AA)en fonts , colores, separaciones, contrastes , etc. para poder desplegar en diferentes dispositivos , computadores personales, tables, celulares y pueda ser usado por el adulto mayor.

Tecnologías:

• HTML5
• CSS3
• JavaScript Vanilla
• Bootstrap 5.3 (CDN)
• Font Awesome 6.5.2 (CDN)

Genera un CRUD con esta estructura específica:

- domElements.js: SOLO referencias a elementos DOM, sin lógica

- form.js              : SOLO manejo de eventos de formulario y manipulación de campos

- schemas.js        : SOLO definición de estructura de datos, sin validación

- validator.js : SOLO validación usando schemas.js

• Arquitectura Modular

/[ENTIDAD]/
├── [index.html         #  genrico
├── js/
│   ├── api.js          # Simulación de API       (generico)
│   ├── domElements.js  # Referencias DOM         (generico)  
│   ├── form.js         # Manejo de formularios   (generico)
│   ├── main.js         # Punto de entrada        (generico)
│   ├── utils.js        # Funciones utilitarias   (generico)
│   ├── validator.js    # Validación de campos    (generico)
│   └── data.js         # Datos de ejemplo        (generico)
└── css/
    └── styles.css      # Estilos personalizados  (generico)
└── schemas/schemas.json                          (especifico)

En este caso [Entidad] , podría ser Proveedores,Vendedores, Materiales, Clientes, Categorías,Terceros o cualquier cosa que se me ocurra que responda al diseño CRUD (Create,Read,Update,Delete) o sea crear, leer, editar, borrar, tan de moda actualmente. Desde luego mas completo de hecho el solo prompt es lo mas especifico posible y ocupa 23 paginas de lineas de comando, directrices, nombres de variables contextuales , definición de campos etc, el resultado de esté desarrollo es un CRUD, que puedo usar cambiando únicamente el schemas , que contiene los parámetros del proceso y mantiene una estructura siempre igual y sin sorpresa. El schemas.js que es el único especifico como se ve en la estructura, (es un archivo json con definición precisa de los campos y su uso en el CRUD) se ve así y basta cambiar ese archivo, para generar un prompt ajustado a casi cualquier necesidad en un backend, o sea no depende del programa sino de la estructrura del schema y siempre responde igual.

Los diferentes enfoques y propuestas que la IA me ofreció fueron bastante especiales , pero al final cada decisión la tome yo.


schemas.js
*********

import { CONFIG } from './config.js';

// Definición de la estructura de datos para la entidad Usuario

export const ENTITY_CONFIG = {
entityName              : 'usuario',
entityNamePlural    : 'usuarios',
displayName           : 'Usuario',
displayNamePlural : 'Usuarios',
icon                         : 'fas fa-users',
primaryKey             : 'id',

// Operaciones de API

apiOperations: {

create           : '[Usuarios]Crear',

read             : '[Usuarios]Consultar',

readById     : '[Usuarios]ConsultarID',

update         : '[Usuarios]Editar',

delete          : '[Usuarios]Borrar',

changeState: '[Usuarios]CambiarEstado'

},

// Schema de la entidad

schema: [
{

name: 'id',

label: 'ID',

type: 'hidden',

required: 'unico',

placeholder: 'ID único del usuario',

tooltip: 'Ingrese Identificador único del usuario',

          validation: null

},

{

name: 'usuarioEstado',

label: 'Estado',

type: 'select',

required: 'opcional',

options: {

'Activo' : 'activo',

'Inactivo': 'inactivo'

},

placeholder: 'Estado del usuario',

tooltip: 'Seleccione Estado del usuario',

validation: '(field === null || field === undefined || field.trim() === \'\')'

},

No pretendo aquí que la gente use este modelo, lo que digo es que esta esta forma de usar la IA, me está dando muchas satisfacciones, lo digo que si se tienen modelos claros, precisos , y bien elaborados , con prompt claros y bien diseñados , los resultados de la IA, pueden ser geniales, pero insisto de la mano de un arquitecto (programador) con los pies en la tierra.