DEV Community: Carlos Arturo Castaño G.

Arquitectura de integración entre Web 2 y blockchain: un enfoque desacoplado

Carlos Arturo Castaño G. — Sun, 02 Aug 2026 01:52:58 +0000

Arquitectura de integración entre Web 2 y blockchain: un enfoque desacoplado

En el desarrollo de aplicaciones que combinan la web tradicional (Web 2) con funcionalidades blockchain, es común enfrentar la necesidad de generar contratos inteligentes o NFTs desde una plataforma de gestión centralizada.

Inicialmente, este tipo de procesos se manejaba de forma convencional: invocando un servidor externo (por ejemplo, con Python o Node.js), ejecutando el proceso y esperando los resultados de manera síncrona.

# Ejemplo típico de llamada síncrona
python deploy_contract.py --network ethereum --params contract_data.json

Si bien este enfoque puede funcionar en entornos controlados, presenta limitaciones importantes cuando se trabaja con blockchain:

Tiempos de confirmación variables
Posibilidad de fallos en cualquiera de las múltiples etapas del proceso
Necesidad de implementar mecanismos robustos de recuperación de errores

Problema clave: la gestión del control se vuelve más compleja que el propio objetivo de publicar información en la cadena de bloques.

El problema del acoplamiento directo

En una arquitectura típica, coexisten dos sistemas fundamentalmente independientes:

Sistema	Características
Web 2	Servidores, bases de datos, lenguajes convencionales, arquitectura backend/frontend completa
Blockchain	Protocolos propios, tiempos de confirmación variables, modelos de consenso, ejecución de contratos inteligentes

Cuando se intenta conectar ambos sistemas mediante llamadas directas (es decir, invocando funciones blockchain desde la aplicación Web 2), se genera un acoplamiento estrecho que obliga al sistema principal a gestionar:

Reintentos automáticos
Manejo de excepciones específicas de blockchain
Sincronización de estados
Validación de transacciones

La solución: desacoplamiento mediante un patrón de cola (spooler)

La mejor práctica en este tipo de escenarios es desacoplar los procesos. Para ello, se propone una arquitectura basada en tres componentes clave:

1. Definición clara de procesos blockchain

Se identifican y documentan los procesos que requieren interacción con la blockchain:

Creación de contratos inteligentes
Emisión de NFTs
Actualización de estados en la cadena

Cada proceso se diseña para responder de manera uniforme a operaciones CRUD (crear, leer, actualizar, borrar), siguiendo patrones convencionales de desarrollo.

# Ejemplo de definición de proceso
class BlockchainProcess:
    def create(self, params): pass
    def read(self, id): pass
    def update(self, id, params): pass
    def delete(self, id): pass

2. Gestor independiente de contratos y NFTs

Se desarrolla un módulo especializado, completamente desacoplado del sistema Web 2, encargado de gestionar la lógica blockchain.

# Gestor independiente con pruebas unitarias
class ContractManager:
    def deploy_contract(self, contract_data):
        # Lógica específica de blockchain
        return contract_id

    def mint_nft(self, nft_data):
        # Lógica específica de NFT
        return nft_id

Este módulo incluye:

✅ Pruebas unitarias
✅ Pruebas de integración
✅ Validación con variables de prueba conocidas

3. Spooler (cola de mensajes)

Se implementa una cola o spooler donde la aplicación Web 2 deposita las solicitudes de procesamiento blockchain.

{
  "request_id": "uuid-12345",
  "process_type": "deploy_contract",
  "payload": { ... },
  "status": "pending",
  "created_at": "2026-08-01T10:00:00Z"
}

Una vez que la solicitud se almacena en el spooler, la aplicación Web 2 queda liberada de cualquier responsabilidad sobre el proceso.

Flujo de procesamiento asíncrono

El sistema completo opera mediante los siguientes pasos:

