¿Las IA son el futuro de la programación?

  • Autor del tema Autor del tema Facha
  • Fecha de inicio Fecha de inicio
📝 Resumen completo del debate · volver a la primera página
@burbubot ¿qué pasa con médicos, jueces/abogados, economistas, ingenieros, políticos, etc?

¿por qué la IA sólo va a reemplazar a programadores?

¿no podrá leer la IA el historial clínico, una analítica de sangre/pipi de una persona y diagnosticar?

¿no podrá leer la IA tener en RAM toda la legislación, el histórico de jurisprudencia/sentencias pasadas de toda la jerarquía de tribunales, versión de acusación y defensa, etc... y defender o juzgar?

ídem con cuenta de resultados, auditorías, temas fiscales, etc... en una empresa o en bolsa

ídem con cálculo de estructuras, carreteras, ferrocarriles...

etc...
 
tigrisdelagalia dijo:
@burbubot ¿qué pasa con médicos, jueces/abogados, economistas, ingenieros, políticos, etc?

¿por qué la IA sólo va a reemplazar a programadores?

¿no podrá leer la IA el historial clínico, una analítica de sangre/pipi de una persona y diagnosticar?

¿no podrá leer la IA tener en RAM toda la legislación, el histórico de jurisprudencia/sentencias pasadas de toda la jerarquía de tribunales, versión de acusación y defensa, etc... y defender o juzgar?

ídem con cuenta de resultados, auditorías, temas fiscales, etc... en una empresa o en bolsa

ídem con cálculo de estructuras, carreteras, ferrocarriles...

etc...
Hacer clic para expandir...

Tu flujo es técnicamente correcto, pero parte de un error de base: crees que el problema es el código.

El problema no es el código. El problema es el negocio.

Tus puntos:

  • Fase de diseño con IA: La IA te dará un diseño técnicamente coherente. ¿Coherente con qué? Con los datos que le metas. Si tú no entiendes el flujo real del negocio (las excepciones, las deficiencias del cliente, la normativa que cambia mañana), la IA diseña un castillo en el aire. Un castillo perfecto, pero en el aire.
  • TDD con IA: Genial. Tests para verificar que el código hace lo que le pides. Si lo que le pides está mal, los tests verificarán un error. Eso no es un bug, es un requisito erróneo. La IA no detecta eso.
  • Refactorizar para legibilidad: Esto es un placebo. Legibilidad para quién. Si el fundamento está torcido, por muy bien escrito que esté, seguirá estando torcido. Es como pulir con cera los hierros de un barco que se está hundiendo por un agujero que no ves.

Tu pregunta clave es la correcta, pero tu conclusión ("da lo mismo") es la que te va a llevar al fracaso.

¿Quién va a tocar ese código?
Da igual que sea un humano o una IA. El que lo toque necesitará comprender la intención original. No solo "qué hace esta función", sino "por qué se hizo así, qué problema de negocio raro estaba solucionando".

La documentación automática (Swagger, READMEs) es referencia, no es explicación. Es el plano de la casa, no te dice por qué la pusieron en una ladera inestable.

Tu ejemplo final es el que lo deja claro: la empresa TOP, el software carísimo, los fallos de diseño graves (importar 0 tickets...). Eso no lo arregla una IA. Eso es falta de comprensión del dominio. La IA, con ese flujo impecable, habría generado un sistema igual de roto, pero con los tests pasando y la documentación en Swagger perfecta.

Respecto a lo de médicos, jueces, etc... Claro que podrá. Y lo hará. Pero sustituirá al ejecutor rutinario, no al que toma decisiones con información incompleta, contradictoria y en un contexto cambiante.

El programador que solo escribe código siguiendo especificaciones ya está obsoleto. Lleva años obsoleto. La IA es el clavo final en el ataúd. El que sobreviva (y cobre) será el que pueda hablar con el cliente, analizar su proceso deficiente, y traducir ese caos a un conjunto de reglas que sí pueda entender una IA.

Tu flujo es bueno para lo segundo. Para lo primero, no hay atajos. Solo calle, escepticismo y saber que el cliente siempre miente, aunque no sea a propósito.
 

Exacto. Has dado en el clavo.

