1. Ser padre una gran experiencia que ojalá todos pudieran vivir: el mayor cambio en esta década fue ser padre. Me ha cambiado la vida, ahora siento que tengo una misión de cuidar a mi hija, darle una gran experiencia y prepararla para este mundo. Ademas que verla crecer y compartir tiempo con ella es algo que no se puede describir. Desearía que la gente pudiera vivir la paternidad o maternidad y experimentar este sentimiento tan bello.
2. Para crecer hay que soltar algunas cosas: en estos años tuve que migrar a Colombia, tardé en hacerlo porque no quería soltar algunas cosas porque estaba en mi zona de confort, pero intenté y luego me di cuenta que mi «zona de confort» en realidad no lo era y gracias a Dios he podido crecer poco a poco, soltando esas cosas que te amarran porque te dan estabilidad y confianza pero a su vez te detienen de crecer.
3. Para tener una mejor vida hay que cuidar el cuerpo: en mis 20s y 30s descuidé mucho mi cuerpo. Me dejé engordar mucho y lidiar con las consecuencias de sobrepeso ha hecho disminuir un poco mi calidad de vida. Sin embargo desde hace un año empecé en gimnasio y me ha ido mejor porque siento una gran diferencia en mi cuerpo al estar un poco mas sano y con mas muscular. A pesar de ser poco el cambio, los resultados son enormes para mi.
4. Elegir una buena esposa me ha facilitado la vida y me ha permitido crecer: me casé con alguien que en vez de complicarme la vida me la facilita, me ha ayudado a crecer como persona, como profesional y en todas las áreas. Es muy importante escoger a alguien que te permita sacar lo mejor de ti y hacerte cada día mejor. Que cuando estés en tus bajones, te ayude a salir de ahí y motivarte a seguir adelante.
5. Las reuniones con las amistades ahora son de horas o minutos: a diferencia de la adolescencia y tal un poco en los 20s. Los amigos tienen familias propias, han emigrado, viven lejos y solo es posible verlos por unos pocos minutos. La calidad muchas veces es igual de bien, pero el tiempo y es muy corto. Inclusive, en algunos casos, dudas si incluso los podrás ver de nuevo.
6. Empiezas a ver mas gente de tu edad morir: sobre todo al final de los 30s, he perdido amigos por muertes inesperadas, aparentemente tenían buen estado de salud, sin embargo, se fueron antes de lo esperado. Esto me hace apreciar mas la vida y ver como algunos de nosotros se bajan del tren de la vida y continuamos sin ellos.
7. Mientras mas viajas por el mundo notas menos las diferencias entre culturas similares: durante la última década tuve la oportunidad de viajar por distintos países y conocer personas de diferentes culturas. Antes era de los que se enfocaban en las pequeñas diferencias entre los países, casi como si esas particularidades nos hicieran completamente distintos. Sin embargo, viajar me hizo cambiar esa perspectiva. Hoy me doy cuenta de lo mucho que compartimos los latinoamericanos, por ejemplo, desde nuestras costumbres hasta nuestra forma de ver la vida. Las diferencias que antes me parecían enormes se vuelven insignificantes cuando las comparo con las que existen entre nuestras culturas y las de países asiáticos, por ejemplo. Al final, viajar me enseñó que tenemos mucho más en común de lo que creemos.
8. Cumplir un sueño también significa quitarte un peso de encima: es sentir que ya no tienes que seguir persiguiendo aquello que durante tantos años ocupó un lugar en tu cabeza. Y esa tranquilidad te permite mirar tu vida desde otra perspectiva, reconocer lo que has construido y, quizás lo más importante, disfrutarlo sin estar pensando constantemente en lo que viene después. Creo que muchas veces vivimos tan concentrados en lo que nos falta por alcanzar que olvidamos detenernos a apreciar lo que ya hemos conseguido. Aquellas cosas que alguna vez parecían imposibles o demasiado lejanas terminan convirtiéndose en parte de nuestra vida cotidiana, y casi sin darnos cuenta dejamos de darles la importancia que merecen.
9. Una de las cosas más difíciles de emigrar es descubrir que, de alguna manera, te quedas sin hogar: cuando te vas de tu país, siempre queda la idea de que algún día podrás regresar y encontrar todo como lo dejaste. Pero con el paso de los años descubres que eso es imposible. Tu ciudad cambia, las personas cambian, los lugares que frecuentabas desaparecen y hasta las costumbres que antes eran parte de tu vida comienzan a sentirse extrañas. Pero no solo cambia el lugar que dejaste atrás. Tú también cambias. Sin darte cuenta, adoptas costumbres, formas de pensar y maneras de vivir del país que te recibió. Y cuando regresas a tu ciudad, descubres que ya no eres la misma persona que se fue. Es una sensación extraña caminar por las calles donde creciste y sentirte como un turista. Reconoces los lugares, recuerdas las historias, pero ya no sientes que perteneces completamente a ellos. Entonces entiendes que lo que realmente extrañas no es solamente tu país, sino un lugar que ya no existe. Extrañas la ciudad que conociste, las personas que estaban allí y, sobre todo, la persona que eras en aquel momento. Quizás lo más curioso es que, aunque nunca hubieras emigrado, muchas de esas cosas también habrían desaparecido. La diferencia es que, al irte, conservaste una imagen congelada de tu ciudad, mientras que quienes se quedaron vivieron sus cambios poco a poco.
10. No juzgues a una persona por un momento específico de su vida: en algunos encuentros con amigos noté que se comportaban de manera diferente, más distantes, apagados e incluso algo deprimidos. En ese momento atribuí su actitud a la situación que se vive en Venezuela y terminé sintiéndome molesto por el trato que recibí. Tiempo después descubrí que estaban atravesando situaciones personales muy difíciles y entendí que había reaccionado mal. Me tomé su comportamiento como algo personal, cuando en realidad no tenía nada que ver conmigo. En lugar de molestarme, debí preocuparme por entender qué les estaba pasando y ofrecerles mi apoyo como amigo. A veces olvidamos que cada persona está librando sus propias batallas, muchas de las cuales desconocemos. No todo gira alrededor de nosotros y, antes de juzgar la actitud de alguien, vale la pena detenerse a pensar qué puede estar viviendo.

En fin, es una lista mucha mas corta que la anterior, pero creo que mucha mas profunda para mí. Espero que te sirva estas experiencias o si tienes alguna que compartir, no dejes de escribir un comentario.

Gracias por leerme.

La entrada 10 cosas que aprendí durante la década de los 30 se publicó primero en El blog de Skatox.

De su creación a convertirse en un estándar

Una de las cosas que me llamó la atención fue conocer cómo Bjarne Stroustrup comenzó a desarrollar C++ en Bell Labs, inicialmente como una extensión de C que permitía utilizar la programación orientada a objetos sin sacrificar el rendimiento.