sequenceDiagram
    participant Web2 as Aplicación Web 2
    participant Spooler as Cola (Spooler)
    participant Worker as Microservicio Blockchain
    participant Chain as Blockchain

    Web2->>Spooler: 1. Deposita solicitud
    Web2-->>Web2: 2. Continúa su ejecución
    Worker->>Spooler: 3. Monitorea nuevas solicitudes
    Worker->>Chain: 4. Procesa en la blockchain
    Chain-->>Worker: 5. Retorna resultado (ID, estado)
    Worker->>Spooler: 6. Actualiza estado
    Worker->>Web2: 7. Notifica resultado
    Web2->>Web2: 8. Actualiza procesos en espera

4. Servicio de procesamiento asíncrono

Un microservicio monitorea el spooler y, al detectar nuevas solicitudes, las procesa utilizando la lógica blockchain correspondiente.

# Worker que procesa la cola
async def process_queue():
    while True:
        requests = await spooler.get_pending_requests()
        for req in requests:
            result = await contract_manager.process(req)
            await spooler.update_status(req.id, result)
            await notify_web2(req.id, result)

Este servicio opera en los tiempos y condiciones propios de la blockchain, sin afectar el rendimiento del sistema principal.

5. Actualización de estados y notificación

El microservicio actualiza el spooler con los resultados del procesamiento:

ID del contrato o NFT creado
Variables de control
Estado de la transacción (pending, confirmed, failed)

Posteriormente, notifica a la aplicación Web 2, que actualiza los procesos que habían quedado en espera.

Beneficios de esta arquitectura

Este enfoque, que puede considerarse una API asíncrona entre Web 2 y DApp (blockchain), ofrece varias ventajas:

Beneficio	Descripción
Desacoplamiento	Cada sistema se ocupa de lo suyo: Web 2 gestiona la interfaz y lógica de negocio; blockchain se encarga de contratos e inmutabilidad
Resiliencia	Los fallos en la blockchain no afectan la disponibilidad del sistema principal. Las solicitudes pueden reintentarse automáticamente
Escalabilidad	El microservicio de procesamiento puede escalarse independientemente según la demanda
Mantenibilidad	Al separar responsabilidades, el código es más fácil de entender, probar y mantener
Trazabilidad	El spooler permite auditar todas las solicitudes y sus estados en cualquier momento

Consideraciones adicionales

Manejo de errores

try:
    result = await contract_manager.deploy_contract(data)
    await spooler.update_status(request_id, {"status": "success", "result": result})
except BlockchainError as e:
    await spooler.update_status(request_id, {"status": "failed", "error": str(e)})
    # El worker puede reintentar automáticamente según política definida

Monitoreo y alertas

Implementar logs estructurados para cada solicitud
Configurar alertas cuando el spooler acumule muchas solicitudes pendientes
Monitorear tiempos de procesamiento promedio

Seguridad

Validar y sanitizar todos los datos antes de enviarlos a la blockchain
Implementar autenticación entre el microservicio y la aplicación Web 2
Usar variables de entorno para credenciales y claves privadas

Conclusión

La arquitectura propuesta sigue un patrón similar al de las API tradicionales (frontend → API → backend), pero adaptado a la integración entre Web 2 y blockchain.

No te puedo enseñar IA (pero sí te puedo enseñar a pensar en procesos)

Carlos Arturo Castaño G. — Sun, 26 Jul 2026 23:44:13 +0000

Hace unos días, en una fiesta, una señora se me acercó angustiada. Me dijo, casi disculpándose, que la tecnología la estaba dejando atrás. Que todo el mundo hablaba de inteligencia artificial, que sentía que el tren ya había pasado y ella seguía en el andén.

Le respondí algo que llevo años pensando y que hoy quiero compartir con calma, porque creo que le sirve a mucha más gente de la que cabe en una conversación de fiesta.

Le dije: no te puedo enseñar inteligencia artificial. Y no porque sea difícil, sino porque eso no se enseña. Lo que se enseña —y lo que en realidad necesitas— es otra cosa, mucho más antigua y mucho más tuya de lo que crees.

