Mostrando las entradas con la etiqueta desarrollo de software. Mostrar todas las entradas
Mostrando las entradas con la etiqueta desarrollo de software. Mostrar todas las entradas

jueves, octubre 01, 2026

Cómo empezar en Inteligencia Artificial, programación y agentes: la ruta que yo seguiría hoy

Muchas personas me han preguntado últimamente:

“¿Cómo comienzo en el mundo de la Inteligencia Artificial, la programación y la creación de agentes?”

Así que decidí escribir la respuesta más completa que pudiera.

No pretendo que esta sea la única ruta. Es simplemente la ruta que, con lo que sé hoy, 1 de octubre de 2026, recomendaría a alguien que quiere comenzar desde cero y llegar al punto en el que pueda construir sus propias aplicaciones con Inteligencia Artificial.

Y quiero comenzar con algo que para mí es fundamental:

No necesitas aprender todo antes de comenzar a construir.

De hecho, creo exactamente lo contrario.

La mejor manera de aprender este mundo es construyendo cosas pequeñas, equivocándote, preguntándole a la IA, corrigiendo y volviendo a construir.

En mi caso, la Inteligencia Artificial se ha convertido en un gran maestro.

He tomado cursos, leído documentación, visto videos y estudiado tecnología durante muchos años. Todo eso sigue siendo valioso. Pero pocas herramientas educativas me han permitido aprender con la velocidad con la que hoy puedo aprender teniendo al lado una IA a la que puedo preguntarle:

“No entendí esto. Explícamelo de otra manera.”

“Ponme un ejemplo.”

“Ahora hazlo más difícil.”

“Déjame intentarlo.”

“No continúes hasta que yo lo haya entendido.”

Eso cambia radicalmente la forma de aprender.

Esta es la ruta que recomiendo.


0. Antes de comenzar: cambia la forma de aprender

Hay una idea que atraviesa toda esta guía:

No utilices la IA solamente para que haga cosas por ti. Utilízala para que te enseñe a hacerlas.

Son dos usos completamente diferentes.

Puedes decir:

“Hazme una aplicación en Python.”

Y probablemente obtendrás código.

Pero también puedes decir:

“Quiero aprender Python construyendo una aplicación sencilla. Actúa como profesor. Explícame cada decisión. Avancemos paso a paso. No continúes hasta que yo confirme que entendí.”

La segunda aproximación construye algo mucho más importante que una aplicación:

construye conocimiento.


1. Comprende qué es realmente un LLM

Antes de crear aplicaciones con Inteligencia Artificial considero casi obligatorio comprender, al menos conceptualmente, qué es un Large Language Model — LLM.

No tienes que convertirte en investigador de Machine Learning.

Pero sí deberías comprender conceptos como:

  • tokens,
  • ventana de contexto,
  • probabilidades,
  • temperatura,
  • prompt,
  • alucinaciones,
  • entrenamiento,
  • inferencia,
  • embeddings,
  • modelos fundacionales.

Y, sobre todo, comprender una idea:

Un LLM no es una base de datos que “conoce la respuesta”. Es fundamentalmente un sistema probabilístico que genera una continuación plausible a partir del contexto recibido.

Eso explica muchas de sus fortalezas.

Y también muchas de sus limitaciones.

Para comenzar recomiendo ver este video:

No pases demasiado rápido por esta etapa.

Cuando entiendes aproximadamente qué ocurre detrás de un LLM, comienzas a utilizarlo de una manera completamente diferente.


2. Aprende Prompt Engineering

El siguiente paso es aprender a comunicarse correctamente con estos modelos.

Es decir: Prompt Engineering.

Puede parecer que esto perderá importancia porque los modelos cada vez entienden mejor nuestras intenciones.

En cierta forma es verdad.

Pero existe una habilidad más profunda que probablemente seguirá siendo muy importante:

aprender a expresar claramente una intención, proporcionar contexto, definir restricciones y describir cómo reconocer una buena respuesta.

Eso sirve para conversar con ChatGPT.

Pero también sirve para programar con agentes, desarrollar software con IA, construir automatizaciones y crear sistemas agénticos.

Un buen prompt debería enseñarte a pensar en:

  • Rol: quién quiero que sea la IA.
  • Contexto: qué necesita saber.
  • Objetivo: qué quiero lograr.
  • Restricciones: qué puede y qué no puede hacer.
  • Criterios de éxito: cómo sé que la respuesta es buena.
  • Formato: cómo quiero recibir la respuesta.
  • Ejemplos: qué significa para mí una respuesta correcta.

Por ejemplo:

Rol: Actúa como arquitecto de software senior.

Contexto: Estoy construyendo una aplicación de citas médicas con React y Python.

Objetivo: Ayúdame a identificar los requerimientos funcionales.

Restricciones: El sistema inicialmente no tendrá pagos ni integración con EPS.

Proceso: Hazme preguntas antes de proponer la arquitectura.

Formato: Organiza los requerimientos por épicas e historias de usuario.

Eso ya es mucho más poderoso que decir:

“Créame una aplicación de citas.”

¿Dónde aprender Prompt Engineering?

Tienes muchas opciones.

Puedes hacer un curso en Udemy, buscar cursos y tutoriales en YouTube o utilizar directamente ChatGPT, Claude o Gemini como profesor.

Mi recomendación es combinar las tres cosas.

Pero no estudies prompting durante tres meses.

Aprende los fundamentos y comienza a utilizarlo inmediatamente en proyectos reales.


3. Después aparecen tres caminos

Una vez tienes esas dos bases —comprender aproximadamente los LLM y saber interactuar con ellos— aparecen varios caminos.

Yo los organizaría así:

  1. Vibe Coding: construir aplicaciones conversando con la IA.
  2. Spec-Driven Development: construir software mediante especificaciones explícitas.
  3. Desarrollo de aplicaciones y agentes de IA: comenzar a programar directamente soluciones con LLM, RAG, tools y agentes.

No son caminos excluyentes.

De hecho, recomiendo recorrer los tres.


4. Camino 1: aprende Vibe Coding

El llamado Vibe Coding consiste, simplificando mucho, en construir software mediante una conversación con una Inteligencia Artificial.

Describes lo que quieres.

La IA genera código.

Ves el resultado.

Corriges.

Refinas.

Repites.

Las herramientas cambian muy rápidamente, así que probablemente cuando leas este artículo existan otras.

A octubre de 2026, algunas herramientas que vale la pena explorar son:

