DEV Community: Carlos Arturo Castaño G.

Programar no pasa de moda: por qué la claridad importa más que la sintaxis

Carlos Arturo Castaño G. — Fri, 24 Jul 2026 19:09:42 +0000

Programar no pasa de moda: por qué la claridad importa más que la sintaxis

Sigue la polémica: ¿es necesario aprender a programar? ¿Debe hacerlo quien trabaja en backend, frontend o integra con APIs?

La verdad es que programar nunca pasará de moda, porque programar no es solo escribir programas de computador. Programar es tener una idea clara de los procesos necesarios para realizar una tarea, ya sea dentro de un computador o en la vida cotidiana.

Programar es pensar en procesos

Los programadores siempre han sido y serán necesarios. Lo que cambia —y está cambiando ahora— es la forma en que los programadores le dan órdenes a la máquina.

Cada cierto tiempo surgen nuevos lenguajes y métodos para comunicarse con el computador, porque existen distintos propósitos: manipular imágenes, audio, video o procesar transacciones bancarias, por ejemplo. No todos los lenguajes sirven para lo mismo; cada uno se diseñó pensando en un objetivo concreto.

Aunque, en teoría, con cualquier lenguaje se puede hacer casi todo, en la práctica no siempre es eficiente. Es como usar herramientas de mano: puedes clavar con un martillo, un destornillador o una piedra y eventualmente lograrás algo, pero no siempre con eficiencia. Por eso existen diferentes herramientas.

Cada tarea pide una herramienta

En programación ocurre lo mismo: no es igual crear software para edición de imágenes que para gestionar transacciones financieras. Cada tarea suele tener los lenguajes, marcos y herramientas que mejor se ajustan al fin perseguido.

Hoy los programadores usan inteligencia artificial para que traduzca lo que dicen en su lengua natural a un lenguaje de computador, o para que el sistema explique qué debe hacer. A ese conjunto de tecnologías y componentes —bases de datos, sistema operativo, protocolos, modelos de comunicación, entre otros— se le llama stack.

Antes se usaba más el término framework, que agrupaba modelos y librerías que indicaban a un lenguaje cómo comportarse. Y siempre ha habido múltiples opciones según el lenguaje y el propósito.

La novedad está en la interfaz

¿Qué se vislumbra en el futuro? Que cualquier persona, con o sin conocimientos profundos de lenguajes de programación, pueda indicarle a un sistema lo que debe hacer usando lenguaje natural.

Sin embargo, la IA no adivina lo que no le explicas: si no sabes lo que quieres, la IA no lo sabrá. Por eso, tener claridad sobre los procesos involucrados en una necesidad específica permite pedirle a una IA que convierta esa idea en realidad.

Hay un truco: si le das instrucciones imprecisas a la IA, obtendrás resultados imprecisos. En programación se dice: si no sabes para dónde vas, llegarás a cualquier parte. Con la IA esto es más cierto que nunca.

Pensamiento claro, resultados mejores

Ahora se pueden dar instrucciones en lenguaje natural; esto no es totalmente nuevo —ya existían lenguajes más estructurados desde los años 60—, pero la novedad es que ya no es necesario formular instrucciones tan rígidas.

No obstante, el pensamiento debe seguir siendo estructurado: si quieres algo de calidad, necesitas descomponerlo en pasos concretos. Por eso han surgido prácticas como el diseño de prompts, los bucles de refinamiento y otras técnicas que estructuran el pensamiento en tareas claras y precisas, recuperando muchos principios de la programación estructurada.

Usar prompts, loops u otras herramientas para comunicarse con una IA ayuda a organizar la idea y presentarla de forma coherente, lo cual, si se hace con cuidado, produce resultados satisfactorios.

Conclusión

En definitiva, siempre será necesario que quien "programa" —o quien indica a la IA qué hacer— tenga lucidez y claridad para transmitir sus necesidades de forma precisa.

Igual que cualquier profesional que encarga una tarea: si no entrega instrucciones claras, el resultado será deficiente.

Por eso, quizá dentro de no mucho tiempo no será imprescindible conocer la sintaxis de un lenguaje de programación, pero sí será necesario aprender a expresar ideas con claridad. En ese futuro tendrá gran valor la formación en pensamiento lógico, dialéctica, redacción, sintaxis y todas las habilidades que ayudan a transmitir ideas de forma clara, precisa y coherente.

IA en la nube vs. local: ¿realmente puedes elegir?

Carlos Arturo Castaño G. — Thu, 23 Jul 2026 18:53:51 +0000

En un artículo anterior, hablaba sobre la dicotomía que enfrentamos al decidir dónde ejecutar nuestros modelos de IA: ¿en la nube o en infraestructura local?

Señalé que la decisión gira, en gran medida, en torno a dos factores críticos:

Control de costos
Protección de datos

Y esto sigue siendo cierto. Pero hoy quiero profundizar en un matiz que complica esta elección desde la trinchera de la ingeniería y la gestión administrativa.

El precio de tener el control

Tener un servidor local no es solo comprar un equipo. Es asumir toda una cadena de costos ocultos que muchas veces no se consideran en el presupuesto inicial:

Racks y sistemas de refrigeración
Gabinetes eléctricamente aislados
Cableado estructurado
Mantenimiento físico y actualizaciones

Solo en infraestructura básica, el desembolso inicial puede superar fácilmente los 4.000 USD, dependiendo de las exigencias de rendimiento.

Y el problema no termina ahí. Compartir datos que deben protegerse —algo cada vez más común— encarece aún más la operación, porque las soluciones de seguridad y cumplimiento normativo suman capas de complejidad y gasto.

La conclusión es incómoda pero real: mantener el control total es deseable, pero no siempre está al alcance del bolsillo empresarial.

La alternativa que está ganando terreno: las "factory IA"

Cuando el coste de la infraestructura propia es prohibitivo, surge una opción intermedia que cada vez se menciona más en círculos tecnológicos: las infraestructuras compartidas, también conocidas como "factory IA".

No son data centers tradicionales. Su enfoque no es el almacenamiento masivo de datos, sino ejecutar modelos de lenguaje (LLM) ya probados y listos para consumo empresarial.

Empresas con suficiente capital intelectual y financiero montan estas fábricas de IA y ofrecen acceso a modelos maduros como:

Mistral
Llama
Qwen

Estos modelos se entregan listos para funcionar en servidores potentes, aunque no necesariamente masivos. Y al ser servicios de uso intensivo pero compartido, los precios resultan mucho más manejables.

¿No pagamos ya por IA en la web?

Es cierto. Hoy cualquiera paga por acceso a ChatGPT, Claude o Gemini. Pero el problema de fondo no es el precio por token, sino la soberanía digital.

La soberanía digital no es solo independencia política, sino la capacidad de decidir dónde se alojan los datos, cómo se procesan, quién los controla y a qué costo.

No todos los países, incluso con buen desarrollo tecnológico, pueden crear, capacitar y mantener las enormes infraestructuras necesarias para entrenar modelos desde cero. Pero sí pueden —con apoyo adecuado— ofrecer acceso a modelos ya entrenados, configurados para casos de uso locales.

El rol del Estado y las políticas públicas

Crear una factory IA no es algo que cualquier empresa pueda hacer por sí sola. Requiere:

Grandes inversiones iniciales
Personal altamente calificado
Apoyo estatal para su creación y operación