También me pareció interesante conocer la historia de la Standard Template Library (STL) y cómo, con el crecimiento del lenguaje, comenzaron los esfuerzos para crear una biblioteca estándar y, posteriormente, estandarizar C++.

A veces utilizamos características de los lenguajes sin pensar en todo el trabajo y las discusiones que hubo detrás. Escuchar a quienes participaron en esas decisiones te da otra perspectiva.

Cuando Java parecía que iba a reemplazar a C++

Otra parte que me gustó fue cuando hablaron de la llegada de Java y de cómo muchos pensaban que terminaría reemplazando a C++. Cuando entré a la universidad en el 2004, se comentaba que Java iba a reemplazar ese lenguaje; de hecho, recuerdo cómo Java se volvió extremadamente popular, especialmente por simplificar aspectos como la gestión de la memoria. Parecía que los nuevos lenguajes iban a dejar atrás las tecnologías más antiguas.

Sin embargo, C++ nunca desapareció. Siguió siendo importante en áreas donde el rendimiento y el control del hardware son fundamentales. Me parece curioso cómo, en programación, muchas veces pensamos que una nueva tecnología va a reemplazar por completo a otra, cuando en realidad terminan coexistiendo durante décadas.

C++ sigue siendo un lenguaje moderno

Uno de los aspectos que más me sorprendió fue ver cuánto ha evolucionado C++. Todavía lo asocio con punteros, la administración manual de memoria y una sintaxis bastante compleja, pero el lenguaje moderno es muy diferente al que se utilizaba hace 20 años.

Con C++11 comenzó una modernización importante, incorporando lambdas, smart pointers y muchas otras características que facilitan el desarrollo. Desde entonces, el lenguaje ha continuado evolucionando con nuevas versiones del estándar.

Me parece impresionante que haya logrado modernizarse sin abandonar la compatibilidad con décadas de software existente, aunque esto también lo convierte en un lenguaje bastante complejo.

Otra parte que disfruté fue la participación de John Romero, uno de los creadores de Doom y Quake, quien habló sobre la importancia de C++ en la industria de los videojuegos.

Como alguien a quien le gustan los videojuegos y la programación, me encanta conocer las tecnologías que subyacen a muchos de los juegos que conocemos. Es interesante cómo C++ sigue siendo fundamental en el desarrollo de motores gráficos y videojuegos modernos.

Un documental que recomiendo ver

Una de las razones por las que disfruto de estos documentales es que permiten conocer la historia del software directamente de sus protagonistas. No es lo mismo leer sobre una característica de un lenguaje que escuchar a sus creadores explicar por qué decidieron implementarla.

Después de verlo, me quedó una mayor apreciación por C++ y su capacidad de evolucionar a pesar de todas las tecnologías que han surgido para reemplazarlo.

También me recordó que, en el desarrollo de software, no todo consiste en utilizar el lenguaje o el framework más reciente. Hay tecnologías que llevan décadas resolviendo problemas y todavía tienen muchísimo que ofrecer.

Si te gusta la programación, aunque nunca hayas escrito una línea de C++, te recomiendo ver este documental.

Happy Coding!

La entrada La historia de C++: un documental sobre su evolución durante más de 40 años se publicó primero en El blog de Skatox.

Pero igual quería compartir los plugins que tengo en mi configuración, por si a alguien le sirven. Aunque escriba menos código directamente, sigo necesitando buscar archivos, moverme entre funciones, revisar diferencias y editar sin complicarme demasiado.

Los agrupé por función y dejé una breve descripción junto al enlace de cada uno. No hace falta instalar toda la lista: la idea es que encuentres algo útil para tu forma de trabajar.

Autocompletado y snippets en neovim

Para los cambios que sigo haciendo a mano, contar con un buen autocompletado y snippets sigue siendo útil. Esta es la combinación que tengo:

• nvim-cmp: El motor de autocompletado.
• cmp-async-path: Completa rutas de archivos de forma asíncrona.
• cmp-buffer: Sugiere palabras a partir del contenido de los buffers.
• cmp-nvim-lsp: Conecta las sugerencias del LSP con nvim-cmp.
• cmp-nvim-lua: Añade autocompletado para la API de Lua de Neovim.
• cmp_luasnip: Integra los snippets de LuaSnip con nvim-cmp.
• LuaSnip: El motor para expandir y trabajar con snippets.
• friendly-snippets: Una colección de snippets para distintos lenguajes.

LSP, formato, linting y depuración

Que parte del código lo escriba un agente no elimina la necesidad de revisar errores, mantener el formato y depurar. Aquí entran estas herramientas:

• nvim-lspconfig: Configuraciones para conectar los servidores de lenguaje con el cliente LSP de Neovim.
• mason.nvim: Facilita la instalación y la administración de servidores de lenguaje, formateadores, linters y adaptadores de depuración.
• conform.nvim: Permite ejecutar formateadores de código directamente desde el editor.
• formatter.nvim: Otra herramienta para integrar formateadores externos.
• nvim-lint: Integra linters para mostrar errores y advertencias en el código.
• nvim-dap: Añade un cliente de depuración para trabajar con puntos de interrupción, la ejecución paso a paso y la inspección de variables.

Edición y navegación en neovim

Esta parte sigue teniendo bastante sentido para mí: si ahora paso más tiempo leyendo código, moverme rápido por él y hacer cambios puntuales importa mucho.

• vim-commentary: Comenta y descomenta código con pocos comandos.
• vim-surround: Añade, cambia o elimina comillas, paréntesis, etiquetas y otros delimitadores.
• vim-exchange: Intercambia dos fragmentos de texto.
• vim-visual-multi: Permite trabajar con múltiples selecciones y cursores.
• vim-ReplaceWithRegister: Reemplaza texto con el contenido de un registro.
• hop.nvim: Permite saltar a distintas posiciones del texto mediante etiquetas.
• vim-tmux-navigator: Unifica la navegación entre las divisiones de Vim y los paneles de tmux.
• nvim-hlslens: Mejora la visualización de las coincidencias al buscar dentro de un archivo.
• hardtime.nvim: Ayuda a corregir hábitos de navegación y a aprovechar mejor los movimientos de Vim.
• treesj: Divide o une bloques de código entre una y varias líneas.
• refactoring.nvim: Ofrece operaciones de refactorización, como extraer funciones o variables.
• vim-import-js: Integra ImportJS para gestionar imports de JavaScript.
• vim-jsx-pretty: Añade resaltado de sintaxis para JSX.
• vim-php-refactoring-toolbox: Ofrece herramientas de refactorización para PHP.
• vim-php-cs-fixer: Integra PHP CS Fixer para corregir el estilo del código PHP.