Especialmente para alguien que está comenzando, estas herramientas son impresionantes porque reducen muchísimo la barrera de entrada.

Ejercicio: construye una aplicación de citas médicas

Por ejemplo, dile inicialmente a ChatGPT:

Quiero construir una aplicación sencilla para gestionar citas médicas.

Actúa como analista de producto.

Ayúdame a definir los requerimientos funcionales mínimos para una primera versión.

No programes todavía.

Quiero máximo 8 funcionalidades.

La IA probablemente te propondrá cosas como:

  • crear pacientes,
  • crear médicos,
  • consultar disponibilidad,
  • agendar una cita,
  • cancelar una cita,
  • consultar agenda,
  • modificar una cita,
  • visualizar próximas citas.

Toma esos requerimientos y llévalos a Lovable, Google AI Studio o la herramienta que quieras experimentar.

Pero aquí viene una recomendación importante:

No intentes construir toda la aplicación en un solo prompt.

Trabaja mediante incrementos pequeños.

Primero crea la pantalla principal.

Después pacientes.

Después médicos.

Después agenda.

Después citas.

Después persistencia.

Después autenticación, si realmente la necesitas.

Ese hábito de construir mediante cambios pequeños será increíblemente útil cuando pases a sistemas más grandes.

Aprende también qué hay detrás

No te conformes con que la aplicación “funcione”.

Pregúntale a la IA:

  • ¿Dónde está el frontend?
  • ¿Qué framework está utilizando?
  • ¿Dónde están los datos?
  • ¿Existe una base de datos?
  • ¿Cómo se autentican los usuarios?
  • ¿Dónde se almacenan las credenciales?
  • ¿Cómo se despliega?
  • ¿Qué riesgos de seguridad existen?

Aunque al comienzo entiendas solamente el 30 %, ya estás aprendiendo.


5. Camino 2: aprende Spec-Driven Development

Después del Vibe Coding recomiendo dar un paso adicional.

En lugar de pedir:

“Construye esto.”

aprendes primero a definir:

“Esto es exactamente lo que quiero construir.”

Ahí aparece el Spec-Driven Development — SDD.

La idea me parece especialmente poderosa en un mundo donde producir código será cada vez más barato.

Si la IA puede producir muchísimo código, entonces aumenta el valor de especificar correctamente:

  • qué problema queremos solucionar,
  • qué comportamiento esperamos,
  • qué restricciones existen,
  • cómo vamos a verificarlo,
  • qué arquitectura utilizaremos,
  • qué pruebas demostrarán que funciona.

Dos proyectos que recomiendo explorar son:

Con Spec Kit, por ejemplo, el flujo básico se puede entender conceptualmente como:

Constitution → Specification → Plan → Tasks → Implementation → Validation

Eso obliga a pensar antes de generar código.

Pero no estudies SDD leyendo cincuenta páginas primero

Mi recomendación es exactamente la contraria.

Apréndelo construyendo.

Este fue el tipo de prompt que utilicé para aprender:

¿Quieres aprender Spec-Driven Development? No le pidas a la IA que te lo explique. Pídele que te enseñe mientras construyes algo.

Quiero aprender Spec-Driven Development usando Spec Kit:

https://github.com/github/spec-kit

Tengo GitHub Copilot y Visual Studio Code.

Construyamos un sistema de alquiler de vehículos con React, Python y CSV.

Solo 8 funcionalidades.

Sin login.

Actúa como mi profesor.

Quiero comprender por qué hacemos cada paso.

Avancemos paso a paso.

No continúes hasta que yo confirme.

Ese pequeño cambio es importantísimo.

No estás diciendo:

“Explícame Spec-Driven Development.”

Estás diciendo:

“Enséñame Spec-Driven Development mientras desarrollamos software.”

Para mí esa es una de las mejores formas de utilizar la IA como maestro.


6. Instala un entorno básico de desarrollo

Si quieres continuar hacia aplicaciones de IA más sofisticadas, en algún momento deberías sentirte cómodo con un entorno de desarrollo.

No necesitas convertirte inmediatamente en ingeniero senior.

Pero sí necesitas una pequeña caja de herramientas.

Yo recomendaría:

Personalmente trabajo mucho con Visual Studio Code.

Y, para comenzar con Python, usaría una versión moderna compatible con las librerías que quieras explorar. Python 3.11 y 3.12 siguen siendo versiones cómodas para muchos ejercicios y frameworks, aunque obviamente debes revisar siempre los requerimientos actuales de cada proyecto.


7. Aprende solamente el Python que necesites

Aquí tengo una opinión que probablemente molestará a algunos puristas.

No esperaría a “aprender Python completamente” para empezar a crear aplicaciones con IA.

Python es enorme.

No necesitas saberlo todo.

Probablemente yo utilizo conscientemente una fracción relativamente pequeña de todo lo que Python puede hacer.

La IA escribe buena parte del código.

Pero eso no significa que puedas ignorarlo completamente.

Necesitas comprender, al menos:

  • variables,
  • strings,
  • listas,
  • diccionarios,
  • condicionales,
  • ciclos,
  • funciones,
  • clases de manera básica,
  • módulos,
  • manejo de errores,
  • archivos,
  • entornos virtuales,
  • instalación de paquetes con pip o herramientas equivalentes.

Eso lo puedes aprender mediante un curso básico de Python.

Puedes hacerlo en:

Pero nuevamente:

aprende construyendo.


8. Reto 1: llama tu primer LLM desde Python

Este es, para mí, el primer gran reto técnico.

Debes lograr que un programa Python envíe una pregunta a un modelo y reciba una respuesta.

Punto.

Nada más.

Algo conceptualmente así:

Usuario
   ↓
Python
   ↓
LLM
   ↓
Respuesta

Puedes utilizar un modelo local mediante:

Ollama

o utilizar APIs externas como:

Cuando consigas enviar:

“Explícame qué es Business Agility.”

desde Python y recibir una respuesta, habrás dado un paso conceptual enorme.

Porque ya no estás usando ChatGPT.

Estás construyendo software que utiliza Inteligencia Artificial.


9. Reto 2: construye una API con FastAPI

El siguiente paso es aprender cómo convertir ese pequeño programa en un servicio.

Para eso recomiendo:

FastAPI

FastAPI es una excelente forma de construir APIs con Python.

Puedes pedirle a la IA:

Quiero aprender FastAPI.

Ayúdame a construir una API pequeña en Python que reciba una noticia y utilice un LLM para extraer cinco ideas principales.