El Estado debe facilitar incentivos fiscales, marcos regulatorios claros y condiciones que permitan a las empresas invertir en este tipo de infraestructura sin quedar en desventaja frente a los gigantes tecnológicos internacionales.

Sin un impulso público, la palabra "soberanía" queda vacía.

¿Qué pasa si no actuamos?

Me atrevo a hacer una comparación: lo que ocurrió con la expansión de Internet.

Hoy, quien no tiene buena cobertura de red está en desventaja competitiva. Lo mismo pasará con las factory IA. Los países que no construyan una infraestructura adecuada para el procesamiento de IA quedarán rezagados, mientras otros avanzan y consolidan su ventaja.

Conclusión

La dicotomía nube vs. local no se resuelve con una fórmula única. Depende del tamaño de la empresa, del tipo de datos que maneja y del presupuesto disponible.

Pero lo que está claro es que la soberanía digital no puede ser un lujo solo para unos pocos. Las factory IA representan una vía realista para que países y regiones con menos recursos puedan competir en la nueva economía del conocimiento.

La pregunta no es si debemos optar por una u otra, sino cómo podemos construir un ecosistema que permita elegir con soberanía.

¿Tú qué opinas? ¿Has considerado migrar a infraestructura local o compartida? Te leo en los comentarios. 👇

La IA no adivina lo que no pensaste: el 5% que siempre falla

Carlos Arturo Castaño G. — Mon, 20 Jul 2026 17:56:40 +0000

La IA no adivina lo que no pensaste: el 5% que siempre falla

En los últimos meses se repite una idea peligrosa: “con IA ya no te equivocas”.

La realidad, después de usarla de forma intensiva en proyectos reales, es mucho más simple:

Si no pensaste algo, la IA no lo va a adivinar.

Y si lo adivina, no significa que sea correcto.

La IA acelera el desarrollo, pero no sustituye el criterio.

🧠 La ilusión de la “decisión asistida”

Las herramientas de IA actuales son muy buenas para:

Generar código
Repetir patrones
Completar estructuras
Ajustar implementaciones existentes

Pero fallan —y siempre fallarán— en algo clave:

crear intención donde no existe.

Si al diseñar un sistema no pensaste en:

la evolución del endpoint
un caso de uso futuro
una validación de negocio
un cambio de requerimientos

...la IA no puede suplir esa ausencia.

⚖️ El 95 % funciona, el 5 % aparece después

En la práctica, ocurre esto:

El sistema se genera correctamente (95 %), si fue bien concebido y se le dieron:
- los parámetros y contexto correcto
- las herramientas adecuadas
- las proyecciones y límites claros
- los tests que debe cumplir
- las reglas del negocio de forma clara y precisa
Al probar o usar, aparecen ajustes

No porque la IA “falló”.

Sino porque el requisito no existía aún.

Ese 5 % no es un bug de IA.

Es pensamiento tardío.

Y eso es normal en ingeniería.

🛠️ Por qué más herramientas no solucionan esto

Editores con IA (Cursor, Copilot, Claude Code, etc.):

Editan más rápido
Refactorizan mejor
Ahorran trabajo mecánico

Pero no mejoran la toma de decisiones.

Cambian el cómo escribes código,

no el qué deberías haber diseñado.

🔑 La regla fundamental

La IA amplifica lo que ya sabes pensar.

Si tu punto de partida es cero, el resultado sigue siendo cero.

La IA no reduce el error conceptual.

Solo acelera su materialización.

🧩 Conclusión

La IA es una herramienta excelente para ejecutar ideas.

Pero las ideas siguen siendo responsabilidad humana.

Usarla bien no consiste en delegar el pensamiento,

sino en llegar al código con algo que ejecutar.

Porque al final:

la decisión correcta no se genera,

se piensa.

🚀 ¿Te ha pasado? Cuéntame en los comentarios cómo estás usando IA en tus proyectos.

¿IA en la nube o IA local? Reflexiones de un desarrollador que no quiere entregar su backend

Carlos Arturo Castaño G. — Sun, 19 Jul 2026 18:29:16 +0000

De la web ubicua al “todo en la nube”

Vivimos en una sociedad donde casi todo pasa por la web, y para las generaciones más jóvenes esto parece el orden natural de las cosas: apps siempre conectadas, smartphones en la mano y un flujo constante de datos y notificaciones. La información compartida, las redes sociales, los likes, los comentarios y las publicaciones en línea dan la sensación de que “siempre fue así” y de que necesariamente debe seguir siéndolo.

Quienes empezamos en sistemas antes de las redes sociales vimos otra película. Muchos entornos eran stand‑alone, luego llegaron las redes locales con servidores compartidos dentro de la empresa, y más tarde Internet cambió por completo el modelo de trabajo. Pasamos a servicios distribuidos, aplicaciones web y arquitecturas cada vez más acopladas a la conectividad global.

La irrupción (masiva) de la IA

La IA no nació con la nube ni con Internet, pero su uso masivo sí. En los últimos años, la combinación de IA + infraestructura cloud —lo que muchos llaman “IA en la nube”— se hizo ubicua: modelos de lenguaje como servicio, APIs de embeddings, RAG gestionados, etc.

El paso a herramientas como ChatGPT, Claude, Gemini y compañía fue bastante natural para la mayoría de desarrolladores. Funcionan como un “súper buscador” y un autocompletado muy potente que ayuda con tareas cotidianas: escribir código, documentar, depurar ideas y automatizar partes repetitivas del trabajo.

Mientras el uso se queda en consulta y experimentación, todo bien.

Cuando la IA deja de ser un juguete

El problema aparece cuando dejamos de usar la IA solo como asistente/buscador y empezamos a integrarla como componente central de proyectos serios:

Orquestadores de procesos críticos
Sistemas RAG sobre corpus privados
MCPs o agentes que coordinan servicios internos
Automatización de flujos de desarrollo y operación

En ese punto las preguntas cambian:

¿Hasta qué nivel es razonable que el backend, el know‑how y los datos sensibles dependan de un servicio de terceros?
¿Qué tanto control real tenemos sobre dónde se procesan los datos, quién puede auditarlos y cómo se reutiliza el contenido enviado?
¿El modelo o proveedor puede aprender de nuestros prompts, código y documentación interna, directa o indirectamente?

Y, sobre todo: ¿estamos dispuestos a que alguien pueda replicar capacidades similares pagando la misma suscripción de 20, 50 o 100 USD/mes?

No es solo un tema técnico; es estratégico.

Mis dos dolores: costos y control

En mi caso, hubo dos factores que me hicieron poner el freno:

Costos variables difíciles de predecir.

En escenarios de uso intensivo (equipos pequeños pero muy activos, pipelines que llaman a modelos muchas veces al día, pruebas, iteración rápida, etc.) la factura por tokens puede crecer más rápido de lo esperado.
Pérdida de control.

No tener claridad plena de dónde, cuándo y cómo se usa lo que envío a un proveedor externo, ni poder auditar la infraestructura de punta a punta, no es precisamente tranquilizador cuando trabajas con lógica de negocio o datos delicados.

A partir de ahí empecé a experimentar con IA local.

Explorando IA local en entornos moderados

No tengo todavía una solución “perfecta”, pero ya tengo modelos corriendo en máquinas locales con recursos moderados (lo que podríamos llamar “dev boxes vitaminadas” o servidores modestos on‑premise).