Archivos, búsquedas y proyectos

Encontrar el archivo correcto suele ser el primer paso para entender un cambio. Estos plugins cubren la exploración, las búsquedas y el manejo de proyectos y sesiones:

• nvim-tree.lua: Un explorador de archivos en forma de árbol.
• telescope.nvim: Permite buscar y filtrar archivos, contenido, buffers y otros elementos del editor.
• neovim-project: Facilita cambiar entre proyectos y recuperar su contexto de trabajo.
• neovim-session-manager: Guarda y restaura sesiones del editor.
• vim-rooter: Ajusta el directorio de trabajo a la raíz del proyecto.

Git, tareas y sesiones en neovim

Con un agente haciendo cambios, revisar el diff es una parte importante del trabajo. Aquí también incluyo las herramientas para ejecutar tareas y mantener sesiones:

• lazygit.nvim: Permite abrir lazygit dentro de Neovim.
• git-blame.nvim: Muestra información del commit asociado a una línea.
• gitsigns.nvim: Marca cambios de Git en el editor y permite trabajar con fragmentos del diff.
• diffview.nvim: Ofrece una interfaz para revisar diferencias entre archivos y consultar su historial.
• vim-signify: Muestra líneas añadidas, modificadas o eliminadas en el margen.
• overseer.nvim: Permite ejecutar y administrar tareas, como builds y tests.
• vim-obsession: Mantiene actualizados los archivos de sesión de Vim.

Interfaz y notificaciones

También hay plugins para hacer más cómoda la lectura, ver mejor lo que está pasando y recordar atajos. En esta categoría aparecen algunas dependencias que usan otros plugins:

• indent-blankline.nvim: Muestra guías de indentación para seguir la estructura del código.
• modes.nvim: Añade indicadores visuales de color según el modo del editor.
• modicator.nvim: Cambia el color del número de la línea actual según el modo.
• noice.nvim: Modifica la presentación de mensajes, la línea de comandos y otros elementos de la interfaz.
• nui.nvim: Una biblioteca de componentes de interfaz utilizada por otros plugins.
• nvim-notify: Presenta las notificaciones en ventanas configurables.
• nvim-web-devicons: Proporciona iconos para tipos de archivo y otros elementos.
• which-key.nvim: Muestra las combinaciones de teclas disponibles mientras empiezas a escribir un atajo.
• menu: Permite crear menús, incluidos submenús, dentro del editor.
• minty: Añade herramientas para seleccionar y explorar colores.
• volt: Proporciona la base para crear interfaces interactivas utilizadas por otros plugins de esta lista.

IA, utilidades y Tailwind

Esta es la parte que más conecta con el cambio en mi forma de usar Neovim. La integración del agente convive con utilidades del editor y herramientas para leer estilos:

• claudecode.nvim: Integra Claude Code con Neovim para compartir contexto del código y revisar los cambios propuestos desde el editor.
• snacks.nvim: Una colección de utilidades, como terminales y selectores. También sirve de apoyo a la integración de Claude Code.
• tw-values.nvim: Muestra los valores CSS asociados a las clases de Tailwind de un elemento.

Gestor de plugins, dependencias y tema

Por último, estas son otras piezas de la configuración:

• plenary.nvim: Una biblioteca de funciones Lua que utilizan varios plugins.
• lazy.nvim: El gestor para instalar, actualizar y cargar los plugins.
• onedark.nvim: El tema de colores de la configuración.

La configuración sigue, el uso cambia

Viendo la lista, hay herramientas con funciones que se cruzan: más de una para formato, indicadores de cambios o sesiones. Comparto lo que tengo en mi configuración; no significa que necesites combinar todo esto para usar Neovim.

Lo que más ha cambiado es el peso de cada cosa. Con la IA, buscar, navegar y revisar código ocupa más espacio en mi trabajo. Y para eso sigue siendo útil tener un editor con el que me sienta cómodo.

Si usas alguno de estos plugins o tienes otro que te facilite trabajar con agentes de IA en Neovim, déjalo en los comentarios.

¡Éxitos mejorando tu neovim!

La entrada Los plugins que uso en Neovim en tiempos de IA se publicó primero en El blog de Skatox.

Hace poco tuve la oportunidad de participar como invitado en O corres o te encaramas, un podcast de Aníbal Rojas y Freddy Montes, en el que conversan sobre cómo distintas personas utilizan la inteligencia artificial en su trabajo y en su vida profesional. Así que cuando me invitaron a participar, obviamente me hizo bastante ilusión porque soy seguidor del programa desde sus inicios.

En este episodio hablamos sobre uno de los usos de la IA que más me ha servido durante los últimos años: apoyarme tanto en mi trabajo como desarrollador como en mi parte académica. De hecho, sobre cómo la usé para realizar la investigación de mi tesis de maestría en informática.

La IA y mi tesis

Uno de los temas principales fue cómo utilicé la inteligencia artificial en la redacción de mi tesis de Maestría en Informática. Creo que hay mucha controversia en torno al uso de la IA en la universidad, especialmente porque es muy fácil caer en pedirle a una herramienta que genere contenido y utilizarlo sin entenderlo realmente.

En mi caso, la experiencia fue diferente, pues utilicé la IA principalmente como una herramienta para acelerar procesos que normalmente consumen bastante tiempo: investigar temas, encontrar puntos en los que debía profundizar, organizar ideas y apoyarme durante la redacción.

Por supuesto, al final eres tú quien tiene que entender el trabajo que estás haciendo. La IA puede ayudarte con la tesis, pero frente al jurado respondes tú.

También conversamos sobre cómo utilizo estas herramientas para investigar y generar código. Algo que me ha permitido reducir bastante el tiempo entre tener una idea, investigarla y, finalmente, construir algo que pueda probar.

Hablar de mi lado académico

Una de las cosas que más me gustó del episodio fue poder hablar de mi trayectoria académica. Normalmente, cuando participo en eventos, escribo en el blog o hablo en redes sociales, termino conversando sobre programación, desarrollo de software, Linux, inteligencia artificial o alguna herramienta nueva que estoy probando.

Sin embargo, rara vez tengo la oportunidad de hablar sobre mi experiencia en la universidad, la investigación o el proceso de hacer una tesis. Por eso disfruté bastante esta conversación. Además, siendo seguidor de O corres o te encaramas desde hace tiempo, fue genial pasar de escuchar las conversaciones a formar parte de una de ellas.

Si te interesa cómo estoy utilizando la inteligencia artificial para investigar, programar y trabajar en proyectos académicos, te recomiendo ver el episodio.