Quiero utilizar buenas prácticas.

Explícame cada archivo.

Avancemos paso a paso.

No continúes hasta que confirme cada paso.

O puedes construir una API que:

  • convierta requerimientos en historias de usuario,
  • analice un RFP e identifique riesgos,
  • resuma documentos,
  • clasifique comentarios de clientes,
  • extraiga compromisos de una reunión,
  • proponga lugares turísticos entre dos puntos,
  • analice retrospectivas ágiles.

El objetivo todavía no es construir algo revolucionario.

El objetivo es comprender la arquitectura:

Frontend
   ↓
API
   ↓
Python / FastAPI
   ↓
LLM

10. Reto 3: aprende embeddings

Después necesitas comprender uno de los conceptos más importantes para muchas aplicaciones modernas de IA:

los embeddings.

Una forma sencilla de entenderlos es pensar que transformamos contenido —por ejemplo textos— en representaciones numéricas que permiten comparar significado.

Eso permite resolver problemas fascinantes.

Ejercicio recomendado

Supongamos que tienes:

  • 20 hojas de vida,
  • una descripción de un cargo.

Construye una aplicación que utilice embeddings para identificar cuáles hojas de vida son semánticamente más cercanas al perfil buscado.

No uses palabras exactas solamente.

Compara significado.

Cuando entiendas ese ejercicio habrás comprendido una pieza fundamental de:

  • búsqueda semántica,
  • sistemas de recomendación,
  • RAG,
  • memoria semántica,
  • recuperación de información.

11. Reto 4: aprende RAG

Después de embeddings, el siguiente concepto que considero fundamental es:

RAG — Retrieval-Augmented Generation.

La idea general es muy poderosa.

En lugar de preguntarle directamente al modelo:

“¿Cuál es la política de vacaciones de mi empresa?”

primero buscas la información relevante en tus documentos.

Después esa información se entrega al modelo como contexto.

Conceptualmente:

Pregunta
   ↓
Búsqueda
   ↓
Documentos relevantes
   ↓
LLM
   ↓
Respuesta fundamentada

Ese patrón aparece constantemente en aplicaciones empresariales.

Construye algo pequeño

Toma cinco documentos PDF.

Construye una aplicación que permita preguntar sobre ellos.

Pero no te conformes con obtener una respuesta.

Pregúntate:

  • ¿recuperé los fragmentos correctos?
  • ¿cuántos fragmentos recuperé?
  • ¿la respuesta realmente está soportada por los documentos?
  • ¿qué pasa cuando la respuesta no está en los documentos?
  • ¿cómo podría medir la calidad del sistema?

Ahí comienzas a entrar realmente en ingeniería de sistemas de IA.


12. Reto 5: aprende a utilizar Tools

Hasta ahora el modelo básicamente piensa y responde.

Pero un sistema mucho más interesante aparece cuando el modelo puede hacer cosas.

Por ejemplo:

  • consultar una base de datos,
  • llamar una API,
  • buscar información,
  • crear un archivo,
  • consultar un calendario,
  • enviar un correo,
  • ejecutar una función Python.

Esas capacidades suelen implementarse mediante tools o funciones que el modelo puede decidir utilizar.

Ese es uno de los saltos conceptuales más importantes.

Pasas de:

IA que responde.

a:

IA que puede actuar sobre un sistema.


13. Reto 6: aprende MCP

Después recomiendo estudiar:

MCP — Model Context Protocol.

MCP busca estandarizar la forma en que aplicaciones basadas en modelos pueden conectarse con herramientas, datos y servicios externos.

Si vas a trabajar seriamente con agentes, vale la pena comprenderlo.

Documentación:

https://modelcontextprotocol.io/

Tu ejercicio puede ser muy sencillo:

Construye o utiliza un servidor MCP con una herramienta sencilla y haz que un cliente o agente pueda descubrirla y ejecutarla.

No importa que el ejemplo sea trivial.

Lo que importa es comprender el protocolo.


14. Ahora sí: comprende qué es un agente

Después de recorrer lo anterior, finalmente la palabra agente comienza a tener mucho más sentido.

Una explicación simplificada podría ser:

             ┌─────────────┐
             │     LLM     │
             │   Cerebro   │
             └──────┬──────┘
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       Memoria    Tools     Contexto
          │         │
          └────┬────┘
               ↓
            Acción

Yo lo explicaría inicialmente así:

Un agente combina un modelo, instrucciones, contexto, memoria y herramientas para perseguir un objetivo mediante una secuencia de decisiones y acciones.

No es solamente un chatbot.

Puede observar.

Puede decidir.

Puede utilizar herramientas.

Puede revisar resultados.

Puede volver a intentarlo.

Puede mantener estado.

Y ahí empieza la parte realmente interesante.


15. Aprende LangChain y especialmente LangGraph

Cuando llegues a este punto, tiene mucho más sentido estudiar frameworks como:

Mi recomendación es no comenzar aprendiendo el framework de memoria.

Primero entiende:

  • LLM,
  • prompts,
  • embeddings,
  • RAG,
  • tools,
  • estado,
  • agentes.

Después LangGraph tiene mucho más sentido.

Porque entiendes qué problema está resolviendo.

Y no solamente cómo copiar código de un tutorial.


16. Reto 7: crea tu primer agente

Construye algo realmente pequeño.

Por ejemplo:

Agente analista de RFP.

El agente recibe un RFP y puede:

  1. leer el documento,
  2. identificar requisitos,
  3. buscar información adicional utilizando una herramienta,
  4. detectar riesgos,
  5. generar preguntas para el cliente,
  6. crear un resumen ejecutivo.

Eso ya te obliga a combinar muchas de las piezas anteriores.


17. Reto 8: crea una red de agentes

Después puedes dar el siguiente salto:

sistemas multiagente.

En lugar de tener un agente intentando hacerlo todo, puedes experimentar con agentes especializados.

Por ejemplo:

                 Orquestador
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
   Investigador   Analista     Revisor
        │            │            │
        └────────────┼────────────┘
                     ↓
                  Resultado

Para experimentar con esto puedes utilizar:

n8n resulta especialmente interesante cuando quieres combinar agentes con automatización visual, APIs y servicios empresariales.

LangGraph es particularmente interesante cuando necesitas controlar mediante código el estado, las transiciones y la orquestación de sistemas agénticos.


18. Después vienen los Skills