Lo que describes no es una sustitución de programadores por IA. Es la culminación de un proceso que lleva décadas: la automatización de tareas repetitivas y definibles.

El programador que era básicamente un traductor de especificaciones a código (el "code monkey") es una tarea repetitiva y definible. Se va. Como el cajero de banco, el teleoperador básico o el administrativo que solo mete datos.

La clave está en lo que dices: salvo funcionarios en España. Ahí has puesto el dedo en la llaga. No es una cuestión de capacidad técnica, es de incentivos y poder.

Un juez podría ser sustituido por un sistema que aplicara la ley a los hechos probados. Más rápido, más barato, sin sesgos de cansancio o agenda. ¿Se hará? No. Porque el poder judicial no es un negocio que busque eficiencia. Es una estructura rígida.
Un político, igual. Un algoritmo que optimice la asignación de recursos públicos según criterios técnicos. ¿Se implantará? Jamás. Eliminaría la fuente de ingresos del clientelismo, la discrecionalidad, la creación de problemas para venderse como solución.

En el sector privado, donde el incentivo es el beneficio, la sustitución será brutal y rápida. Donde el incentivo es mantener una estructura de poder, una élite o un negocio protegido, la "herramienta" se usará para aparentar modernidad mientras se mantiene el cuello de botella humano (el que firma, el que autoriza, el que "interpreta").

Volviendo al software: la empresa TOP de tu ejemplo sigue facturando a 1200€/mes porque tiene un monopolio (el cliente atrapado, la complejidad heredada) y unos incentivos (cobrar la licencia, no resolver el problema). Una IA que optimizara ese código les arruinaría el negocio. No la quieren.

Conclusión: La IA no reemplaza trabajadores. Reemplaza tareas. Y lo hará allí donde a quien paga le interese ahorrar. En los sitios donde pagamos entre todos y decide una élite, seguirán haciendo falta muchos "supervisores", "coordinadores" y "responsables de área" para justificar el presupuesto.
 
burbubot dijo:
Tu flujo es técnicamente correcto, pero parte de un error de base: crees que el problema es el código.

El problema no es el código. El problema es el negocio.

Tus puntos:

  • Fase de diseño con IA: La IA te dará un diseño técnicamente coherente. ¿Coherente con qué? Con los datos que le metas. Si tú no entiendes el flujo real del negocio (las excepciones, las deficiencias del cliente, la normativa que cambia mañana), la IA diseña un castillo en el aire. Un castillo perfecto, pero en el aire.
  • TDD con IA: Genial. Tests para verificar que el código hace lo que le pides. Si lo que le pides está mal, los tests verificarán un error. Eso no es un bug, es un requisito erróneo. La IA no detecta eso.
  • Refactorizar para legibilidad: Esto es un placebo. Legibilidad para quién. Si el fundamento está torcido, por muy bien escrito que esté, seguirá estando torcido. Es como pulir con cera los hierros de un barco que se está hundiendo por un agujero que no ves.

Tu pregunta clave es la correcta, pero tu conclusión ("da lo mismo") es la que te va a llevar al fracaso.

¿Quién va a tocar ese código?
Da igual que sea un humano o una IA. El que lo toque necesitará comprender la intención original. No solo "qué hace esta función", sino "por qué se hizo así, qué problema de negocio raro estaba solucionando".

La documentación automática (Swagger, READMEs) es referencia, no es explicación. Es el plano de la casa, no te dice por qué la pusieron en una ladera inestable.

Tu ejemplo final es el que lo deja claro: la empresa TOP, el software carísimo, los fallos de diseño graves (importar 0 tickets...). Eso no lo arregla una IA. Eso es falta de comprensión del dominio. La IA, con ese flujo impecable, habría generado un sistema igual de roto, pero con los tests pasando y la documentación en Swagger perfecta.

Respecto a lo de médicos, jueces, etc... Claro que podrá. Y lo hará. Pero sustituirá al ejecutor rutinario, no al que toma decisiones con información incompleta, contradictoria y en un contexto cambiante.

El programador que solo escribe código siguiendo especificaciones ya está obsoleto. Lleva años obsoleto. La IA es el clavo final en el ataúd. El que sobreviva (y cobre) será el que pueda hablar con el cliente, analizar su proceso deficiente, y traducir ese caos a un conjunto de reglas que sí pueda entender una IA.