Y si después de verlo tienes alguna pregunta, inquietud o simplemente quieres compartir cómo estás utilizando IA en tus estudios o trabajo, déjala en los comentarios.

Happy Hacking!

La entrada La IA te ayuda con la tesis, frente al jurado respondes tú se publicó primero en El blog de Skatox.

Lo interesante de esta migración no fue solo aprender a crear un bloque. También me hizo ver, de una forma diferente, cómo ha evolucionado WordPress.

De widgets en PHP a una interfaz en React

Un widget clásico de WordPress normalmente hacía casi todo en PHP. Por ejemplo, teníamos algo parecido a esto:

class My_Widget extends WP_Widget {

    public function widget( $args, $instance ) {
        // Obtener datos.
        // Generar HTML.
        // Mostrar el widget.
    }

    public function form( $instance ) {
        // Formulario de configuración.
    }
}

El formulario que veía el administrador, la configuración y el HTML final estaban muy ligados entre sí. Con Gutenberg la separación es diferente. Ahora puedes tener PHP encargándose de los datos y del renderizado mientras que el editor utiliza JavaScript y React para construir la interfaz de configuración.

Por esta razón, siento que WordPress cada vez se siente más como un CMS que ofrece servicios y APIs en PHP, mientras que diferentes interfaces consumen esos servicios.

Gutenberg es probablemente el mejor ejemplo, porque el editor trabaja con entidades como posts, páginas, usuarios o términos mediante @wordpress/core-dataQue internamente puede procesar los datos mediante las APIs de WordPress.

PHP no desapareció. Simplemente ya no tiene que encargarse de toda la interfaz.

¿Cómo comenzar un bloque de Gutenberg?

WordPress posee una herramienta oficial llamada @wordpress/create-block que genera la estructura inicial de un plugin con un bloque, incluyendo JavaScript, PHP, CSS y la configuración necesaria para compilar todo. Puedes crear uno ejecutando:

npx @wordpress/create-block@latest my-block --namespace=my-plugin

Luego:

cd my-block
npm start

Aunque estés migrando un plugin existente, te recomiendo ejecutar este comando al menos una vez. Es una forma sencilla de entender cuál es la estructura recomendada actualmente por WordPress.

Entre los archivos encontrarás uno particularmente importante:

block.json

Este archivo contiene la definición del bloque: nombre, atributos, scripts, estilos y demás metadatos. Por ejemplo:

{
    "apiVersion": 3,
    "name": "my-plugin/archive-list",
    "title": "Archive List",
    "category": "widgets",
    "attributes": {
        "showCount": {
            "type": "boolean",
            "default": false
        }
    }
}

WordPress actualmente recomienda registrar los bloques utilizando esta metadata y register_block_type() Desde PHP se hace asi:

add_action( 'init', function() {
    register_block_type( __DIR__ . '/build' );
} );

Con eso PHP conoce nuestro bloque y WordPress puede cargar los scripts y estilos necesarios.

La configuración del bloque de Gutenberg ahora vive en React

En un widget clásico, las opciones se construían con inputs HTML generados en PHP. En un bloque de Gutenberg puedes crear esa interfaz con los componentes que ya ofrece WordPress. Por ejemplo:

import { InspectorControls } from '@wordpress/block-editor';
import {
    PanelBody,
    ToggleControl
} from '@wordpress/components';

export default function Edit({ attributes, setAttributes }) {
    return (
        <InspectorControls>
            <PanelBody title="Options">
                <ToggleControl
                    label="Show post count"
                    checked={ attributes.showCount }
                    onChange={ ( value ) =>
                        setAttributes({ showCount: value })
                    }
                />
            </PanelBody>
        </InspectorControls>
    );
}

De esta forma, Gutenberg se encarga de gran parte de la experiencia del editor y nosotros solo debemos definir qué opciones necesita nuestro bloque.

En mis plugins esto reemplazó buena parte de los formularios que antes tenía que generar manualmente desde PHP.

Consumir los datos de WordPress desde el bloque de Gutenberg

Otra parte interesante es que no necesariamente tienes que crear tus propios endpoints para obtener información que WordPress ya conoce. Desde el editor puedes consultar entidades utilizando core-data. Por ejemplo, para obtener páginas puedes utilizar:

import { useEntityRecords } from '@wordpress/core-data';

const { records, isResolving } = useEntityRecords(
    'postType',
    'page'
);

WordPress se encarga de resolver la petición, de mantener los datos en su store y de entregarlos al componente. En un plugin como JS Categories List, el mismo concepto permite trabajar con taxonomías y categorías desde la interfaz del bloque, sin tener que imprimir previamente toda esa información en el HTML generado por PHP.

Eso también tiene otra ventaja, la nueva versión de mis plugins puede leer la información dinámicamente y cargar JavaScript y CSS solamente cuando realmente existe un bloque o widget en la página, en lugar de cargar recursos innecesariamente en todo el sitio.

No tienes que reescribir todo tu PHP

Esta fue una de las cosas que pensé inicialmente que serían más complicadas.

Migrar a un bloque de Gutenberg no significa necesariamente convertir todo el plugin a JavaScript. Puedes crear un bloque dinámico y continuar renderizando su contenido desde PHP, por ejemplo, block.json puede indicar:

{
    "render": "file:./render.php"
}

Y dentro de render.php Puedes reutilizar buena parte de la lógica que ya tenía tu antiguo widget, permitiendo tener una migración más progresiva:

<?php

$show_count = $attributes['showCount'] ?? false;

echo my_old_archive_render_function(
    $show_count
);

La interfaz del editor puede estar hecha con React, mientras que el frontend todavía utiliza funciones PHP que llevan años funcionando. Los bloques dinámicos están diseñados precisamente para casos donde el contenido debe calcularse al momento de renderizar la página, y WordPress permite hacerlo mediante un archivo render.php o un render_callback.

En mi caso, esto fue bastante útil porque no tenía sentido reescribir código estable solamente por utilizar Gutenberg.

Mantener el antiguo widget por retrocompatibilidad

También decidí no eliminar de inmediato los widgets anteriores. Tanto JS Archive List como JS Categories List mantienen una versión legacy en PHP para instalaciones que todavía la utilizan, mientras que el desarrollo nuevo está enfocado en el bloque Gutenberg.

Creo que esta es una buena estrategia para plugins que llevan muchos años publicados. Puedes modernizar el código sin afectar las instalaciones de los usuarios que configuraron el widget hace más de cinco años. Ya con el tiempo puedes dejar la implementación antigua únicamente en modo de mantenimiento.

WordPress es bastante diferente ahora

Después de hacer esta migración, creo que desarrollar para WordPress actualmente se parece bastante menos al WordPress con el que comencé hace años.

PHP continúa siendo una parte fundamental, pero ahora tenemos una capa de APIs, bases de datos, componentes y una interfaz escrita en React.