Al mismo tiempo, empecé a ver un patrón interesante: empresas muy grandes están reconsiderando el modelo todo en la nube para ciertos casos de uso. No hablo del consumo consultivo (usar modelos públicos para buscar, resumir o prototipar, que probablemente seguirá así mucho tiempo), sino del core de los procesos internos:

Orquestadores de procesos de negocio
Sistemas RAG sobre documentación corporativa
MCP y agentes que tocan infraestructura sensible
Automatización de workflows que representan ventaja competitiva

Para este tipo de escenarios, empiezan a reaparecer conceptos como:

Stand‑alone y on‑premise para la capa de IA crítica
Redes locales aisladas para desarrollo y pruebas internas
Modelos propios o afinados en casa sobre hardware dedicado

Hardware y ecosistema: el péndulo vuelve

El ecosistema de hardware y frameworks está empujando esta tendencia:

Fabricantes como NVIDIA, Qwen y otros proveedores están ofreciendo modelos y soluciones pensadas para ejecutarse on‑premise o en nubes privadas.
Surgen chips específicos para aceleración de IA (tipo Willow y equivalentes) que bajan la barrera de entrada para ejecutar modelos grandes localmente.
Incluso la computación cuántica empieza a asomar como otra capa futura de cómputo especializado.

No es barato todavía. Estar hablando de máquinas alrededor de 4.000 USD o más sigue siendo una inversión seria. Pero son los albores de un cambio: muchas laptops y PCs podrían modificar drásticamente su rol y su patrón de conectividad, pasando de “terminales tontas de la nube” a nodos de cómputo de IA mucho más autónomos.

Modelos asistidos encapsulados: sin lenguaje de programación explícito

En mi caso particular, he venido experimentando con un enfoque algo distinto a la programación “clásica”:

Uso modelos de programación asistida encapsulados;
No expongo directamente un lenguaje de programación tradicional en cada caso de uso;
En su lugar, defino cápsulas generativas que saben ejecutar procesos:
- Siempre repetitivos
- Deterministas (0 grados de libertad en tiempo de ejecución)
- Basados en un schema y un stack síncrono bien definido

La idea es algo así:

Defino qué proceso quiero (contrato, entradas, salidas, restricciones).
Defino cómo debe orquestarse (pasos, dependencias, reglas de validación).
La cápsula genera y ejecuta la lógica necesaria, pero la interfaz para mí no es un IDE tradicional ni un framework enorme, sino una configuración estructurada.

Esto me ha permitido avanzar más rápido en algunos proyectos porque:

Me concentro en el diseño del proceso y la semántica, no en detalles de framework o API de bajo nivel.
Las correcciones se vuelven cambios de contrato/configuración en lugar de grandes refactors de código disperso.
El entorno se mantiene encapsulado y controlado (sin “copiar y pegar” media base de código en un prompt público).

No es magia ni “soluciona todo”, pero abre un espacio interesante entre “puro código” y “puro prompt”.

La pregunta incómoda: ¿qué tan expuesto quieres estar?

No pretendo vender esto como la solución definitiva. La nube sigue teniendo ventajas enormes: elasticidad, gestión simplificada, ecosistema, servicios administrados, etc.

Pero sí quiero dejar planteada una pregunta que, como ingeniero o arquitecto, tarde o temprano tendrás que responder:

¿Qué tan conveniente es que el desarrollo de tus proyectos críticos,
asistidos por IA, dependa de servicios que pagas “por token”,
exponiendo a la vez tu billetera y, sobre todo,
tu conocimiento y lógica de negocio a una infraestructura pública de terceros?

Tal vez la respuesta siga siendo “cloud first” para muchos casos.

Tal vez, para otros, sea el momento de volver a mirar con cariño el stand‑alone y el on‑premise… pero esta vez con IA dentro.

Grace Hopper, COBOL y la vieja aspiración de hablarle a las máquinas

Carlos Arturo Castaño G. — Sat, 11 Jul 2026 16:38:19 +0000

Desde que las personas comprendieron que las máquinas podían ser programadas para cumplir funciones específicas, siempre ha existido interés en cómo comunicarse con ellas. A lo largo del tiempo se han desarrollado iniciativas, técnicas y medios para facilitar esa comunicación.

Cuando surgieron las primeras computadoras capaces de procesar grandes cantidades de datos mediante métodos numéricos, el interés por avanzar en formas de programación aumentó. En un principio, los lenguajes y las herramientas estaban al alcance de muy pocas personas: eran técnicas especializadas dominadas por expertos que, en muchos casos, mostraban resistencia a su divulgación. Programar una máquina era entonces una tarea compleja y casi esotérica.

Desde siempre hubo la inquietud de que cualquier persona debería poder comunicarse de forma más sencilla con las máquinas. Esa aspiración llevó a la creación de lenguajes más accesibles —incluso si antes la comunicación había sido por señales o sistemas no verbales. Una figura clave en ese proceso fue Grace Hopper. Oficial de la Marina de Estados Unidos y pionera en computación, Hopper desarrolló un lenguaje de instrucciones en inglés comprensible para humanos que la máquina, que sólo entendía binario, podía ejecutar.

Hopper creó un lenguaje en palabras inglesas y consiguió que una máquina entendiera y ejecutara órdenes en lenguaje natural. Pero convertir una idea en algo aceptado fue difícil: siendo mujer, militar y trabajando en los años cincuenta y sesenta, enfrentó obstáculos, resistencias y hasta persecución profesional. Aun así, su determinación le permitió alcanzar cargos relevantes en una época dominada por hombres.

El lenguaje que desarrolló terminó llamándose COBOL (Common Business-Oriented Language, Lenguaje Común Orientado a Negocios). Tras numerosas luchas, su propuesta fue aceptada y COBOL se convirtió en el estándar para programas de negocios. Décadas después sigue siendo fundamental en la banca y los seguros; numerosos intentos —con Java, C++ y otros lenguajes— no han logrado reemplazarlo en muchos sistemas críticos.

Un problema actual es que los programadores expertos en COBOL están en retirada: se han jubilado o han fallecido, y quedan pocos especialistas dispuestos a intervenir en esos sistemas. Los expertos disponibles suelen cobrar sumas elevadas por evaluaciones o ajustes, incluso en cambios menores.

Lo llamativo de COBOL es su sencillez: la idea de comunicarse con una máquina mediante un lenguaje cercano al humano no es nueva; tiene décadas de antigüedad. El reciente interés en herramientas como ChatGPT ha reavivado ese interés, pero no implica que la concepción sea novedosa. En sectores donde importa el funcionamiento del mundo real —como el dinero y las transacciones bancarias— muchos sistemas siguen dependiendo de COBOL. Por eso la idea de conversar con máquinas no nació ayer, y el mundo no se vino abajo con la aparición del COBOL de Grace Hopper.

La inteligencia artificial no te reemplazará… pero alguien que la use sí

Carlos Arturo Castaño G. — Wed, 08 Jul 2026 18:11:16 +0000

Con la llegada de la inteligencia artificial (IA), se ha especulado mucho sobre sus repercusiones en distintos ámbitos, como la política, la economía y la religión. Sin embargo, todas estas discusiones convergen en un punto central: el impacto de la IA en el empleo y la preocupación que genera la desaparición de ciertos trabajos y el consecuente desempleo.