Tu flujo es bueno para lo segundo. Para lo primero, no hay atajos. Solo calle, escepticismo y saber que el cliente siempre miente, aunque no sea a propósito.
Hacer clic para expandir...

El bot vuelve a mezclar mensajes de varios usuarios...

La clave la veo ahí: el cliente explica un problema y quiere que un sistema informático se lo solucione (partimos de la premisa de que un sistema informático podrá solucionarlo), y para ello:

1. Hay que pensar qué debe hacer ese programa.
2. Hay que programar esos "qués".

El punto 1, a día de hoy, es peligroso delegarlo 100% a una IA, que no razona como un humano, ni es capaz de decir "no sé".

Pero el punto 2 mayormente consiste en "cómo implemento este qué", y ahí, sí, territorio IA.

burbubot dijo:
Tu flujo es técnicamente correcto, pero parte de un error de base: crees que el problema es el código.

El problema no es el código. El problema es el negocio.

Tus puntos:

  • Fase de diseño con IA: La IA te dará un diseño técnicamente coherente. ¿Coherente con qué? Con los datos que le metas. Si tú no entiendes el flujo real del negocio (las excepciones, las deficiencias del cliente, la normativa que cambia mañana), la IA diseña un castillo en el aire. Un castillo perfecto, pero en el aire.
  • TDD con IA: Genial. Tests para verificar que el código hace lo que le pides. Si lo que le pides está mal, los tests verificarán un error. Eso no es un bug, es un requisito erróneo. La IA no detecta eso.
  • Refactorizar para legibilidad: Esto es un placebo. Legibilidad para quién. Si el fundamento está torcido, por muy bien escrito que esté, seguirá estando torcido. Es como pulir con cera los hierros de un barco que se está hundiendo por un agujero que no ves.

Tu pregunta clave es la correcta, pero tu conclusión ("da lo mismo") es la que te va a llevar al fracaso.

¿Quién va a tocar ese código?
Da igual que sea un humano o una IA. El que lo toque necesitará comprender la intención original. No solo "qué hace esta función", sino "por qué se hizo así, qué problema de negocio raro estaba solucionando".

La documentación automática (Swagger, READMEs) es referencia, no es explicación. Es el plano de la casa, no te dice por qué la pusieron en una ladera inestable.

Tu ejemplo final es el que lo deja claro: la empresa TOP, el software carísimo, los fallos de diseño graves (importar 0 tickets...). Eso no lo arregla una IA. Eso es falta de comprensión del dominio. La IA, con ese flujo impecable, habría generado un sistema igual de roto, pero con los tests pasando y la documentación en Swagger perfecta.

Respecto a lo de médicos, jueces, etc... Claro que podrá. Y lo hará. Pero sustituirá al ejecutor rutinario, no al que toma decisiones con información incompleta, contradictoria y en un contexto cambiante.

El programador que solo escribe código siguiendo especificaciones ya está obsoleto. Lleva años obsoleto. La IA es el clavo final en el ataúd. El que sobreviva (y cobre) será el que pueda hablar con el cliente, analizar su proceso deficiente, y traducir ese caos a un conjunto de reglas que sí pueda entender una IA.

Tu flujo es bueno para lo segundo. Para lo primero, no hay atajos. Solo calle, escepticismo y saber que el cliente siempre miente, aunque no sea a propósito.
Hacer clic para expandir...

No me parece que "dé igual". Veo dos escenarios:

- Que el bug se deba a que el "qué" que dio lugar a ese código sea incorrecto.
- Que el bug se debe a que el "cómo" está mal implementado.

En ambos casos, es importante saber quién va a corregir el bug:

- ¿Una IA? Pues entonces hay que pasarle explícitamente el qué, la especificación, porque el riesgo de que "alucine" y se lo invente es alto.
- Un humano debería tener capacidad de levantar la mano y decir: eh, aquí no está claro si debería hacerse X o Y.

En ambos casos, si la aplicación ha sido programa con IA, pero con método, no el caos del "vibe coding", tendrá partes separadas que un humano podrá pasarle a una IA para su corrección, y el riesgo de que te haga perder el tiempo con soluciones erróneas será menor.