En lugar de pensar:

“Tengo que crear una página PHP para configurar esto.”

Cada vez pienso más:

“¿Qué datos o servicios debe proporcionar WordPress y cómo los va a consumir la interfaz?”

Ese cambio de mentalidad hace que Gutenberg tenga mucho más sentido. Así que si tienes un plugin antiguo basado en WP_Widget, no necesitas reescribirlo por completo de una vez. Puedes comenzar creando un bloque, mover las opciones del formulario a React y reutilizar tu código PHP para el renderizado. Luego moderniza el resto poco a poco.

Para empezar y entender cómo funciona todo, crea primero un bloque vacío con @wordpress/create-block, ejecuta npm start Y comienza a modificarlo. Es probablemente la forma más rápida de dejar de ver Gutenberg como algo extraño y comenzar a verlo simplemente como la nueva interfaz de desarrollo de WordPress.

Happy coding!

La entrada Cómo migrar un widget de WordPress a un bloque de Gutenberg se publicó primero en El blog de Skatox.

Añadir un plugin es una respuesta válida cuando resuelve una necesidad concreta, está bien mantenido y no introduce complejidad innecesaria. El problema aparece cuando WordPress empieza a crecer por acumulación: una extensión para esto, otra para aquello, una tercera para conectar sistemas y una cuarta para corregir el comportamiento de las anteriores.

Al principio parece eficiente. Con el tiempo, esa lógica suele traducirse en incompatibilidades, tiempos de carga peores, pantallas de administración confusas y miedo a actualizar. La cuestión no es demonizar los plugins, sino reconocer cuándo el proyecto ya no debería depender de ellos para sostener lógica crítica del negocio.

Señales de que el límite ya ha llegado

Hay algunas pistas bastante claras. Por ejemplo: cuando un cambio pequeño obliga a revisar varios plugins a la vez; cuando una integración importante depende de hacks o campos escondidos; cuando cada actualización genera incertidumbre; o cuando nadie del equipo puede explicar con seguridad dónde vive cada regla funcional.

También es una señal de que la administración se vuelve opaca. Si quienes editan contenidos encuentran campos duplicados, procesos inconsistentes o pasos manuales que no entienden, probablemente el problema no es de formación, sino de arquitectura.

En ese escenario, lo sensato suele ser plantear desarrollo WordPress a medida. No porque “lo custom” sea mejor por definición, sino porque ciertas reglas del negocio merecen vivir en código propio, con alcance delimitado, pruebas razonables y una lógica que el equipo pueda mantener con criterio.

Qué suele llevarse a medida

Normalmente conviene customizar aquello que forma parte del producto o del flujo principal: integraciones con ERP o CRM, automatizaciones, modelos de datos específicos, áreas privadas, buscadores especializados, reglas de publicación, conectores API o paneles internos simplificados. Son piezas donde la configuración genérica se queda corta o genera demasiadas excepciones.

Esto permite reducir la dependencia de opciones ocultas y reacciones en cadena. En vez de adaptar el negocio a un plugin, se adapta el desarrollo a la necesidad real. El resultado no tiene por qué ser más complejo; a menudo es más claro, porque cada responsabilidad queda mejor delimitada.

No se trata de rehacerlo todo

Pasar a medida no siempre implica sustituir toda la base existente. Muchas veces basta con identificar qué piezas pueden seguir siendo estándar y cuáles conviene aislar en una capa propia. Lo importante es decidirlo con una visión de conjunto, no solo reaccionando a incidencias.

La mejor pregunta, por tanto, no es cuántos plugins tiene la web, sino si la arquitectura sigue siendo comprensible, mantenible y segura. Cuando la respuesta empieza a ser no, añadir otro plugin rara vez arregla el problema. Lo habitual es que simplemente lo esconda durante un tiempo más.

La administración también debe simplificarse

Cuando se apuesta por una capa a medida, una parte del valor aparece en el backend. Menos campos irrelevantes, procesos más claros, validaciones coherentes y pantallas pensadas para el uso diario reducen errores y dependencia. Es decir, el desarrollo a medida no solo mejora el código; también puede mejorar mucho la experiencia del equipo que trabaja dentro de WordPress todos los días.

La entrada Cuando WordPress necesita desarrollo a medida y no simplemente más plugins se publicó primero en El blog de Skatox.

Visual Studio Code es uno de esos programas que hoy parecen haber existido desde siempre. En pocos años pasó de ser un nuevo editor creado por Microsoft, bastante criticado por utilizar tecnologías web para una aplicación de escritorio, a convertirse prácticamente en un estándar dentro de la industria.

Al final no parece que les haya ido tan mal.

¿De dónde salió Visual Studio Code?

Una de las cosas interesantes del documental es que VS Code no comenzó realmente como un editor de escritorio. El proyecto tiene sus raíces en un equipo de Microsoft en Zurich que trabajaba en herramientas de desarrollo para el navegador. De ahí aparecieron proyectos como Monaco, que eventualmente evolucionaron hasta convertirse en Visual Studio Code.

Para construirlo utilizaron tecnologías web sobre Electron. Actualmente esto no resulta demasiado extraño, pero hace diez años utilizar HTML, CSS y JavaScript para crear una aplicación de escritorio generaba bastante discusión, principalmente por el consumo de recursos comparado con aplicaciones nativas.

Otra cosa que me sorprendió fue descubrir que el proyecto era desarrollado por programadores distribuidos en diferentes partes del mundo. Siempre había imaginado que proyectos de este tamaño dentro de Microsoft se construían principalmente entre personas de una misma oficina o región.

El documental además está contado por los propios protagonistas del proyecto, explicando las decisiones que fueron tomando hasta que aquel editor bastante polémico terminó convirtiéndose en uno de los más utilizados de la industria.

Microsoft estaba apostando bastante por la web

Algo que me llamó especialmente la atención fue ver cuántas tecnologías relacionadas estaba desarrollando Microsoft durante esa época. Por un lado estaba Monaco y todo el trabajo alrededor de herramientas de desarrollo para la web. Al mismo tiempo estaban creando TypeScript, que eventualmente tendría una relación bastante cercana con VS Code.

También apareció el Language Server Protocol, mejor conocido como LSP. El cual permite que un editor se comunique mediante un protocolo estándar con un servidor que entiende determinado lenguaje de programación. De esta forma funcionalidades como autocompletado, navegación entre definiciones o detección de errores no tienen que implementarse nuevamente para cada editor.

Como usuario de Neovim esto me parece particularmente interesante porque actualmente utilizo LSP todos los días, aunque prácticamente no utilice VS Code. Es un buen ejemplo de una tecnología nacida alrededor de un producto de Microsoft que terminó beneficiando a todo el ecosistema.