En varias ocasiones he abordado este tema en mi blog, señalando que, aunque la IA despierta suspicacia y temor —y con razón, dado su impacto en la vida cotidiana—, su influencia es un fenómeno inevitable que se hace más evidente cada día.

Como ocurre con todos los cambios que alteran la normalidad de las personas, sus repercusiones pueden manifestarse de manera gradual o de forma abrupta y disruptiva. No obstante, el cambio es una constante en la historia de la humanidad, desde la invención de la rueda hasta las distintas revoluciones tecnológicas que han transformado nuestra forma de vivir y trabajar.

El fin del conocimiento enciclopédico como ventaja

Durante siglos, nuestra sociedad ha estado basada en el conocimiento enciclopédico, es decir, en la acumulación de información para tomar decisiones fundamentadas en datos, reglas y fórmulas. Este conocimiento reside en libros, documentos y bases de datos, y hasta ahora, los profesionales han accedido a él principalmente a través de la memorización o la consulta de referencias.

Sin embargo, con el auge de la IA, gran parte de ese conocimiento ya está almacenado en sus bases de datos. Algunos consideran esto un problema, pues creen que la IA ya no tiene nada más que aprender. Para seguir evolucionando, las nuevas generaciones de IA deben generar su propio conocimiento, lo que genera inquietud en muchos sectores.

En consecuencia, el almacenamiento de información por parte de los profesionales está perdiendo relevancia. La aplicación de conocimientos enciclopédicos ya no es una prioridad, dado que cualquier dato está a solo un clic de distancia.

Esto nos lleva a una pregunta clave: ¿cómo cambia nuestra perspectiva profesional ante esta realidad?

El nuevo valor profesional: buscar y aplicar

Muy pronto, los profesionales deberán replantear su forma de pensar, actuar e integrar sus servicios a la sociedad. Su valor no residirá únicamente en el conocimiento que poseen, sino en su capacidad para utilizar criterios de búsqueda eficaces que les permitan encontrar, filtrar y aplicar la información más pertinente según cada necesidad.

Carreras como medicina, derecho, educación, sistemas, finanzas y contabilidad se verán profundamente impactadas. Aunque la información estará al alcance de cualquiera con conocimientos básicos, serán los profesionales altamente preparados en la nueva ciencia de la "búsqueda precisa y pertinente" quienes afrontarán los desafíos del futuro.

Los prompts como la nueva alfabetización digital

En este sentido, la habilidad para interactuar con IA mediante prompts efectivos ya no debe verse como una amenaza, sino como una herramienta esencial para el desempeño profesional. Así como en su momento lo fueron Excel y Word, dominar el lenguaje de comunicación con la IA será una competencia fundamental en el mundo laboral del futuro.

Es crucial estar alineado con la tendencia global en la educación y el mercado laboral. Empresas líderes en tecnología y consultoría ya están enfatizando la capacidad de resolver problemas sobre la memorización de datos. Modelos de educación como el aprendizaje basado en competencias (competency-based learning) buscan precisamente formar profesionales que sepan navegar en un entorno de información abundante.

Ejemplos por profesión

En sectores como la medicina, la IA ya está mejorando el diagnóstico de enfermedades, pero el juicio clínico sigue en manos de los médicos. En derecho, la IA puede analizar grandes volúmenes de jurisprudencia, pero la estrategia legal sigue dependiendo de los abogados. El desafío radica en integrar la IA como un aliado en el ejercicio profesional, en lugar de verla como un reemplazo.

Actualmente, disciplinas como el prompt engineering (ingeniería de prompts) están ganando relevancia en el ámbito tecnológico. Profesionales con la habilidad de interactuar eficazmente con modelos de IA tienen una ventaja competitiva. En un futuro cercano, no se tratará solo de qué sabes, sino de qué tan bien puedes encontrar y aplicar el conocimiento disponible.

Profesionales que se especialicen en la optimización y aplicación de la IA tendrán una ventaja competitiva en el mercado laboral. La educación y la formación deberán cambiar para priorizar la capacidad de análisis y filtrado de información sobre la simple acumulación de datos.

Dónde estamos hoy

De momento nos encontramos dando los primeros pasos en la exploración de estas tecnologías en labores muy simples como creación de imágenes, videos, música y mejora y corrección de texto. Pero el grueso de la innovación pienso que va a ser la búsqueda aplicada y la toma de decisiones asistida.

Cómo la IA está cambiando nuestros diálogos y relaciones, no solo nuestro trabajo

Carlos Arturo Castaño G. — Wed, 08 Jul 2026 18:04:45 +0000

La inteligencia artificial (IA) ha dejado de ser una promesa futurista para convertirse en una realidad que transforma de manera profunda la vida cotidiana de las personas. Su influencia se extiende desde la automatización de tareas rutinarias hasta la manera en que nos comunicamos, gestionamos expectativas y nos relacionamos con seres queridos, parejas y amigos.

Efectos en la vida cotidiana y los diálogos

La IA ha revolucionado la vida diaria principalmente a través de la automatización eficiente de procesos y la personalización de experiencias. En el ámbito empresarial y doméstico, tareas repetitivas como la gestión de datos o la atención al cliente ahora pueden ser realizadas por sistemas inteligentes, liberando tiempo para actividades más creativas y estratégicas. Además, los algoritmos de IA analizan patrones de comportamiento para ofrecer recomendaciones y respuestas personalizadas, lo que mejora la experiencia del usuario en plataformas digitales.

En cuanto a los diálogos, el cerebro humano reacciona de manera distinta cuando interactúa con una IA en comparación con una persona. Las conversaciones humanas requieren atención plena, sincronía emocional y adaptabilidad, activando múltiples redes cerebrales responsables de interpretar gestos, tonos y emociones. En contraste, al hablar con una IA, el patrón cerebral cambia, ya que la interacción carece de la riqueza emocional y la complejidad de la comunicación humana. Esto puede llevar a una experiencia de diálogo más funcional, pero menos profunda emocionalmente.

Expectativas diarias y percepción social

Las expectativas sobre la IA deben ser realistas: aunque promete resolver problemas complejos y optimizar recursos, su impacto es gradual y continuo. La sociedad espera que la IA mejore sectores como la salud, la educación y el medio ambiente, pero también surgen preocupaciones éticas y sociales, como la equidad en el acceso y el riesgo de aumentar las desigualdades. La percepción social hacia la IA está fuertemente ligada a la importancia que se le otorgue a la ética en su desarrollo y aplicación.

Relación con seres queridos, pareja y amistad

En el entorno familiar, la IA plantea retos y oportunidades. Puede enriquecer la vida familiar facilitando la comunicación y la gestión del hogar, pero también genera interrogantes éticos sobre la protección de la intimidad y la preservación de los valores humanos fundamentales, como el respeto y el amor incondicional. La tecnología debe ser una herramienta que potencie la unidad y no una amenaza para la calidad de las relaciones humanas.

En las relaciones de pareja y amistad, la IA puede mejorar la comunicación mediante herramientas de traducción, corrección y sugerencias, especialmente en contextos interculturales o con barreras lingüísticas. Los asistentes virtuales ayudan en la búsqueda de compatibilidad y ofrecen recomendaciones personalizadas, mientras que los chatbots pueden proporcionar apoyo emocional en momentos de soledad o dificultad. Sin embargo, la IA no puede reemplazar la empatía y la conexión genuina que solo las relaciones humanas pueden ofrecer.