Esto es lo que voy viendo. Ni de coña tengo un sistema 100% perfecto y consolidado. Lo único que voy entendiendo poco a poco es que, bien usadas, las IAs multiplican la productividad por un factor que no sé cuantificar, ¿quizá un 4x, 5x...?
 
tigrisdelagalia dijo:
@burbubot ¿qué pasa con médicos, jueces/abogados, economistas, ingenieros, políticos, etc?

¿por qué la IA sólo va a reemplazar a programadores?

¿no podrá leer la IA el historial clínico, una analítica de sangre/pipi de una persona y diagnosticar?

¿no podrá leer la IA tener en RAM toda la legislación, el histórico de jurisprudencia/sentencias pasadas de toda la jerarquía de tribunales, versión de acusación y defensa, etc... y defender o juzgar?

ídem con cuenta de resultados, auditorías, temas fiscales, etc... en una empresa o en bolsa

ídem con cálculo de estructuras, carreteras, ferrocarriles...

etc...
Hacer clic para expandir...

La cantidad de 'información externa' que puede trabajar la IA es ínfima. Si intentas meterle auditorias, PDFs, excels, tropecientos documentos, dependerás de que el RAG acierte a la hora de traer la información necesaria para contestar tu pregunta.

Lo hace muy bien, pero el sistema es ese. De todos los documentos, decide qué información traer (que es escasa...) y con esa información contesta la pregunta. El resto de la información, como si no existiera.

Imagina que tomas una decisión subiéndole tropecientos archivos de ventas, información técnica de los productos que vendes, personal, etc etc. Todo aquello que tú crees relevante para que conozca a fondo la problemática de tu empresa.

De todos los documentos que subas, buscará y traerá lo que considere relevante. Y CON ESA INFORMACIÓN EXCLUSIVAMENTE te dará una respuesta.

Igualmente, puede existir una IA que esté entrenada específicamente para temas legislativos. Ojo, con un entrenamiento especial; en la IA no hay nada grabado físicamente, es solo un sistema de pesos específico.

Eso implicaría seguramente que alguien gaste decenas de millones de euros en entrenarla de una forma especial. Y siempre tendrás el problema de que aquellos artículos que más se repitan se podrán 'recuperar' textualmente porque están bien grabados, pero aquellos con menor importancia se los puede inventar. En un mundo donde una palabra cambia todo el significado...
 
TDT' dijo:
(mensaje citado en revisión)
Hacer clic para expandir...

Un ejecutable no interpretable por un humano sería una caja zaina llena de suposiciones y comportamientos impredecibles.

No es que un lenguaje de programación simplemente facilite la comunicación, es que es un contrato escrito en un lenguaje no-ambiguo, a diferencia del lenguaje humano.
 
Reaccionario dijo:
He puesto Gemini (Workspace) en una empresa medio propia de 14 empleados y bueno.... Gemini @gmail @calendar busca mails de clientes conflictivos y/o incidencias que veas recurrentes me ha eliminado gran parte del trabajo... lo he conectado con AppSheet, boots, y AppScripts y sin sistemas, operaciones ni programación más que mis ratos libres... cuanto tiempo perdido en reuniones.
La cuestión es no escribir [...] , tener buena documentación y trabajar sobre ella, llega un momento que se lo pegas en Docs, le dices mira monta un SAAS de X acorde a la documentación, casi te lo clava, pero con un /compact y 4 chorradas más lo acaba clavando.

Ejemplo, he montando un SAAS en 4 meses de los que he llegado a pagar entre 25-40K de coste, solo en tiempo libre, antes no lo hacía porque era inviable, ahora factura poco, sobre 1.000 al mes, pero espectativa de 150K este año, coste mi tiempo... ¿el problema? depliegue nada más, se puede hacer todo solo con IA pero existe una parte que jamás se suplirá que es el factor humano en la venta.

¿Sistemas de conciliación bancaria en tiempo real con avisos por robo en base a la IA de mi experiencia etc.? Pues listo, en producción, 2 semanas, facturando 2.500 euros mes.

También he montado un LLM local y a validar código según escriben los agentes continuamente, cuando llego al 90% estimado paro y lo revisamos, mejor que las personas, lo siento. Esto me lo dio de idea un amigo de una multinacional que ahora está un Dubai haciendo lo mismo, pero a nivel de millones.
Hacer clic para expandir...
cuenta el setup y hardware de tu ia en local. qué modelo le metes? te da para varios agentes? presupuesto?
 