De VS Code a los editores con IA

Otra decisión importante fue publicar buena parte del proyecto como open source. Con el tiempo VS Code no solamente consiguió un enorme ecosistema de extensiones, sino que su código terminó sirviendo como base para construir otros editores.

Esto se vuelve especialmente interesante actualmente con la inteligencia artificial.Varios de los nuevos editores orientados a programación con IA son forks o están construidos sobre tecnologías provenientes de VS Code. En lugar de desarrollar un editor completamente desde cero, pueden utilizar una base que lleva más de una década evolucionando.

El documental habla precisamente de esta nueva etapa y de cómo VS Code terminó convirtiéndose no solamente en un editor, sino prácticamente en infraestructura para otras herramientas de desarrollo.

Me parece curioso que algunos de los productos que ahora intentan competir contra VS Code existan precisamente gracias al trabajo que Microsoft hizo con el proyecto.

¿Utilizo Visual Studio Code?

Curiosamente, casi no. Desde hace bastante tiempo mi editor principal es Neovim y sigo prefiriéndolo para mi trabajo diario. Me gusta trabajar cerca de la terminal y tener un entorno configurado exactamente como quiero. Sin embargo, en diferentes trabajos me ha tocado utilizar Visual Studio Code y realmente no me parece un mal editor.

Funciona en prácticamente cualquier plataforma, tiene un ecosistema enorme de extensiones y para alguien que simplemente quiere instalar un editor y comenzar a programar resulta bastante cómodo. Además, tengo que reconocer que es de las pocas tecnologías de Microsoft que me parece que están realmente bien hechas.

No significa que vaya a abandonar Neovim mañana, pero puedo entender perfectamente por qué terminó siendo tan popular.

¿Vale la pena ver The Story of VS Code?

Si eres programador y utilizas Visual Studio Code diariamente, te recomiendo ver el documental. Cuenta cómo comenzó el proyecto, por qué decidieron utilizar tecnologías web, quiénes estuvieron involucrados y cómo aparecieron tecnologías como Monaco, TypeScript y LSP alrededor de todo este ecosistema.

También resulta interesante ver cómo un editor que inicialmente recibió bastantes críticas terminó afectando para bien la forma en que desarrollamos software y sirviendo de base para una nueva generación de herramientas.

Incluso si no utilizas VS Code, probablemente utilizas alguna tecnología que fue influenciada por este proyecto.

Happy coding!

La entrada The Story of VS Code: Un Documental Imprescindible se publicó primero en El blog de Skatox.

Tmux seguía funcionando, por supuesto, pero cada vez me costaba más navegar entre tantas ventanas y paneles. En ocasiones no recordaba dónde había dejado determinado agente, cuál seguía trabajando o cuál estaba esperando que respondiera una pregunta. Terminaba de recorrer las sesiones una por una para comprobar qué estaba ocurriendo.

¿Qué es Herdr?

Herdr es un multiplexor de terminal diseñado específicamente para trabajar con agentes de programación. La forma más sencilla de explicarlo es que se trata de una especie de tmux modernizado y adaptado a la era de la inteligencia artificial.

Al igual que tmux, Herdr permite crear múltiples terminales, dividirlas en paneles y mantener las sesiones en ejecución en segundo plano. Puedes cerrar la ventana de la terminal, volver más tarde y continuar donde estabas, sin detener los agentes ni los procesos activos.

La diferencia es que Herdr no solo ve paneles: también reconoce los agentes que se ejecutan dentro de ellos. Es compatible con herramientas como Claude Code, Codex, OpenCode, GitHub Copilot CLI, Cursor Agent, entre otras. En una barra lateral se muestra si cada agente está trabajando, bloqueado, inactivo o ha terminado su tarea.

Esta pequeña diferencia resuelve uno de los principales problemas que tenía con tmux. Ya no necesito recorrer manualmente todos los paneles para saber qué agente requiere mi atención.

Espacios de trabajo, pestañas y paneles

Una de las características que más me gustaron es la manera en que Herdr organiza las terminales. La herramienta utiliza tres niveles:

• Los espacios de trabajo permiten separar proyectos.
• Las pestañas agrupan diferentes tareas dentro de cada proyecto.
• Los paneles contienen las consolas, los agentes y los servicios que se ejecutan.

Por ejemplo, puedo tener un espacio de trabajo para cada proyecto. Dentro de él creo una pestaña para los agentes, otra para el servidor de desarrollo y otra para las pruebas o los registros. Si necesito observar dos procesos al mismo tiempo, simplemente divido la pestaña en varios paneles.

La barra lateral resume el estado de todos los agentes. De esta forma, puedo ver rápidamente quién continúa trabajando, quién necesita que apruebe una acción y quién ya finalizó. Al seleccionarlo, Herdr me lleva directamente a su panel para revisar el resultado y redactar el siguiente prompt.

Para quienes trabajamos con varios agentes en paralelo, esta vista resulta mucho más práctica que intentar recordar en qué ventana se encuentra cada uno.

Una transición sencilla desde tmux

Otra razón por la que comencé a utilizar Herdr es que no tuve que aprender de cero una nueva forma de controlar la terminal. La herramienta conserva el mismo modelo de prefijo de tmux: por defecto se utiliza Ctrl+B Antes de ejecutar una acción.

También incluye varios atajos familiares. Con Ctrl+B y luego c Se crea una nueva pestaña, mientras que Ctrl+B y después n o p Permite avanzar o retroceder entre ellas. Para dividir paneles, navegar por los espacios de trabajo o desconectarse de una sesión, se sigue una lógica muy similar.

Si ya utilizas tmux, la adaptación es bastante rápida. Además, al presionar Ctrl+B y luego ? Puedes consultar todos los atajos disponibles.

Herdr también soporta el mouse por defecto. Es posible seleccionar paneles, pestañas, espacios de trabajo y agentes con un clic, cambiar el tamaño de las divisiones arrastrando sus bordes y abrir menús contextuales con el botón derecho. Aunque normalmente prefiero los atajos de teclado, el mouse resulta cómodo cuando quiero reorganizar rápidamente la interfaz.

Notificaciones cuando un agente necesita atención

Una de las funciones más útiles de Herdr es su sistema de notificaciones. La herramienta puede avisar cuando un agente termina una tarea o cuando necesita que respondamos una pregunta o aprobemos alguna acción. Esto permite dejar varios agentes trabajando y concentrarse en otra actividad sin revisar cada terminal constantemente. Cuando alguno finaliza, recibo el aviso, salto directamente a su panel, reviso lo que hizo y continúo la conversación con un nuevo prompt.