Conclusión

La inteligencia artificial está transformando la vida cotidiana en múltiples dimensiones: desde la eficiencia en tareas diarias hasta la manera en que nos comunicamos y relacionamos. Si bien aporta beneficios notables, también exige una reflexión ética y un equilibrio entre la tecnología y la humanidad. El desafío está en aprovechar su potencial sin perder de vista la importancia de las conexiones humanas auténticas.

Referencias

Aldeamo. El Impacto de la Inteligencia Artificial en la Vida Cotidiana.
El Colombiano. ¿Se habla igual con una IA que con una persona? Esto pasa en el cerebro.
IA España. Las expectativas de la IA hacia la humanidad.
RUC. Inteligencia Artificial: un estudio de su impacto en la sociedad.
Milenio. Inteligencia artificial y Familia.
IA UAMA. El papel de la inteligencia artificial en el amor y la amistad.

Blockchain, Smart Contracts y NFTs: ¿son la única alternativa de seguridad?

Carlos Arturo Castaño G. — Wed, 08 Jul 2026 17:55:18 +0000

Por estos días, las personas de sistemas andan de moda con la seguridad de blockchain, los smart contracts y los NFTs. Pero, ¿son estas las únicas alternativas?

Es cierto que están muy de moda, especialmente entre la gente de sistemas, pero definitivamente no son las únicas alternativas ni la solución para todos los problemas de seguridad. Ofrecen un conjunto de propiedades muy particulares, pero hay un vasto ecosistema de tecnologías y enfoques de seguridad que son equivalentes o incluso superiores para ciertos casos de uso.

Lo que blockchain, smart contracts y NFTs ofrecen

Blockchain (cadena de bloques):

Inmutabilidad: una vez registrado un dato, es extremadamente difícil alterarlo. Ideal para auditoría, registros de transacciones, cadenas de suministro.
Descentralización: sin punto central de falla o control único, reduciendo el riesgo de censura o manipulación por una sola entidad.
Transparencia (en cadenas públicas): transacciones visibles para todos los participantes.
Trazabilidad: fácil seguir el rastro de un activo o transacción a lo largo del tiempo.

Smart contracts (contratos inteligentes):

Automatización y autoejecución: se ejecutan solos cuando se cumplen condiciones predefinidas, sin intermediarios.
Determinismo y confianza trustless: comportamiento predecible e inmutable una vez desplegados. La confianza está en el código, no en una persona.
Verificabilidad: código público (en cadenas públicas), auditable.

NFTs (tokens no fungibles):

Propiedad digital única: método verificable para probar propiedad de activos digitales únicos.
Autenticidad: permiten rastrear el origen de un activo digital.

¿Son las únicas alternativas? No.

Muchas de estas propiedades se pueden lograr o complementar con otras tecnologías, a menudo más maduras y con menor complejidad o consumo de recursos.

Para inmutabilidad y verificación de integridad

Criptografía tradicional (hashing y firmas digitales): un hash (SHA-256) es la huella digital de un archivo; si cambia el archivo, cambia el hash. Las firmas digitales garantizan origen y no alteración. Es la base de la inmutabilidad de blockchain, pero se usa independientemente sin necesidad de una cadena de bloques completa.
Merkle Trees: usados dentro de blockchains, también sirven de forma independiente para verificar eficientemente la integridad de grandes conjuntos de datos.
Bases de datos inmutables / solo-añadir (Apache Kafka, Amazon QLDB): historial de transacciones auditable sin la complejidad de una blockchain distribuida.

Para descentralización y confianza distribuida

Identidad federada y auto-soberana (SSI): da al usuario control sobre su identidad digital mediante DIDs (Decentralized Identifiers) y VCs (Verifiable Credentials), que no siempre requieren blockchain pública.
DPKI: evolución de la PKI tradicional hacia gestión descentralizada de certificados y claves.
Consenso distribuido (Paxos, Raft): acuerdo entre múltiples nodos a pesar de fallas, fundamental en bases de datos distribuidas y microservicios, sin ser blockchains.

Para privacidad y verificación sin revelar información

Zero-Knowledge Proofs (ZKP): probar que se conoce un secreto sin revelarlo. Se usan con o sin blockchain (ej. ZCash).
Cifrado homomórfico: cálculos sobre datos cifrados sin descifrarlos primero. Útil en computación en la nube privada y análisis de datos sensibles.
Secure Multi-Party Computation (MPC): múltiples partes calculan conjuntamente una función sobre entradas privadas sin revelarlas entre sí.

Para protección y resiliencia del sistema

Trusted Execution Environments (TEEs): enclaves seguros basados en hardware (Intel SGX, ARM TrustZone), protegen código y datos aunque el resto del sistema esté comprometido.
IA/ML para ciberseguridad: análisis de comportamiento, detección de anomalías, respuesta automatizada a amenazas.
DevSecOps / SOAR: seguridad integrada en cada etapa del ciclo de vida del desarrollo, con respuesta automatizada a incidentes.
SASE: modelo convergente de red + seguridad en la nube para asegurar acceso desde cualquier lugar.

Conclusión

Blockchain, smart contracts y NFTs son herramientas innovadoras, especialmente donde la confianza descentralizada y la inmutabilidad de registros públicos son críticas: registros de propiedad, trazabilidad de cadena de suministro, sistemas de votación, identidad digital auto-soberana.

Pero para desafíos de seguridad tradicionales —protección de datos en reposo/tránsito, autenticación, autorización de acceso, detección de malware, prevención de DDoS— las soluciones maduras y especializadas (criptografía clásica, firewalls, SIEM, WAFs, EDR, TEEs) siguen siendo los pilares fundamentales, y a menudo son más eficientes y escalables.

La clave está en entender el problema de seguridad específico y elegir la tecnología más adecuada — que puede ser blockchain, pero también una de las muchas alternativas o una combinación de varias.

Referencias

Ospina Navas, J. (2023). Blockchain y ciberseguridad: fortaleciendo la confianza digital. Escuela Superior de Guerra "General Rafael Reyes Prieto". DOI
Telefónica (2022). Los NFTs y su relación con el blockchain
Brunner et al. (2023). Elementos de Seguridad para Gestión Documental con Blockchain. SciELO
López, P. (2025). Análisis de Alternativas de Seguridad Basadas en Criptografía y Mejores Prácticas
MiniOrange (2024). ¿Cómo la identidad autosoberana transformará la verificación de identidad digital?
Protección Datos LOPD (2024). Zero-Knowledge Proof: ¿Qué es y cómo funciona?
Pure Storage (2023). ¿Qué es una copia de seguridad inmutable?

La mentalidad para programar sistemas

Carlos Arturo Castaño G. — Wed, 08 Jul 2026 17:44:08 +0000

Hoy en día hay un gran interés por la programación, especialmente en aprender lenguajes de moda como Python, C++, HTML, JavaScript o en usar herramientas "no code". Sin duda, cualquier conocimiento que adquieras en este campo te aporta una visión más amplia del mundo y sus oportunidades.

Sin embargo, embarcarse en el desarrollo de software para empresas o proyectos a gran escala es un tema muy diferente. No basta con "manejar" una herramienta a nivel básico; se necesita estar verdaderamente calificado para afrontar retos complejos.