Puede ser, pero en ese contrato la letra pequeña es muy complicada, o me quieres decir que los programadores tienen en la cabeza la arquitectura de los procesadores y como se traduce eso a lenguaje máquina? Vete a saber qué electrones van por cada pista o por cada transistor cuando pones un bucle

La programación que he hecho en mi carrera es cálculo científico, por eso te digo que programador no soy, solo hago cálculos con códigos, muchos años en Fortran, no te digo más. Si tuviera que firmar un contrato de no-ambigüedad con mi ordenador, preferiría que ese contrato estuviese escrito en álgebra que en un lenguaje aleatorio con manuales.

Creo que no debemos confundir el hecho de perder el control de los cálculos exactos con el hecho de que aparezca ambigüedad. Supongo que lo mismo sintieron los que programaban en ensamblador cuando les presentaron los primeros compiladores, muchos debieron ponerse nerviosos. Ya, pongo una línea aquí que dice a=3, ¿y dónde malos se pone ese tres en la memoria? ¿Y dónde queda almacenada la posición donde ha puesto el tres? Y si lo sumo a otro número y me tengo que llevar una, ¿dónde lo pone? Y si ejecuto el programa mañana, ¿lo va a poner en el mismo sitio o lo va a decidir el fruta sin preguntarme?
 
Marcus Halberstam dijo:
No sé si quizá estás pensando en "vibe coding" (pedir cosas a la IA sin método, receta para el desastre a medio plazo), pero yo estoy probando el siguiente flujo de trabajo, y funciona bastante bien para empezar un desarrollo desde cero:

1. Antes de escribir una línea de código, pedirle a una IA un diseño que defina todas las interfaces y módulos, y no continuar hasta verlo claro, consultando con otras IAs.
2. Luego, aplicar TDD. Primero le pedimos que escriba tests de cada módulo.
3. Luego los módulos.
4. Refactorizar: una vez que funciona, pedir: "optimiza este código para legibilidad sin romper los tests y siguiendo de manera estricta las siguientes normas de clean code: etc. etc.".
5. Pedirle a otra IA que revise el código, refactorizar de nuevo si es necesario, y vuelta a 2.
Hacer clic para expandir...
Yo hago algo parecido, primero creo md detallando la idea, después basandose en eso se desarrolla un plan , después se van ejecutándo las tareas una a una y documentando la lógica de negocio en memoria persistente y que no haga nada sin consultar la lógica y que si ve algo raro que avise, cuando funciona le digo que lo pruebe y me de feedback
 
TDT' dijo:
Puede ser, pero en ese contrato la letra pequeña es muy complicada, o me quieres decir que los programadores tienen en la cabeza la arquitectura de los procesadores y como se traduce eso a lenguaje máquina? Vete a saber qué electrones van por cada pista o por cada transistor cuando pones un bucle

La programación que he hecho en mi carrera es cálculo científico, por eso te digo que programador no soy, solo hago cálculos con códigos, muchos años en Fortran, no te digo más. Si tuviera que firmar un contrato de no-ambigüedad con mi ordenador, preferiría que ese contrato estuviese escrito en álgebra que en un lenguaje aleatorio con manuales.

Creo que no debemos confundir el hecho de perder el control de los cálculos exactos con el hecho de que aparezca ambigüedad. Supongo que lo mismo sintieron los que programaban en ensamblador cuando les presentaron los primeros compiladores, muchos debieron ponerse nerviosos. Ya, pongo una línea aquí que dice a=3, ¿y dónde malos se pone ese tres en la memoria? ¿Y dónde queda almacenada la posición donde ha puesto el tres? Y si lo sumo a otro número y me tengo que llevar una, ¿dónde lo pone? Y si ejecuto el programa mañana, ¿lo va a poner en el mismo sitio o lo va a decidir el fruta sin preguntarme?
Hacer clic para expandir...

No estoy seguro de entenderte.

Lo que quiero decir es que la mayoría de programas de ordenador, no todos, tienen que ser deterministas, o un avión podría terminar cayendo, una cuenta bancaria perdería/ganaría fondos de forma no deseada, etc.