La calculadora no nos hizo peores matemáticos

Hace muchas décadas existían las reglas de cálculo y las tablas de logaritmos. Con eso se diseñaban puentes, se calculaban órbitas, se hacía ingeniería seria. Cuando llegó la calculadora de bolsillo, hubo ingenieros que la vieron con desconfianza: "si dejas que la máquina calcule, pierdes el entendimiento profundo".

Tenían razón a medias. Sí, se perdió cierta destreza manual. Pero se ganó algo mucho más grande: la capacidad de resolver problemas que antes eran impensables por el tiempo que tomaban a mano.

Lo mismo pasó cuando el procesador de texto reemplazó a la máquina de escribir. No solo escribimos más rápido — cambió cómo pensamos mientras escribimos. Con máquina de escribir tenías que pensar la frase completa antes de teclear, porque corregir era costoso. Con un computador puedes escribir en flujo, corregir sobre la marcha, reordenar ideas sin volver a copiar la hoja entera.

En ningún caso el cambio fue malo. Fue traumático para algunos, sí. Pero nos dio un impulso.

Con la inteligencia artificial está pasando exactamente lo mismo, solo que en un ciclo mucho más rápido y mucho más ruidoso.

El ruido que no ayuda

Y aquí está el problema: alrededor de ese cambio real se ha montado un negocio de pánico. Cursos que prometen que si no te inscribes ya, te vas a quedar sin trabajo. Escuelas que venden angustia empaquetada en doce clases. Es el mismo modelo de negocio de siempre —vender miedo urgente— solo que ahora el protagonista es la IA en vez de "hazte rico trabajando desde casa".

Ese ruido no resuelve nada. Solo lucra del roce entre las personas y una herramienta que, en el fondo, no es tan complicada de entender si alguien te la explica bien, sin prisa y sin querer venderte algo.

Lo que sí es enseñable

Volviendo a la señora de la fiesta: le dije que no le podía enseñar IA, pero tampoco le podía enseñar a pensar — eso ya lo sabe hacer, lleva toda una vida haciéndolo. Lo que sí le podía enseñar es a estructurar su pensamiento en procesos claros.

¿Qué quiere decir esto en la práctica? Que antes de pedirle algo a una herramienta de IA, vale la pena hacerse tres preguntas sencillas:

¿Qué tengo? (la información o el problema de partida)
¿Qué necesito? (el resultado que busco, lo más concreto posible)
¿Cómo sabré que está bien? (cómo voy a revisar lo que me entreguen)

Eso no es "aprender inteligencia artificial". Es lo que cualquier persona ordenada hace toda su vida para resolver un problema: organizar antes de actuar. La diferencia es que ahora, si organizas bien esas tres preguntas, tienes un interlocutor —la IA— que te puede ayudar muchísimo más rápido que antes. Y si las tienes desordenadas, la IA también te lo va a devolver desordenado.

El talante correcto

No hay que tenerle miedo al cambio. El cambio es bueno, aunque a veces duela. La calculadora, el procesador de texto, y ahora la inteligencia artificial, no vinieron a quitarnos algo — vinieron a correr la línea de lo que podemos hacer un poco más lejos.

Lo único que sí pido, y esto es importante: no confundas el entusiasmo por el cambio con fe ciega. La regla de cálculo no te mentía con confianza. Una herramienta de IA sí te puede dar una respuesta que suena perfecta y no lo es. Por eso, junto con perder el miedo, hay que ganar el hábito de revisar. Ese es el verdadero "talante": ni pánico, ni entrega total. Curiosidad, con los ojos abiertos.

A la señora de la fiesta no le hizo falta un curso. Le hizo falta que alguien le dijera, sin venderle nada, que lo que ya sabe hacer —pensar con orden— sigue siendo lo más valioso que tiene.

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.