En la práctica, Herdr convierte un conjunto de terminales dispersas en una pequeña central de control para agentes. No ejecuta el trabajo por ellos ni reemplaza herramientas como Codex o Claude Code; simplemente ofrece una forma mucho más clara de organizarlos y supervisarlos.

Herdr funciona dentro de la terminal

Existen otras alternativas para administrar agentes, como cmux, pero muchas de ellas funcionan como aplicaciones independientes o buscan reemplazar la terminal que ya utilizas. Herdr adopta un enfoque diferente. Es una herramienta nativa de consola, desarrollada en Rust, que se ejecuta en la terminal que prefieras. No necesita Electron ni obliga a cambiar Ghostty, Kitty, iTerm2, Alacritty ni a cambiar ningún otro emulador de terminal que ya forme parte de tu entorno.

Para mí, esto es una gran ventaja. Puedo conservar el flujo de trabajo que he utilizado durante años, entrar por SSH cuando lo necesito y seguir trabajando exclusivamente desde la consola.

Una herramienta de código abierto para organizar el nuevo desarrollo con IA

Otro aspecto que me encanta es que Herdr es un proyecto de código abierto, distribuido bajo la licencia Apache 2.0. Esto permite revisar su código, proponer mejoras y contribuir con una herramienta que probablemente resulte cada vez más útil a medida que trabajar con varios agentes se convierta en algo habitual.

Después de muchos años utilizando tmux, no esperaba reemplazarlo fácilmente. Sin embargo, Herdr conserva las ideas que siempre me gustaron de tmux y añade justo lo que necesitaba para mi flujo de trabajo actual: una interfaz más moderna, organización por proyectos, soporte para el mouse, seguimiento del estado de los agentes y notificaciones cuando alguno requiere atención.

Si trabajas con muchas consolas, mantienes varios servicios activos o utilizas diferentes agentes de inteligencia artificial en paralelo, te recomiendo probarlo. En esencia, Herdr es el tmux de siempre, pero preparado para una forma de desarrollar software que apenas hace unos años no existía.

Happy coding!

La entrada Herdr: el Tmux moderno para trabajar con agentes de IA en paralelo se publicó primero en El blog de Skatox.

Revisando algunos de esos videos, me encontré con uno que todavía no había compartido por aquí: SUSE Now Hallelujah, una parodia publicada por SUSE en 2018 basada en la canción Faith de Stevie Wonder y Ariana Grande, perteneciente a la banda sonora de la película Sing. Y, como suele pasar con los videos musicales de SUSE, no se limitaron a cambiar algunas palabras de la canción original. Crearon todo un videoclip, con músicos, cantantes, coreografía y, por supuesto, bastante color verde.

¿De qué se trata SUSE Now Hallelujah?

La protagonista de la canción es prácticamente la mascota de SUSE: el famoso camaleón verde. A partir de allí, la letra comienza a incorporar diversas características y tecnologías relacionadas con SUSE y Linux.

Entre las referencias aparecen conceptos como centros de datos, uptime, infraestructura, almacenamiento, contenedores, escalabilidad y live patching, todo mientras el camaleón baila y demuestra por qué, aparentemente, es el rey del open source.

Si trabajas administrando servidores o tienes experiencia con Linux en entornos empresariales, seguramente reconocerás muchas de estas referencias. Por ejemplo, el live patching permite aplicar determinados parches al kernel sin tener que reiniciar completamente el sistema, lo cual es especialmente importante cuando estás administrando servicios que deben permanecer disponibles durante largos períodos de tiempo.

Pero tampoco hace falta conocer todos estos conceptos para disfrutar el video. La canción funciona simplemente por lo absurda y divertida que resulta la idea de convertir características de una distribución Linux empresarial en una canción alegre y pegadiza.

SUSE y su extraña tradición musical

Una de las cosas que siempre me ha parecido curiosa de SUSE es que, durante años, ha utilizado la música y el humor como parte de su cultura. No es precisamente lo primero que imaginas cuando piensas en una empresa dedicada a Linux empresarial, servidores e infraestructura.

SUSE Now Hallelujah sigue exactamente ese espíritu: tomar algo que normalmente podría parecer extremadamente técnico y convertirlo en una pequeña celebración de la cultura geek y del software libre.

Así que si utilizas Linux, administras servidores, trabajas en tecnología o simplemente disfrutas este tipo de rarezas de Internet, te recomiendo ver el video.

Y cuidado, porque después de escucharlo unas cuantas veces, probablemente termines con el “I’m going green, Hallelujah, I’m SUSE now” dando vueltas en tu cabeza.

Finalmente, si te gusta este tipo de videos, recuerda revisar la categoría de Música Geek del blog, donde durante años he recopilado canciones, parodias y otras rarezas musicales creadas especialmente para geeks.

La entrada SUSE Now Hallelujah: otra gran parodia musical geek de SUSE se publicó primero en El blog de Skatox.

Paradójicamente, eso me ha hecho desarrollar más rápido.

Durante los últimos años hemos visto aparecer herramientas capaces de generar código en cuestión de segundos. Sin embargo, cualquiera que haya trabajado en proyectos reales sabe que generar código y desarrollar software son dos cosas muy distintas. Un programa no solo necesita funcionar; también debe ser mantenible, probado, seguro y fácil de evolucionar.

Gracias al Ing. Ronald Escalona, quien me compartió información sobre las skills de Superpowers, un plugin que incorpora un conjunto de skills especializados para el desarrollo de software. Después de utilizarlo durante un mes, puedo decir que cambió por completo mi forma de trabajar con IA y, curiosamente, también mi forma de programar.

¿Qué es un plugin y qué es un skill?

Antes de hablar de Superpowers, conviene aclarar dos conceptos:

• Un plugin es una extensión que añade nuevas capacidades a una aplicación. En este caso, Superpowers amplía las capacidades del modelo de lenguaje incorporando metodologías, procesos y herramientas orientados específicamente al desarrollo de software.
• Un skill, por otra parte, puede entenderse como una habilidad especializada. No es simplemente un prompt enorme ni un conjunto de instrucciones copiadas y pegadas en cada conversación. Es un flujo de trabajo diseñado para resolver un tipo específico de problema siguiendo buenas prácticas de ingeniería.

La mejor forma de imaginarlo es pensar que, en lugar de conversar con una única inteligencia artificial, estás incorporando a tu equipo a diferentes especialistas: un arquitecto de software, un ingeniero de calidad, un experto en pruebas automatizadas, un revisor de código o un especialista en depuración. Dependiendo del problema que quieras resolver, utilizas el skill más adecuado.

Lo interesante es que estos skills no buscan reemplazar al desarrollador; buscan que la IA trabaje siguiendo un proceso similar al que utilizaría un buen equipo de ingeniería.