El ecosistema está evolucionando tan rápidamente que continuamente aparecen nuevos patrones.

Uno de ellos es encapsular conocimiento, instrucciones y capacidades reutilizables en skills que los agentes pueden utilizar dependiendo de la tarea.

No comenzaría por ahí.

Pero cuando ya comprendas agentes, tools, MCP y orquestación, empieza a explorar:

  • skills,
  • subagentes especializados,
  • memoria,
  • guardrails,
  • observabilidad,
  • evaluaciones,
  • tracing,
  • sistemas multiagente.

19. Algo que no puedes olvidar: seguridad

Cuando comiences a programar con APIs, nunca pongas tus API keys directamente en el código que subes a GitHub.

Aprende desde el comienzo a utilizar:

  • variables de entorno,
  • archivos .env,
  • .gitignore,
  • gestores de secretos cuando llegues a producción.

Y mientras estés aprendiendo evita utilizar datos personales, historias clínicas, credenciales reales o información sensible.

Utiliza datos sintéticos.


20. La ruta completa

Si tuviera que resumir toda la jornada, sería aproximadamente esta:

1. Comprender qué es un LLM
            ↓
2. Prompt Engineering
            ↓
3. Vibe Coding
            ↓
4. Spec-Driven Development
            ↓
5. Python básico
            ↓
6. Consumir un LLM desde Python
            ↓
7. FastAPI
            ↓
8. Embeddings
            ↓
9. RAG
            ↓
10. Tools
            ↓
11. MCP
            ↓
12. Agentes
            ↓
13. LangGraph / n8n
            ↓
14. Sistemas multiagente
            ↓
15. Skills, evaluaciones y observabilidad

21. Una propuesta de ocho semanas

No necesitas dedicar un año a esto antes de construir algo interesante.

Una persona disciplinada puede recorrer esta ruta inicial en aproximadamente uno o dos meses.

Semana 1

LLM + Prompt Engineering.

Semana 2

Vibe Coding. Construye dos aplicaciones pequeñas.

Semana 3

Spec-Driven Development con Spec Kit u OpenSpec.

Semana 4

Python + llamadas a APIs + FastAPI.

Semana 5

Embeddings + búsqueda semántica.

Semana 6

RAG.

Semana 7

Tools + MCP + primer agente.

Semana 8

LangGraph o n8n + pequeño sistema multiagente.

Si tienes tiempo y disciplina, probablemente puedas hacerlo incluso más rápido.

Pero no conviertas esto en una carrera.

El objetivo no es terminar ocho semanas.

El objetivo es que al terminar puedas decir:

“Entiendo las piezas y soy capaz de construir con ellas.”


22. El secreto: proyectos pequeños

Creo que uno de los errores más comunes cuando comenzamos en este mundo es intentar construir inmediatamente:

“Una plataforma inteligente multiagente con RAG, memoria, visión artificial, blockchain, Kubernetes y probablemente café automático.”

No.

Haz cosas ridículamente pequeñas.

Un script.

Una API.

Una pantalla.

Un embedding.

Un documento.

Una tool.

Un agente.

Después combínalos.

La complejidad debe aparecer como consecuencia del aprendizaje, no como requisito para comenzar.


23. Utiliza la IA como profesor

Esta quizás sea mi recomendación más importante.

No preguntes solamente:

“¿Cómo funciona RAG?”

Pregunta:

Quiero aprender RAG construyendo una aplicación pequeña.

Tengo conocimientos básicos de Python.

Actúa como profesor de ingeniería de software e Inteligencia Artificial.

Construiremos una aplicación que permita hacer preguntas sobre cinco documentos PDF.

Quiero entender cada decisión.

Explícame solamente lo necesario para realizar el siguiente paso.

Hazme preguntas para comprobar que comprendí.

No continúes hasta que yo confirme.

Ese prompt cambia completamente la experiencia.


24. No necesitas saberlo todo

Este mundo se está moviendo demasiado rápido.

No existe una persona que conozca todas las librerías, todos los modelos, todos los frameworks y todas las técnicas.

Y probablemente esa no sea siquiera una meta razonable.

La habilidad importante es otra:

aprender rápidamente cosas nuevas, comprender los principios y saber utilizar la IA para acelerar ese aprendizaje.

Hoy utilizamos unas herramientas.

Dentro de seis meses utilizaremos otras.

Dentro de tres años probablemente buena parte del desarrollo de software se parecerá muy poco al desarrollo de software que conocíamos hace una década.

Por eso intenta aprender los conceptos que sobreviven a las herramientas:

  • cómo describir un problema,
  • cómo especificar comportamiento,
  • cómo dividir problemas grandes,
  • cómo diseñar sistemas,
  • cómo probarlos,
  • cómo evaluar resultados probabilísticos,
  • cómo reducir incertidumbre,
  • cómo construir sistemas confiables.

Conclusión

Si hoy alguien me preguntara:

“Jorge, ¿cómo comienzo en Inteligencia Artificial?”

mi respuesta no sería:

“Haz seis cursos.”

Sería:

Construye ocho cosas.

Construye una conversación con un LLM.

Construye una aplicación mediante vibe coding.

Construye una pequeña aplicación mediante SDD.

Construye una API.

Construye una búsqueda con embeddings.

Construye un RAG.

Construye un agente.

Construye una pequeña red de agentes.

Y utiliza la Inteligencia Artificial como compañero y como profesor durante todo el proceso.

Probablemente en uno o dos meses sabrás muchísimo más de lo que imaginas hoy.

Y, sobre todo, habrás adquirido algo mucho más importante que conocer una herramienta específica:

habrás aprendido a aprender en la era de la Inteligencia Artificial.

Eso, en mi opinión, es la verdadera superpotencia.


Recursos mencionados

Publicado originalmente el 1 de octubre de 2026. Este ecosistema cambia extremadamente rápido; algunas herramientas, modelos o interfaces probablemente habrán cambiado cuando leas este artículo o mientras lo lees😮. Los principios, sin embargo, deberían sobrevivir bastante más tiempo.

martes, septiembre 15, 2026

Los testers son el nuevo cuello de botella de TI.

La IA ya hace testing: ¿entonces para qué necesitamos testers? Una mirada desde Spec-Driven Development

La Inteligencia Artificial ya puede generar código, crear pruebas, ejecutar validaciones, analizar resultados e incluso corregir errores.

Entonces aparece una pregunta inevitable:

Si la IA ya hace testing, ¿para qué necesitamos testers?