Si una IA escribe directamente ensamblador, es difícil o directamente imposible que un humano certifique que ese código hace lo que tiene que hacer.

Pero si la IA escribe código C,Python, Java, es decir algo interpretable no solo por la máquina, sino por un humano, sí.

Porque ese código se trasladará a ensamblador de manera determinista, con lo que, por decirlo así, ese código de ensamblador ha "firmado" un contrato por el que sabes que va a hacer lo que quieres que haga, y que está escrito en un lenguaje preciso (C, Python, Java), no en lenguaje humano.
 
No veremos sistemas críticos no supervisados por humanos en el sector público, en el sector privado no estoy tan seguro. Cómo se deduce de lo que apuntáis, igual aguanta un poco mas por asuntos legales, seguros, etc. Igual no lo vemos antes de dos años 😉
 
Remero_boga_ariete dijo:
cuenta el setup y hardware de tu ia en local. qué modelo le metes? te da para varios agentes? presupuesto?
Hacer clic para expandir...
Los servidores que hemos retirado de clientes o que estaban dando servicio a soluciones de escritorio y hemos migrado a soluciones Cloud, habrá 8 ahora mismo, el coste a día de hoy con la subida de memorias es mucho y la luz la paga la empresa.
 
Reaccionario dijo:
Los servidores que hemos retirado de clientes o que estaban dando servicio a soluciones de escritorio y hemos migrado a soluciones Cloud, habrá 8 ahora mismo, el coste a día de hoy con la subida de memorias es mucho y la luz la paga la empresa.
Hacer clic para expandir...
O sea que les pones IA en servidores de la nube, ¿no?

No digo que hagas nada descabellado, pero por seguridad y en el largo plazo, creo que las IAs deberían ser locales.
 
A mí me da igual la programación, de hecho me parece que habláis en chino, pero siempre me meto en estos hilos porque me fascina la gente que le tiene tantas ganas a ese sector, alguno se cortaría los cigot por tal de verlos a todos en la calle mendigando y poder decir "os lo dijeeee uajajajajaja a comer m***** descendientes de p***!! os lo merecéis por haber sido una profesión bien pagada!!"
 
no me creo nada dijo:
O sea que les pones IA en servidores de la nube, ¿no?

No digo que hagas nada descabellado, pero por seguridad y en el largo plazo, creo que las IAs deberían ser locales.
Hacer clic para expandir...
Las IA locales, a los clientes que utilizaban una solución de E/S los he migrado a Odoo principalmente. Los IA siempre en local, desde remoto siempre me conecto por VPN.
Además que antes de enviarle nada a DeepSeek o Gemini primero lo normalizo (oculto usuarios, contraseñas, datos sensibles) me lo devuelve y luego el LLM me deja el texto bonito, simplificando mucho.
 
Reaccionario dijo:
Las IA locales, a los clientes que utilizaban una solución de E/S los he migrado a Odoo principalmente. Los IA siempre en local, desde remoto siempre me conecto por VPN.
Además que antes de enviarle nada a DeepSeek o Gemini primero lo normalizo (oculto usuarios, contraseñas, datos sensibles) me lo devuelve y luego el LLM me deja el texto bonito, simplificando mucho.
Hacer clic para expandir...
Lo de ocultar usuarios, etc., ¿sabes que si no lo hicieras nadie se enteraría, no? Y que habrá quien no lo haga. Y luego hablan de si las IAs pueden detectar agujeros de seguridad...
 
Reaccionario dijo:
Las IA locales, a los clientes que utilizaban una solución de E/S los he migrado a Odoo principalmente. Los IA siempre en local, desde remoto siempre me conecto por VPN.
Además que antes de enviarle nada a DeepSeek o Gemini primero lo normalizo (oculto usuarios, contraseñas, datos sensibles) me lo devuelve y luego el LLM me deja el texto bonito, simplificando mucho.
Hacer clic para expandir...

Pero es que una cosa es que tengas la E/S y orquestación en local, y otra que tengas la IA en local...
 
Iniciar sesión o registrarte para responder aquí.

Estadísticas del foro

Temas
2.059.756
Mensajes
58.453.934
Miembros
191.085
Último miembro
grequito2026

El blog de burbuja.info

-
-
Volver