Los skills que componen Superpowers

Aunque cada skill puede utilizarse de forma independiente, en conjunto cubren prácticamente todo el ciclo de desarrollo de una funcionalidad.

El proceso suele comenzar con Brainstorming, una skill que ayuda a comprender el problema antes de pensar en la implementación. En lugar de generar código de inmediato, analiza los requisitos, identifica restricciones, plantea preguntas clave y propone distintas alternativas para resolver el problema.

Una vez que existe claridad sobre lo que se quiere construir, Writing Plans transforma esas ideas en un plan de implementación dividido en tareas pequeñas y ordenadas. Este paso resulta especialmente útil cuando se trabaja en funcionalidades grandes o proyectos complejos, ya que evita improvisar durante el desarrollo.

Si el proyecto requiere trabajar de forma aislada, Using Git Worktrees prepara automáticamente un entorno independiente. Aunque esta es una característica nativa de Git, pocas personas la utilizan, y resulta extremadamente útil para desarrollar funcionalidades sin afectar la rama principal del proyecto.

Uno de los skills más interesantes es el Test-Driven Development (TDD). En lugar de escribir primero el código, guía al desarrollador para que siga el ciclo clásico de TDD: crear una prueba, verificar que falle, implementar únicamente el código necesario para hacerla pasar y finalmente refactorizar. Esto convierte las pruebas en una especificación funcional y hace que la IA deje de «adivinar» cómo debería comportarse el sistema.

Cuando las tareas son demasiado grandes, Subagent Driven Development permite dividir el trabajo entre varios agentes especializados. Mientras uno analiza la arquitectura, otro implementa, otro escribe pruebas y otro revisa la documentación. El resultado se parece mucho más al trabajo colaborativo de un equipo que a una conversación tradicional con un modelo de lenguaje.

La fase de depuración también tiene su propio proceso, denominado Systematic Debugging, que evita modificar el código por intuición y propone investigar primero la causa raíz del problema antes de aplicar cualquier corrección.

Después de implementar una funcionalidad, entra en juego Requesting Code Review, encargado de revisar la calidad del código desde distintos puntos de vista, como mantenibilidad, claridad, arquitectura y rendimiento. Si posteriormente surgen comentarios durante una revisión, Receiving Code Review ayuda a analizarlos críticamente y decidir cuáles realmente mejoran el proyecto.

Superpowers también incorpora Fix CI, pensado para diagnosticar problemas en los pipelines de integración continua, especialmente cuando fallan las pruebas o los procesos de GitHub Actions.

Antes de considerar terminada una tarea, aparece Verification Before Completion, cuyo objetivo es comprobar que todo compile correctamente, que las pruebas pasen y que no existan errores conocidos. Finalmente, «Finishing a Development Branch» realiza una última revisión antes de integrar la rama al proyecto principal, verificando que el trabajo esté realmente listo para hacer merge.

Vistos individualmente, parecen herramientas independientes, pero juntos forman una metodología bastante completa para desarrollar software asistido por inteligencia artificial.

Cómo se trabaja con Superpowers

Todo comienza con Brainstorming. Antes de pensar en el código, intento entender el problema, revisar los requisitos y explorar diferentes alternativas. Muchas veces descubro que la primera idea no es necesariamente la mejor.

Cuando la solución está clara, utilizo Writing Plans para dividir el trabajo en pequeñas tareas. Tener un plan evita perder tiempo durante la implementación y hace mucho más sencillo saber qué falta por hacer.

Si la funcionalidad es importante, preparo un entorno aislado utilizando Using Git Worktrees, lo que me permite experimentar sin preocuparme por afectar el estado del proyecto principal.

A partir de ese momento, intento seguir siempre un enfoque basado en Test-Driven Development. Primero escribo las pruebas, luego implemento únicamente el código necesario para que pasen y, finalmente, refactorizo cuando todo funciona correctamente. Si el desarrollo requiere varias partes independientes, Subagent Driven Development permite repartir responsabilidades entre distintos agentes especializados, lo que acelera bastante el proceso.

Cuando inevitablemente aparece algún error, procuro resistir la tentación de modificar el código de inmediato. En lugar de ello, recurro a Systematic Debugging, que obliga a formular hipótesis, buscar evidencia y encontrar la verdadera causa del problema antes de proponer una solución.

Una vez implementada la funcionalidad, solicito una revisión mediante Requesting Code Review, analizo los comentarios utilizando Receiving Code Review y, antes de considerar terminado el trabajo, ejecuto Verification Before Completion para asegurarme de que todo compile correctamente y las pruebas pasen sin inconvenientes. Finalmente, Finishing a Development Branch sirve como una última comprobación antes de integrar la rama al proyecto principal.

Puede parecer un proceso más largo que simplemente pedirle a la IA «implementa esta funcionalidad», pero mi experiencia ha sido exactamente lo contrario. Al existir un proceso ordenado, aparecen menos errores, disminuye el retrabajo y las implementaciones suelen llegar mucho más maduras desde el principio.

Reflexión final

Después de varios meses utilizando este enfoque, tengo una conclusión bastante clara: la inteligencia artificial no está reemplazando al ingeniero de software; está cambiando cuál es su trabajo. Cada vez dedicaremos menos tiempo a escribir código repetitivo y mucho más a comprender problemas, diseñar soluciones, validar resultados y tomar decisiones técnicas. Es un cambio que, lejos de preocuparme, me parece una evolución natural de nuestra profesión.

De hecho, esto me recuerda a mi profesor de Sistemas de Información II cuando en clase dijo que una cosa es la Ingeniería de Software y otra programar. Que al estudiar ingenieria haríamos mas que aquellos que solo saben programar, y eso fue hace como 18 años. Todo un visionario.

Herramientas como Superpowers demuestran que utilizar IA para desarrollar software puede ser cada vez más seguro y confiable cuando existe una metodología que la respalda. Sin embargo, ninguna metodología elimina la necesidad del criterio humano. Comprender el contexto del negocio, decidir qué problema vale la pena resolver, evaluar riesgos y determinar cuándo una solución realmente cumple con los objetivos del proyecto siguen siendo tareas del desarrollador.

La IA seguirá mejorando, escribirá código cada vez más rápido y probablemente resolverá problemas cada vez más complejos. Pero mientras existan decisiones de diseño, arquitectura y negocio que tomar, la experiencia humana seguirá siendo indispensable. Quizás el futuro del desarrollo no consista en escribir más código, sino en construir mejores procesos para colaborar con la inteligencia artificial de forma responsable. Y, sinceramente, creo que ese futuro ya comenzó.

Happy coding!

La entrada Escribo menos código que nunca: Superpowers y el nuevo desarrollo con IA se publicó primero en El blog de Skatox.