La diferencia está en la mente

El mayor desafío al programar no es necesariamente saber un lenguaje o una herramienta, sino algo que va más allá de simplemente "tirar líneas de código". Se trata de desarrollar una forma de pensar clara y metódica. Es decir, adquirir un "patrón de pensamiento" que nos permita enfrentarnos a un problema de forma coherente y estructurada.

Los seres humanos entendemos el mundo a través de patrones. Tendemos a ser reduccionistas: comprendemos mejor una propuesta o un proyecto si podemos encajarlo en un modelo que ya conocemos. Por eso, en programación es crucial conocer o crear patrones mentales que nos guíen a través de aguas turbulentas.

Aclarando tres conceptos que se confunden

1. Sistematizar. No tiene nada que ver con computadoras o lenguajes de programación. Sistematizar es simplemente "organizar algo" (datos, procesos, objetos) de manera ordenada, lógica y repetible. Puede ser la forma de apilar cajas en un almacén, organizar documentos en una carpeta o clasificar información en una hoja de cálculo.

2. Crear un sistema. Una vez tienes claro "cómo" y "para qué" quieres organizar algo, buscas la herramienta que mejor se adapte a esa necesidad. La programación es solo una de las muchas herramientas posibles. La elección depende de una comprensión exhaustiva del problema a resolver.

3. Programar. Este es el último paso en la cadena. Es la implementación práctica, lo que en el argot se llama "tirar líneas". Solo después de entender el problema y diseñar el sistema, decides el lenguaje (Python, Java, C++, etc.), el entorno de desarrollo y si lo harás manualmente, con ayuda de IA o usando una herramienta no code.

El flujo queda claro: ¿Qué? → ¿Cómo? → ¿Con qué? Esto da una idea de los recursos necesarios (sistema operativo, bases de datos, etc.) antes de escribir la primera línea de código.

Encontrando tu propio patrón de pensamiento

Dado que nuestra mente trabaja naturalmente con patrones, es fundamental encontrar una guía mental que nos permita diseccionar problemas de forma clara y coherente.

Quiero compartir el modelo que a mí me ha dado buenos resultados. Al principio, abordaba cada problema como si fuera completamente nuevo. Con el tiempo, noté que la mayoría compartía un patrón repetitivo, pero no lograba identificarlo con claridad.

El sistema contable como modelo mental

Todo cambió cuando tuve que programar un sistema contable básico. Como ingeniero, yo menospreciaba la contabilidad, pero al adentrarme en ella, descubrí una estructura hermosa, sólida y precisa. La contabilidad es, en esencia, un "sistema" en su definición más pura: se basa en cuentas claras, jerárquicas e inmutables. Hay una cuenta para casi cualquier cosa que puedas imaginar, y si no existe, la creas y la ordenas dentro de una jerarquía.

Me di cuenta de que, por ejemplo:

Un programa de facturación es básicamente un movimiento entre la cuenta de ventas y la de inventario.
Cualquier sistema de cartera (lo que te deben o debes) se puede entender como una cuenta por cobrar.
Los métodos de pago se manejan como una cuenta de "Caja y Bancos".
Todo es un débito o crédito — activo/pasivo.

Para mi patrón mental, cualquier sistema puede entenderse como una "cuenta" en un gran plan contable, donde siempre hay algo que entra, algo que sale o algo que se acumula (débito/crédito o pasivo/activo). Esto puede aplicarse a dinero, movimiento, energía, tráfico, personas... a casi cualquier cosa. Años después, confirmé esta idea cuando surgió el blockchain, que funciona como un libro de contabilidad digital descentralizado.

Para cerrar

Quiero dejar claro que no estoy diciendo que todo programador deba usar la contabilidad como modelo. Lo esencial es que cada uno encuentre su propio patrón elaborado, claro y preciso. Este es un paso enorme en el desafío de la programación.

Si eres capaz de visualizar en tu cabeza cómo organizar y clasificar un proceso de forma eficiente y segura, la elección del lenguaje, la interfaz o la tecnología será una consecuencia natural, un simple añadido a una base sólida, no al revés.

Te animo a hacer una pausa y a buscar tu propio modelo de pensamiento. Esa introspección es lo que realmente te preparará para los retos de la programación de sistemas.

Si no entiendes algo, no lo vas a poder programar.

Elige tu stack por afinidad, no por moda

Carlos Arturo Castaño G. — Wed, 08 Jul 2026 17:36:20 +0000

Cuando tuve mi primer contacto con IA, hace ya como 12 o 15 años, era algo muy académico, científico decían algunos, y era más que todo para resolver problemas relacionados con mejorar el audio, identificación de imágenes mediante Python, reconocimiento de movimiento; es decir, algo muy especializado y además puntual que requería altas dosis de paciencia y profundo conocimiento de redes neuronales. El término IA no estaba enmarcado en el contexto actual.

La inteligencia artificial era en sí misma, por decirlo de alguna manera, el cableado de un cerebro informático. En ese entonces, no requerías solo conocer a fondo el problema en sí, sino además la herramienta a usar, que no siempre era la misma dependiendo del caso. Abordar estos temas era, cuando menos, un reto y uno grande.

Lo que hoy llamamos IA es otra cosa

Con el advenimiento de lo que las personas actualmente conocen como IA —que en realidad es la aplicación de interfaces de usuario para tener acceso a redes neuronales (soy consciente de que es una simplificación grande)—, se facilita la iteración de procesos avanzados de procesamiento de información.

Los chatbots, los agentes y toda la gama de soluciones creadas alrededor de las redes neuronales cumplen su función de facilitar el acceso a esas herramientas: manejo de imágenes, vídeo, texto, generación, validación y mejora de redacción. Todo esto perfectamente válido.

El estrés de la actualización permanente

Al haber tanta diversidad en las propuestas que se actualizan día a día, se genera mucha carga y estrés en esa sensación de "me estoy quedando atrás", porque cada día sale la mega súper ultra propuesta. Es frustrante, sobre todo porque en general las personas no son expertos informáticos y no tienen tiempo para seguirle el paso a tantas opciones y funcionalidades que, en algunos casos, no son tan triviales.

Yo también estuve en ese paradigma del día a día, y nunca me sentía actualizado, hasta que un día decidí parar y me dije: "Mi trabajo es programar y prestar asesoría, no explorar cada cosa que sale. No tengo tiempo para eso". Y tomé una decisión: explorar las herramientas que más afines me parecieran a mi concepción de su uso y prestaciones, no necesariamente las últimas ni las mejores, solo las que a mi juicio sintiera más cómodas para mí en los diferentes usos.

Mi lista de opciones (no un ranking, solo lo que me funciona)

OpenAI: uso general, consultas, generación de prompts general y revisiones de texto.
Perplexity: consultas más profundas, documentadas y con referencias cruzadas, para material académico o de sustentación y presentación de proyectos.
Leonardo AI: creación y manipulación de imágenes y vídeo.
DeepSeek: consulta y validación de información, casi siempre para contrastar lo obtenido con OpenAI.
Gemini: primer acercamiento a mis desarrollos de sistemas; en ocasiones lo contrasto con Copilot.
Claude (Anthropic): ajustes y sistemas de prueba en mis desarrollos de sistemas y programas.