Esta fue la pregunta central de la charla que compartí en Testear.la el 10 de septiembre de 2026:

“La IA ya hace testing, ¿entonces para qué necesitamos testers? — Una mirada desde Spec-Driven Development (SDD)”

La discusión no se limita a preguntarnos si la IA reemplazará o no a los testers. El cambio que estamos viviendo es mucho más profundo.

Cuando utilizamos Inteligencia Artificial y agentes para desarrollar software, el trabajo humano comienza a desplazarse desde la ejecución hacia la definición de:

  • qué debe hacer realmente el sistema,
  • qué comportamiento esperamos,
  • qué escenarios debemos considerar,
  • qué riesgos necesitamos controlar,
  • y qué significa que una funcionalidad esté realmente terminada.

El testing está cambiando

La IA puede automatizar una parte creciente de las tareas que tradicionalmente realizaban desarrolladores y testers.

Puede generar pruebas unitarias, pruebas de integración, escenarios, datos de prueba e incluso interpretar los resultados.

Pero existe una diferencia importante entre generar pruebas y entender qué debe probarse.

Y justamente allí aparece uno de los espacios más interesantes para la evolución del rol del tester.

La IA puede automatizar cada vez más la ejecución del testing, pero alguien todavía tiene que decidir qué significa que el software realmente funcione.

Spec-Driven Development cambia la conversación

Desde la perspectiva de Spec-Driven Development (SDD), las especificaciones dejan de ser documentos secundarios que describen algo que ya construimos.

Empiezan a convertirse en uno de los principales mecanismos para dirigir, controlar y verificar el trabajo realizado por agentes de Inteligencia Artificial.

Especificaciones, reglas de negocio, escenarios, criterios de aceptación y condiciones de validación adquieren entonces un valor mucho mayor.

Esto también transforma el testing.

El tester puede evolucionar desde un rol fuertemente enfocado en la ejecución hacia uno cada vez más relacionado con:

  • análisis de riesgos,
  • diseño de escenarios,
  • definición de criterios de aceptación,
  • exploración de comportamientos inesperados,
  • validación del producto,
  • y evaluación del trabajo producido por agentes de IA.

🎥 Mira la charla completa

📑 Consulta también la presentación

Puedes revisar a continuación el documento utilizado como apoyo durante la charla:

Una pregunta abierta

Probablemente el futuro del testing no consista en competir con la IA para ver quién ejecuta más pruebas.

El verdadero valor puede estar en algo mucho más humano:

formular mejores preguntas, descubrir riesgos, definir comportamientos y decidir qué significa realmente construir el producto correcto.

Y en un mundo de desarrollo agéntico, esa capacidad puede ser incluso más importante que antes.

martes, marzo 11, 2025

De lo Complejo a lo Simple: Cómo la IA Está Reinventando el Desarrollo de Software

Marco Cynefin

Hola a todos,

Hace unos días, hablando con mi compañero de trabajo, Roberto Moraga, surgió una reflexión interesante: el desarrollo de software ha pasado de ser un proceso altamente complejo a volverse más simple, en gran parte gracias a la inteligencia artificial. Sin embargo, si bien las herramientas han evolucionado, el mercado (usuarios, consumidores, empresas y negocios) sigue siendo dinámico, incierto y cada vez más complejo. Entender las necesidades y traducirlas en soluciones sigue siendo un desafío estratégico, que marcos como Scrum y metodologías como XP buscan reducir a la interacción con una sola voz.

Después de conversar un rato, llegamos a la misma conclusión: el software ya no se construye de la misma manera que antes. Scrum fue diseñado para gestionar la complejidad del desarrollo de software inicialmente, permitiendo a los equipos adaptarse de manera iterativa y generar soluciones en entornos de incertidumbre y luego su alcance se amplió hacia soliciones en entornos complejos, sin importar si incluían software o no. Sin embargo, hoy en día, el proceso software es mucho más predecible, gracias a la inteligencia artificial, las mejoras en los procesos han aumentado entre un 40% y un 60%, o incluso más, en la generación de código, la validación y la utilización del talento en los equipos.

Esto nos llevó a unas preguntas clave: ¿qué va a pasar con Scrum en el desarrollo de sofware? Si este se ha vuelto más automatizado y eficiente,  ¿Cómo afecta la IA a los marcos ágiles, metodologías ágiles?¿El escalamiento (es decir muchos equipos ágiles) seguirá igual o cambiará al emplear estas nueva tecnología?. Una aproximación para responder a estas preguntas, se plantearán en este artículo.


El desarrollo de software antes de la IA

El desarrollo de software siempre ha sido un ejercicio de lidiar con la complejidad. Antes de la llegada de la Inteligencia Artificial (IA) generativa, la construcción de software requería múltiples iteraciones, idas y venidas con el cliente, reuniones de refinamiento y planificación, pruebas constantes y ajustes sobre la marcha. Era un proceso artesanal en el que cada pieza de código debía encajar perfectamente en un entramado ya existente, con una complejidad que crecía exponencialmente con cada nueva funcionalidad.

Con la llegada de los marcos ágiles, esta complejidad se empezó a gestionar de manera más efectiva. En Scrum y XP por ejemplo, los equipos reducían la incertidumbre fragmentando el trabajo en historias de usuario pequeñas, cada una encapsulada dentro de un timebox de dos semanas (1). Por otro lado, Kanban ofrecía flujos de trabajo más cortos y continuos para optimizar la entrega (2). La clave estaba en la descomposición y la priorización: si algo no llegaba a desarrollarse, al menos lo más valioso ya estaba en producción.


¿Por qué el desarrollo de software es complejo?

El software no es solo líneas de código. Es una red interconectada de dependencias, reglas de negocio, infraestructura, bases de datos y lógica distribuida. Su complejidad crece con cada nueva funcionalidad porque:

  • La cantidad de código crece exponencialmente: Cada nueva línea interactúa con muchas otras, lo que hace que el sistema se vuelva más difícil de comprender y modificar (3).
  • Las dependencias se multiplican: Los sistemas modernos no son aplicaciones monolíticas; dependen de APIs, microservicios y plataformas en la nube (4).
  • Las reglas de negocio son cambiantes: Lo que hoy es válido, mañana puede cambiar por una nueva regulación, requerimiento de usuario o innovación del mercado.
  • Las expectativas de los usuarios evolucionan: Lo que antes tomaba meses ahora se espera en semanas o días.