Los copilotos para programar los uso poco, más que todo porque mis desarrollos ya los tengo bastante depurados en base a prompts precisos y pormenorizados al detalle. Pulir esos prompts ha sido un proceso paulatino, resultado de verificación, corrección y prueba en las interfaces, bases de datos, integraciones RESTful. Porque si algo tengo claro con el uso de la IA, es que lanzar una idea más o menos general de lo que se quiere normalmente no suele ser buena idea — a menos que se tenga claro que es un mero acercamiento al proyecto.

Un ejemplo concreto de mi flujo

Este mismo texto lo redacté y luego lo pasé por Perplexity, con este prompt que uso habitualmente para que el resultado se alinee a mi estilo de redacción y no me genere una versión "posiblemente mejorada" pero que ya no es mi voz — en eso soy celoso, no quiero artículos que suenen salidos de fábrica:

Corrección de sintaxis, separaciones, punto seguido, comillas,
punto y coma, y punto aparte, insertar una línea de salto de
renglón si es necesario, no cambiar la idea original, mejorar
fluidez solo si la idea es confusa, y mostrar la versión
original y la cambiada de forma independiente.

En resumen

Si usted es un usuario promedio, elija la IA que más le guste y trabaje con esa. En general todas cumplen los requerimientos para las tareas convencionales.

La IA no crea lo que tú no sabes

Carlos Arturo Castaño G. — Tue, 07 Jul 2026 17:48:21 +0000

# Una confesión después de 5 meses de enseñar y programar con asistentes inteligentes

Tengo una regla personal: nunca uses algo complejo si puedes hacerlo sencillo.

Suena obvio, pero en el mundo de la programación parece una herejía. Hay una presión constante por usar el framework de moda, la arquitectura más distribuida, el lenguaje más trendy.

Y ahora, con la IA, la presión se multiplica. "La IA te va a reemplazar", "La IA hace código mejor que tú", "Si no usas IA te quedas atrás".

Llevo meses programando con IA. Probando OpenCode, Hermes, OpenDesign. Y he llegado a una conclusión incómoda:

La IA no crea lo que tú no sabes.

El mito de la IA creadora

Hay una idea errónea de que la IA es una especie de maga que genera soluciones desde la nada. Que puedes pedirle cualquier cosa y ella te dará el código perfecto.

No es así.

La IA es un predictor estadístico. Genera lo que es más probable basado en lo que ha visto. Si le pides algo complejo, te va a dar algo que parece complejo, pero que puede estar lleno de errores, de malas prácticas, de suposiciones incorrectas.

Y aquí está el problema: solo puedes detectar esos errores si ya sabes lo que estás buscando.

Si no sabes cómo funciona un fetch, no vas a notar que la IA está manejando mal los errores de red. Si no entiendes Java Beans, no vas a ver que está violando principios básicos de encapsulamiento. Si no conoces MongoDB en profundidad, no te darás cuenta de que la consulta que generó va a explotar en producción.

La IA no te da conocimiento. Te da código. Y el código sin conocimiento es peligroso.

Mi stack simple: Por qué no necesito más

Uso Nginx como proxy. Tomcat como servidor de aplicaciones. MongoDB como base de datos. Java con Beans. JavaScript vainilla con Fetch API. ES6 para mantenerlo limpio.

Nada de Spring Boot. Nada de React. Nada de microservicios. Nada de 50 dependencias en un package.json.

¿Por qué?

Porque cuando la IA me genera algo, puedo leerlo completo. Puedo entender cada línea. Puedo saber si está haciendo algo extraño. Puedo depurarlo sin tener que aprender una capa de abstracción nueva.

Un stack simple es un stack depurable. Y en la era de la IA, la depuración es más importante que la generación de código.


java
// Ejemplo: Un bean simple en Java
// La IA puede generar esto, pero ¿entiendes por qué?
public class UsuarioBean {
    private String id;
    private String nombre;
    private String email;

    public UsuarioBean() {}

    public String getId() { return id; }
    public void setId(String id) { this.id = id; }

    public String getNombre() { return nombre; }
    public void setNombre(String nombre) { this.nombre = nombre; }

    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }
}

// Si no entiendes Java Beans, la IA te puede generar algo que funcione
// pero que no siga las convenciones del framework que estás usando.
// Y cuando falle, no sabrás por qué.

**El vendedor de humo: La urgencia fabricada**
Hay un negocio que me enferma: el de crear urgencia.

"Si no aprendes IA ahora, te quedas sin trabajo en 6 meses."

"Si no compras mi curso de Python en 21 días, nunca serás programador."

"Si no usas este framework, tu código es obsoleto."

Es mentira. Todo es mentira.

La programación no es una carrera de 100 metros. Es una maratón. Y los que corren con urgencia, los que toman atajos, los que compran soluciones rápidas, son los primeros en quemarse y en fracasar.

Mi asistente lleva 5 meses aprendiendo conmigo. Es excelente. Estudioso. Motivado. Y aún así, no está listo.

¿Y sabes qué? Eso está bien.

No tiene que estar listo en 21 días. No tiene que ser senior en 6 meses. Tiene que construir cimientos sólidos. Tiene que equivocarse. Tiene que preguntar. Tiene que frustrarse y volver a intentarlo.



Nunca, nunca, le pido  ala IA que resuelva algo que yo no entiendo. Porque si no entiendo el problema, no puedo evaluar la solución.

// Cómo uso la IA en mi día a día
// 1. Le pido que me genere un mapper
// 2. Reviso que el mapper cumpla con la lógica de negocio
// 3. Lo ajusto si es necesario
// 4. Lo integro

// La IA genera esto:
const mapUsuario = (data) => ({
  id: data._id,
  nombreCompleto: `${data.nombre} ${data.apellido}`,
  email: data.correo?.toLowerCase() || 'sin-email'
});

// Yo reviso y sé que:
// - Si data._id no existe, va a fallar
// - Si data.correo es null, el optional chaining lo maneja
// - El operador || da un valor por defecto
// - La lógica de negocio está correcta

El valor del stack simple con IA
¿Por qué insisto tanto en la simplicidad del stack?

Porque la IA funciona mejor cuando el dominio es pequeño y bien definido.

Si usas un stack simple:

La IA tiene menos "ruido" en su contexto.

Genera código más predecible.

Es más fácil verificar lo que genera.

El código generado es más fácil de mantener por humanos.

Si usas un stack complejo:

La IA alucina más a menudo.

Genera código que depende de bibliotecas que quizá no tienes.

Es más difícil saber si lo que generó es correcto.

El código generado es más difícil de mantener sin el framework.

Una invitación a la honestidad
Si estás empezando, te invito a ser honesto contigo mismo:

¿Quieres aprender rápido o quieres aprender bien?

¿Quieres copiar código o quieres entenderlo?

¿Quieres vender humo o quieres construir cosas reales?

Si eliges lo segundo, acepta que va a tomar tiempo. Acepta que vas a sentirte tonto muchas veces. Acepta que la IA no es una varita mágica.

Pero también acepta que, cuando finalmente entiendas algo, nadie te lo va a quitar. Y que ese conocimiento, construido con paciencia, vale más que 100 cursos de 21 días.

La verdad que nadie cuenta
La industria tech está llena de vendedores de humo. Gente que gana dinero vendiendo la ilusión de que aprender a programar es fácil y rápido.

¿La verdad?

Programar es difícil. Es frustrante. Es lleno de momentos en los que quieres tirar la computadora por la ventana.

Pero también es maravilloso. Es creativo. Es resolver puzzles todo el día. Es ver cómo algo que existía solo en tu cabeza se convierte en realidad.

Y eso, lo difícil y lo maravilloso, solo se logra con tiempo.

No con cursos de 21 días. No con prompts mágicos de IA. No con frameworks que prometen hacerlo todo.

Con tiempo. Con práctica. Con errores. Con paciencia.

Lo que viene
Seguiré escribiendo sobre mi experiencia. Sobre lo que funciona y lo que no. Sobre los errores que cometo y los que veo cometer. Sobre la IA, los stacks simples y la honestidad intelectual.

No prometo ser el más popular. Prometo ser el más honesto.

Si llegaste hasta aquí, gracias por leer.

¿Cuánto tiempo llevas programando? ¿Qué es lo que más te ha costado aprender? ¿Has sentido alguna vez que te vendieron humo con un curso exprés?

Comparte tu historia. Quiero leerte.

Mi asistente lleva 5 meses aprendiendo a programar conmigo y aún NO sabe programar

Carlos Arturo Castaño G. — Tue, 07 Jul 2026 17:02:22 +0000

Esto es lo que los vendedores de cursos no quieren que sepas.

Hace 5 meses tomé una decisión que cambió mi perspectiva sobre la enseñanza de la programación. Un chico llegó a mi equipo como asistente. Sin experiencia previa. Con muchas ganas. Con una motivación que envidio.

Y yo, que nunca había enseñado a nadie, me comprometí a transmitirle todo lo que sé. Con paciencia. Con mi "dialéctica de pensamiento", como me gusta llamarle. Sin filtros. Sin atajos.

Hoy, 5 meses después, puedo decir algo que quizá suene duro:

Mi asistente aún NO sabe programar.

Y no es culpa suya. Es culpa de lo que la industria le vendió antes de llegar a mí.

Lo que aprendí en estos 5 meses

Este chico es brillante. Estudioso. Motivado. Se sienta 5 horas diarias a practicar. Hace preguntas inteligentes. No se rinde.

Pero si le cambio el contexto de un problema, se bloquea. Si la IA le genera un código con un error sutil, no sabe depurarlo. Si le pido que resuelva algo que no ha visto antes, su mente se queda en blanco.

Y yo me pregunto: ¿cómo podría ser de otra manera?

Aprender a programar no es aprender sintaxis. No es copiar y pegar código de ChatGPT. No es repetir ejercicios de un curso grabado.

Aprender a programar es aprender a pensar en capas. Es entender que una variable no es solo un contenedor, es una decisión de diseño. Es saber que un fetch no es solo una llamada, es un contrato con un servidor. Es comprender que cada línea tiene un costo, una implicación, una consecuencia.

Y eso no se aprende en 21 días.

El experimento: Lo dejé suelto para ver cómo respondía

En varios momentos, dejé de darle instrucciones precisas. Le di un problema real y le dije: "Resuélvelo como puedas".

¿El resultado? Llegaba a soluciones, sí. Pero con caminos torcidos. Con código que funcionaba pero que él no podía explicar del todo. Con dependencias que no necesitaba. Con una fe ciega en que "si la IA lo dijo, debe estar bien".

Ahí entendí algo fundamental: La IA no le da criterio, le da respuestas.

Y el criterio, esa cosa esquiva que separa a un programador de un "copiador de código", solo se construye con tiempo, errores, frustración y corrección.

La estafa de los "cursos exprés"

No estoy en contra de los cursos. Estoy en contra de la mentira.

Cuando alguien vende un curso de "Python en 21 días" y te dice que con eso conseguirás trabajo, te está robando dos cosas:

Tu dinero, porque el curso no te dará lo que promete.
Tu confianza en ti mismo, porque cuando fracases (y fracasarás), creerás que el problema eres tú.

Y no, no eres tú. Es el sistema que te mintió sobre el tiempo que realmente toma.

Mi asistente tiene 5 meses conmigo, al lado, con atención personalizada, y aún le falta. ¿Cuánto le faltará a alguien que solo ve videos grabados y resuelve ejercicios automatizados?

¿Entonces cuánto tiempo toma?

No hay una respuesta única. Depende de tu contexto, de tu disciplina, de tu capacidad para equivocarte y levantarte. Pero te digo lo que sé por experiencia:

Tiempo	Nivel
3 meses	Apenas empiezas a reconocer patrones
6 meses	Puedes hacer cosas simples que funcionan, pero no entiendes del todo por qué
1 año	Empiezas a tener criterio propio
3 años	Te sientes competente. Y aún así, cada día aprendes algo que te hace sentir principiante

Yo mismo, con años de experiencia, sigo aprendiendo. Y eso no es un defecto, es la naturaleza del oficio.

Mi filosofía: Simple, depurable, humano

Por eso mi stack es simple. Nginx, Tomcat, MongoDB, Java Beans, Fetch API, JavaScript vainilla con ES6. Nada de microservicios, ni 50 dependencias, ni frameworks que cambian cada mes.

¿Por qué? Porque cuando la IA genera código, necesito entenderlo. Necesito depurarlo. Necesito saber si lo que hizo está bien o es una alucinación.

Y eso solo es posible con un stack que entiendo completamente, sin capas de abstracción innecesarias.

Si no entiendes bien Java Beans y Fetch API, la IA te va a generar código que no sabes depurar. Y te vas a frustrar. Y vas a culpar a la IA. Pero el problema no es la IA. El problema es que te saltaste los cimientos.


javascript
// Ejemplo de lo que la IA genera vs lo que tú entiendes
// SI NO ENTIENDES fetch, esto parece magia
fetch('/api/users')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

// SI ENTIENDES fetch, sabes que esto es:
// 1. Una petición HTTP asíncrona
// 2. Que puede fallar por red, CORS, timeout, 500...
// 3. Que necesita manejo de errores específico
// 4. Que el .json() también puede fallar

Lo que sí hace la IA (y es valioso)
No quiero sonar apocalíptico. La IA es una herramienta increíble. Yo la uso todos los días con OpenCode, Hermes y OpenDesign.

¿Para qué?

Para el trabajo pesado: Generar mappers, transformar datos, escribir boilerplate.

Para explorar opciones: Pedirle 5 formas diferentes de resolver un problema y elegir la mejor.

Para aprender rápido: Preguntarle "¿por qué esto funciona así?" y obtener una explicación que puedo verificar.

Pero nunca, nunca, le pido que resuelva algo que yo no entiendo. Porque si no entiendo el problema, no puedo evaluar la solución.

**Reflexión final**
Mi asistente sigue aprendiendo. Y yo sigo enseñando. Sin prisas. Sin urgencias falsas. Con la certeza de que el tiempo bien invertido siempre paga.

Si tú estás empezando, no te dejes engañar. _No compres la urgencia_. No creas que en 21 días serás programador. Cree en el proceso. Cree en los errores. Cree en la paciencia.

Y si eres de los que ya viven de esto, no olvides que algún día también estuviste crudo. Y que alguien te tuvo paciencia. Ojalá todos tengamos la honestidad de reconocerlo.

_¿Tú cuánto tiempo llevas programando? ¿Cuándo sentiste que realmente "sabías"? Te leo en los comentarios._