Dave Snowden, con su marco Cynefin, nos dice que un problema puede estar en distintos dominios: simple, complicado, complejo o caótico (5). Durante décadas, el desarrollo de software ha habitado en la zona de lo complejo, donde la relación causa-efecto solo se entiende en retrospectiva, y donde la experimentación y la iteración eran la única forma de avanzar.


¿Cómo la IA ha simplificado el desarrollo de software?

La IA generativa está moviendo el desarrollo de software del espacio de lo complejo al de lo complicado e incluso a la frontera con lo simple. ¿Cómo?

  • Generación automática de código: Hoy en día, un desarrollador puede describir en lenguaje natural qué necesita y herramientas como Copilot o ChatGPT pueden generar código funcional en segundos (6).
  • Automatización de pruebas: La IA puede crear, ejecutar y ajustar pruebas unitarias y de integración sin intervención humana (7).
  • Refactorización asistida: Lo que antes requería semanas de análisis, hoy se puede hacer en minutos con IA sugiriendo mejoras y optimizando código (8).
  • Mayor velocidad en el desarrollo: Ahora es posible generar prototipos funcionales en horas, lo que antes tomaba semanas.

Esto ha cambiado radicalmente el flujo de trabajo. Antes, un equipo de desarrollo tenía que construir cada pieza de código manualmente y validarla en iteraciones cortas. Hoy, la IA permite automatizar gran parte de ese trabajo, transformando el proceso en algo más cercano a un modelo de entrega continua, donde Kanban empieza a ser una herramienta de gestión más efectiva que Scrum (9).


¿Qué pasa con el escalamiento?

El desarrollo de software no solo se ha vuelto más rápido con la IA, sino que también ha impactado la forma en que las organizaciones gestionan el escalamiento. Antes, uno de los mayores desafíos en la escalabilidad era la gestión de dependencias entre equipos: ¿Quién trabaja en qué? ¿Qué bloquea a quién? ¿Cuándo estará disponible una funcionalidad que otro equipo necesita?

Con ciclos de desarrollo más cortos gracias a la IA, los equipos están generando software a una velocidad nunca antes vista. Esto significa que los cuellos de botella ya no están en la escritura del código, sino en la coordinación entre equipos.

La nueva gestión de dependencias

Cuando la generación de código deja de ser un problema, la conversación cambia:

  • Los equipos hablarán más de dependencias y lo harán más rápido, porque llegarán a ellas en menos tiempo.
  • La gestión proactiva de dependencias es clave, porque ahora los bloqueos pueden detener desarrollos que, de otro modo, habrían estado listos en cuestión de horas.
  • Los gestores de flujo de trabajo (Scrum Masters, Agile Coaches, facilitadores) deberán anticipar y resolver estas dependencias con más rapidez que nunca.

Esto tendrá un impacto directo en los marcos de escalamiento ágiles como SAFe, LeSS, Nexus y Spotify Model. Tradicionalmente, estos marcos han tratado las dependencias con eventos de sincronización como el PI Planning (SAFe) o los eventos de coordinación en LeSS. Pero en un entorno donde los equipos avanzan más rápido, estas cadencias predefinidas pueden volverse insuficientes. Y es allí donde toma valor la gestión impecable de las dependencias, que es la forma como trabaja Amazon, que logra escalar sientos de equipos sin necesidad de eventos de coordinación.


Cerrando: De la complejidad a la simplicidad

El desarrollo de software ya no es un proceso 100% artesanal. Las historias de usuario siguen funcionando como método de comunicación con el cliente, pero la ejecución es más ágil que nunca. Algunas funcionalidades pueden construirse de manera casi instantánea, moviendo el desarrollo del espacio complejo al complicado, o incluso a lo simple, cuando la IA puede resolverlo sin intervención humana.

La IA ha cambiado el juego. Ahora, la clave no es escribir código más rápido, sino enforcarnos en en entender mejor el negocio y remover bloqueos con la misma o más velocidad que con la que producimos software.


Saludos ágiles,

Jorge Abad


Referencias

  1. Schwaber, Ken, and Jeff Sutherland. The Scrum Guide. Scrum.org, 2020.
  2. Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
  3. McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, 2004.
  4. Lewis, James. Microservices: The Journey to Cloud Native. O'Reilly Media, 2019.
  5. Snowden, Dave. Cynefin: Weaving Sense-Making into the Fabric of Our World. Cognitive Edge, 2020.
  6. GitHub. "Introducing GitHub Copilot." GitHub Blog, 2021.
  7. Agile Alliance. "Dependency Management in Agile Teams." Agile Alliance, 2022.

 

jueves, octubre 17, 2013

Dos post que nos invitan a ser muy buenos desarrolladores y a no menospreciar el arte de escribir líneas de código

Estos dos Post... son de antología

Lo escribieron dos ingenieros que conozco y que son de una alta capacidad técnica, los voy a copiar y pegar acá pues es necesario que esto redunde, que esto cale en la mente de los que se están formando en ciencias de la computación, ingeniería de sistemas, ingeniería informática, afines y tambien cale en quienes las estamos enseñando.

Se que un ciclo de formación profesional no tiene como objetivo un solo fin, pero no tiene presentación que los egresados salgan de carreras de sistemas (y sus afines) y que estos no quieran ver lineas de código "por que ya programaron demasiado en la carrera" como alguna vez lo he oído.

Es una realidad, requerimos buenos y excelentes programadores, pero lo cierto es que muy pocos quieren serlo, o peor quieren dejar de serlo lo antes posible.

------


Muchos caciques y pocos desarrolladores

Por: @GabrielMorrisS - Link: http://gabrielmorrissa.blogspot.com/2013/10/muchos-caciques-y-pocos-desarrolladores.html#!

Hace poco alguien me decía que había evolucionado bastante, que ya no desarrollaba y que dirige proyectos, que es todo un PMP. Casi me pega cuando le mencioné que yo siempre voy a ser un desarrollador, aunque lamentablemente cada vez lo hago menos. 

No me creía cuando le conté que cuando trabajé en unos proyectos en Brasil, el que más ganaba era el tester. Varios se han reído de esa anécdota, pues de inmediato me recuerdan que ese "recurso" debe ser un practicante o un bachiller ávido de conocimiento que ejecute checklists. Falso, el tester no solo hace pruebas, afina y recomienda refactorizaciones, evalúa el comportamiento en ejecución a través de telemetrías, en general tiene cicatrices de guerra, no come cuentos.

En otros escenarios me he enfrentado a discursos acerca del recurso, de fábricas de software, de métricas sofisticadas, de planes tipo bola de cristal, de látigo, como si los desarrolladores de software fueran unos chimpancés que se pueden llevar a alta mar para reducir tributos para que entreguen piezas de software similares a chaquetas o camisas. Que hacemos, el software es arte, lo demás son enfoques comerciales que buscan demostrar teorías de modelos de madurez o medir cuantas veces un "recurso" entra al baño para ser más productivo o contabilizar las líneas de código generadas.

En otros escenarios se muestra a super expertos que se muestran así por certificaciones alcanzadas, expertos de un año de experiencia y 6 meses de manejo de una herramienta. Qué pasará si cambian la herramienta? Si cambian las tácticas, las estrategias, los patrones a aplicar? Será que es mejor tener criterio que un discurso acartonado y poco original? Bien dice el antipatrón de dependencia del vendedor que si su arquitectura son herramientas implicará que no tienes arquitectura.

Otras cosas del hoy, bueno y del ayer es el fastidio a ensuciarse las manos con código miserable. Se buscan más niveles de abstracción olvidándose de niveles subyacentes. Por ejemplo: uso JSF según san X vendedor como MVC, uso como ORM  a hibernate, etc. ¿Qué pasa si ocurre un error en estas APIS? ¿Cómo lo resolvemos? ¿Cómo afinamos las consultas?  ¿Cómo evitamos introspecciones innecesarias? .....otro ejemplo es el uso de flujitos, dibujitos con herramientas que generan código; ¿y si fallan, y si el desempeño no es el esperado?

Hace unos meses un desarrollador tuvo un problema elaborando un servicio Web (mal llamado servicio). La afirmación del personaje era, "no funciona", sin entrar en detalles. El problema consistía en que no seguía un estándar simple de JavaBeans acerca de gets y sets para un bean, Qué pasó? Simple, nos volvimos herramienta dependientes, framework dependientes y nos olvidamos de los fundamentos.

Creemos por ejemplo que un ESB es una herramienta o que un servicio es un servicio Web; simple, los fabricantes necesitan vender y ese es un discurso fácil de mostrar y de aprender por figuras comerciales. Por ejemplo, el ESB es un concepto, una estrategia,  una capa de integración, una guía de arquitectura compuesta de patrones de integración siguiendo un manejo stateless con gestión de recursos orientados a la conectividad, que puede ser implementado a conveniencia y a la medida, no es la super herramienta que centraliza todo el procesamiento de transformaciones o adaptaciones. 

Bueno, y ¿los arquitectos qué? En mi opinión son necesarios. Éstos deben proporcionar decisiones de arquitectura teniendo como base pruebas de concepto PoC, decisiones de diseño de alto nivel HLD que impliquen su desarrollo así como el cumplimiento de restricciones y de los principales aspectos no funcionales. Sin embargo, no creo en arquitecturas de marfil o  BDUF, pues muchas decisiones de diseño detallado se determinan en  el día a día, en el tablero no en modelos que desencadenen generadores de código. Es  necesario un dueño de la arquitectura, un Architect Owner.

Otro punto clave es que conozco muchos casos de empresas de ciudad gótica en donde a las personas de negocio les molesta trabajar con personas de áreas de tecnología. Lo anterior porque ven que no les ofrecen implementaciones que realmente produzcan valor para el negocio, prácticas, sencillas, en tiempos cortos y que den solución a su problemática.

En conclusión, nos preocupamos por el cuidado de la caja, del tiempo, del presupuesto y del alcance, pero no en la generación de valor hacia el cliente quien es finalmente el más interesado en el software, si este le proporciona beneficios. En resumen, es necesario buenos desarrolladores con amplia experiencia, con criterio, que en  muchos casos son conocidos como arquitectos de aplicaciones.

Creo que en países hispano parlantes todos quieren ser abogados, gerentes de proyectos, médicos, pero pocos quieren ser maestros en una actividad específica. De igual manera pasa con los desarrolladores, pues todos quieren ser directores de proyectos o arquitectos en pocos meses.

Espero no herir susceptibilidades ni establecer opiniones fanáticas, es una opinión muy personal: mucho cacique y poco desarrollador.

------------------

Un desarrollador de 20 millones mensuales

Por: Yuji Kiriki


Recibí la llamada de una amiga con la que hace años no hablaba. Con ella trabajamos en un proyecto big bang en el que debíamos automatizar cerca de 30 procesos de negocio hace ya más de 7 años.
Después de ponernos al día, le pregunté el motivo de su llamada. Me dijo que quería saber si ella me podría poner en su hoja de vida como referencia profesional, a lo que respondí afirmativamente. Luego le pregunté si estaba escribiendo software en algún proyecto. Me sorprendió notar un fuerte cambio de tono, casi de indignación e ira; me respondió: “Yo ya no escribo código. Hace mucho que ya no hago eso. Yo ya soy administrativa y estoy Gerenciando proyectos.”
Por otro lado me encontré con un compañero de la universidad. El recién se bajaba de su BMW (no creo que esto indique algo, pero quédense con la connotación esnobista del BMW para efectos de esta entrada). Hablamos, nos reímos y le pregunté a qué se había dedicado. Me respondió con orgullo “nada, usted sabe que a mi me gustaba mucho la parte técnica y era hasta bueno, pero me ofrecieron un cargo Comercial super bien remunerado y ando vendiendo el X producto de esta Y empresa Multinacional Super Reconocida.”.
Esta situación es muy curiosa. En mi trabajo me enfrento a muchísimos proyectos en clientes de varios dominios. A medida que pasa el tiempo me doy cuenta de que las organizaciones esperan más de las plataformas que desarrollamos. Es de esperarse, pues a medida que pasa el tiempo las personas del común van conociendo e interactuando con aplicaciones en línea que cada vez les ofrecen más comodidades, mayores facilidades u optimizaciones en la operación de sus negocios y su vida personal.
Por ejemplo cada vez es más común que nos pidan desarrollos con la disponibilidad de Facebook o con la simpleza y capacidad de respuesta Google. Inclusive nos han pedido colas de trabajo basadas en el comportamiento de Twitter. Es un hecho que los usuarios de las plataformas empresariales ya no son los que otrora se conformaban con lo que se les entregaba y eran completamente ignorantes del potencial de las TI.
Estos mismos usuarios son los que hoy en día se inventan requerimientos funcionales cada vez más interesantes. Y no sólo hablo de la experiencia de usuario, sino de reglas de negocio basadas en la evaluación de miles de eventos; o la detección de fraude en tiempo cercano al real; pueden ser reglas de negocio que se adapten al flujo de transacciones o que se autogeneren dadas ciertas condiciones de negocio. Sobra decir que estos desarrollos representan retos técnicos considerables.
Si el implementador es capaz de entregar este tipo de funcionalidad, el negocio será seguramente capaz de optimizar su costo de operación o de ofrecer servicios más interesantes a sus clientes. Muy seguramente este tipo de funcionalidad le permitirá a la organización diferenciarse frente a su competencia y posicionarse de mejor manera en el mercado. Posiblemente este conjunto de funcionalidades le permita a la organización abrir nuevos mercados o ganar terreno en el actual.
Ahora pregunto: ¿cuánto está dispuesta a pagar la organización por estas funcionalidades? ¿Le importaría que estas funcionalidades de negocio las desarrolle un joven recién graduado, que devenga al mes menos de $2’500.000 y que debe trabajar más de 12 horas al día, incluyendo sábados, para poder cumplir con un cronograma que definió un Gerente de Proyectos PMI y que acortó un VP por política y por mostrar resultados?
No sé en qué momento en Colombia ser desarrollador se volvió un trabajo, al parecer, de segunda clase. No sé en qué momento seguir siendo desarrollador se volvió sinónimo de no haber avanzado profesionalmente. Me sorprende que esto ocurra en el país si en países desarrollados este oficio es de los mejor pagados 1 o es considerado como uno de los mejores trabajos a realizar profesionalmente 2 debido a la autonomía, bienestar y salario que representan.
Es triste, pero no es raro ver las famosas y mal llamadas Fábricas de Software repletas de inexpertos e ignorantes 3 desarrolladores trasnochando de domingo a domingo entregando software hecho de la peor manera por cansancio, siguiendo metodologías rancias (RUP, TSP, PSP, ¿alguien?) y cumpliendo cronogramas políticos. No es raro que me llamen a prestar servicios de consultoría en proyectos donde el Arquitecto no tiene idea de desarrollo de software, pero sí de productos; lo que los lleva a implementar plataformas inviables.
¿Lo más triste de todo? Que estas plataformas supuestamente prestarán servicios a los ciudadanos o en teoría deberían optimizar la operación de una organización para ayudarla a cumplir con sus objetivos estratégicos.
Ah, la estrategia. Estos, podríamos decir, nuevos ricos llamados “Arquitectos Empresariales” que al ser tan “estratégicos” no tienen idea de software ni de tecnología pues saber de eso los ensucia o los avergüenza y terminan comprando productos porque están de moda o porque la competencia también los adquirió. Ríanse los documentos de justificación que se jalan estos personajes.
¿O qué me dicen de algunos Arquitectos que definen Arquitecturas de Solución pero que son incapaces de implementarlas, pues desarrollar software es una labor demasiado operativa y vulgar que debe ser tercerizada en alguna Fábrica de Software en India para que le cobren por hora hombre o punto de función (sólo nombrarlo da ganas de vomitar) y no por valor de negocio entregado?
Es un hecho que las plataformas de software son mecanismos a través de las cuales las organizaciones pueden innovar y pueden apalancar los objetivos estratégicos. Pero si estas plataformas son implementadas por personas sin experiencia o por personas mal valoradas ¿cuáles serán los resultados? ¿Será que esos resultados les alcanzarán a las empresas para lograr la innovación y el apalancamiento de la estrategia que buscan?
Es vital que nuestra industria empiece a entender que construir requerimientos funcionales no es lo mismo que echar cemento y pegar ladrillos (no es peyorativo, sólo quiero dar la connotación de que no es un oficio operativo). Es fundamental que nos saquemos de la cabeza que los desarrolladores son “recursos 4” intercambiables y explotables y que uno es capaz de hacer lo mismo que el otro.
La industria tiene que caer en cuenta que este oficio es profundamente artesanal y que el resultado de un proyecto depende casi en su totalidad de los artesanos que lo construyen. Entre mejor sea el artesano mejor será el producto. Si no me creen que es artesanal, métanse a Github 5 comparen proyectos y saquen sus conclusiones.
Por nuestra parte, como desarrolladores debemos empezar por respetar nuestro oficio estudiando, leyendo, compartiendo y publicando conocimiento. Debemos formarnos en la capacidad de escuchar, de entender y de proponer. Debemos volvernos diestros en entender una idea de negocio y de presentar la mejor alternativa técnica para llevarla a cabo.
Nosotros como desarrolladores somos el puente entre las ideas, las estrategias y su implementación en TI. También debemos esforzarnos por proponer ideas que abran nuevos mercados o que faciliten la penetración de los productos y servicios actuales. Recuerden Software Is Eating The World 6.
Como buenos desarrolladores debemos hacer valorar nuestro trabajo y explicarle a nuestros clientes que no es lo mismo un desarrollador juicioso con experiencia de 2 años que un desarrollador juicioso con 10 años de experiencia.
Imagínense: es como si compararan un experto en preparación de sushi con 2 años de experiencia con un experto en preparación de sushi con 10 años de experiencia. ¿Cuál pieza de sushi será más valorada suponiendo que ambos han invertido el mismo esfuerzo en ser cada día mejores? 7
Pienso que el tiempo nos dará la razón, pues a medida que las organizaciones dependan más de las plataformas de software, más valiosos deberán ser quienes las implementan. No es lo mismo implementar una aplicación que funciona a una que también funciona y que además es fácil de mantener y evolucionar. ¿Creen que la mantenibilidad de una aplicación depende completamente de la Arquitectura de Referencia o de un generador de código basado en modelos? Pues no mi querido Arquitecto PowerPoint. No.
Si los desarrolladores ven que si siguen en este oficio no van a avanzar profesionalmente porque ni la industria ni nuestros clientes los valoran por su experiencia ¿con qué tipo de desarrolladores se implementarán las retantes y poderosas plataformas de software necesarias en el futuro? ¿Con personas que no se han dedicado a ser maestros en su oficio y dirigidas por Arquitectos con asco a programar?
Para cerrar quisiera que me dijeran cómo se imaginan un desarrollador que devenga veinte millones de pesos mensuales. ¿Qué debería estar haciendo? ¿Qué experiencia debe tener? ¿Es demasiado irreal que en Colombia lleguemos a ese nivel?
¡Espero sus opiniones!