Saltar al contenido

El blog de Skatox Entradas

Escribo menos código que nunca: Superpowers y el nuevo desarrollo con IA

Hace unos pocos meses me di cuenta de que cada vez escribía menos código directamente. No porque estuviera desarrollando menos software, sino porque mi forma de trabajar había cambiado por completo. Si antes abría mi editor y comenzaba a implementar una idea casi de inmediato, ahora paso mucho más tiempo entendiendo el problema, diseñando la solución y validando que todo tenga sentido antes de escribir una sola línea a través del uso de Superpowers.

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.

Programador trabajando con las skills de superpowers que sugiere código en pantalla
Gracias al skill de superpowers, ahora tengo un asistente que programa por mi

¿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!

Deja un comentario

Code for the People: documental sobre la web abierta y WordPress

Navegando por las redes sociales vi que muchas personas anunciaban el lanzamiento de un documental sobre quienes han participado en el desarrollo de la web. Me llamó la atención, ya que hacía mucho tiempo que no se producía un contenido de este tipo, así que decidí darle una oportunidad. El documental se titula Code for the People y está dirigido por Bao Nguen. A lo largo de la obra se presentan las experiencias de varias personas que contribuyeron a democratizar la web, haciéndola más accesible y permitiendo que millones de usuarios pudieran crear y compartir contenido en Internet.

¿Donde puedo ver Code for the People?

Code for the People es un cortometraje de 20 minutos dirigido por Bao Nguyen. El mismo fue subido a Youtube y lo puedes ver . En él se realiza un recorrido por el pasado, el presente y el futuro de la web abierta. Además, plantea una reflexión sobre los desafíos que enfrenta el software de código abierto ante el creciente dominio de los monopolios digitales y el auge de los sistemas de inteligencia artificial de carácter propietario.

A medida que avanza el documental, es fácil notar que muchas de las personas entrevistadas están relacionadas, de una u otra forma, con el proyecto WordPress. Esto no representa ningún inconveniente para la narrativa, aunque, al investigar un poco más, descubrí que el documental fue patrocinado por Automattic. Aun así, ese patrocinio no resulta invasivo ni resta credibilidad al contenido, ya que el enfoque sigue siendo una reflexión sobre la evolución de la web abierta y la importancia del software libre en su desarrollo.

Code for the People | A Film by Bao Nguyen | Full Documentary

Espero que os haya gustado este documental. Aunque está centrado exclusivamente en la comunidad de WordPress, creo que resulta inspirador y muy motivador. Personalmente, me siento identificado con muchas de las personas que aparecen en él, y siempre es interesante conocer cómo ha evolucionado la web abierta a lo largo de los años.

Además, es innegable el papel que desempeñó WordPress al permitir que personas sin conocimientos técnicos pudieran formar parte de la web, facilitándoles la publicación y difusión de su contenido a través de Internet.

Espero que luego de ver Code for the People te animes y participes en ayudar a democratizar la web.

Hack the planet!

Deja un comentario

Script para ver paquetes de AUR comprometidos

Si son usuarios de Arch Linux, habrán escuchado que recientemente alguien logró acceder al Arch User’s Repository (AUR) y adoptó muchos paquetes huérfanos para modificarlos e inyectar código malicioso. Como lo hizo con muchos paquetes y durante un tiempo desconocido, es posible que tu equipo tenga instalados paquetes comprometidos. Una ventaja de todo este problema, es que el equipo de Arch publicó una lista oficial de paquetes que fueron víctimas de este ataque y me motivó a desarrollar un script para ver paquetes de AUR comprometidos

El script para ver paquetes de AUR comprometidos

Por esta razón, decidí hacer un script en Fish; si han leído mi blog antes, sabrán que uso Fish en mi consola y que la sintaxis de la terminal cambia un poco. Este script chequea el archivo oficial de paquetes comprometidos, valida que solo contenga texto y nombres de paquetes (para evitar que, si se compromete, te ataquen) y luego revisa tus paquetes instalados y los compara para ver si alguno de ellos está instalado en tu equipo.

#!/usr/bin/env fish

set URL "https://md.archlinux.org/s/SxbqukK6IA/download"

set installed (pacman -Qq)
set aur (pacman -Qqm 2>/dev/null)

# Download as plain text only; keep only valid-looking package names
set suspects (curl -fsSL "$URL" \
  | string match -r '^[a-z0-9][a-z0-9._+-]*$' \
  | sort -u)

set total (count $suspects)
set found_list
set i 0
set spinner "⠋" "⠙" "⠹" "⠸" "⠼" "⠴" "⠦" "⠧" "⠇" "⠏"
set spin_i 1

function draw
    set i $argv[1]
    set total $argv[2]
    set spin $argv[3]

    set width 35

    if test "$total" -eq 0
        set percent 0
        set filled 0
    else
        set percent (math -s0 "$i * 100 / $total")
        set filled (math -s0 "$i * $width / $total")
    end

    set empty (math -s0 "$width - $filled")

    printf "\r%s [" "$spin"
    printf "%s" (string repeat -n $filled "=")
    printf "%s" (string repeat -n $empty " ")
    printf "] %3d%% (%d/%d)" $percent $i $total
end

echo "Scanning suspect packages..."
echo ""

for pkg in $suspects
    set i (math "$i + 1")

    if contains -- "$pkg" $installed; or contains -- "$pkg" $aur
        set -a found_list "$pkg"
    end

    draw "$i" "$total" "$spinner[$spin_i]"

    set spin_i (math "$spin_i + 1")
    if test "$spin_i" -gt (count $spinner)
        set spin_i 1
    end

    sleep 0.005
end

echo ""
echo ""

echo "Installed suspect packages:"
echo "----------------------------"

if test (count $found_list) -eq 0
    echo "None"
else
    for p in $found_list
        echo "$p"
    end
end

Nota: Recuerda ejecutarlo con fish y no con bash.

Finalmente, si tienes algún script, simplemente elimínalo del sistema con pacman y mantén tu sistema seguro.

Y recuerda compartir este script con otros usuarios de Arch, o al menos infórmales sobre este problema para que estén protegidos.

Deja un comentario

Imagine DevOps: cuando la cultura de infraestructura también necesita reírse de sí misma

Hace poco me encontré con un video llamado «Imagine DevOps», una parodia basada en la famosa canción «Imagine» de The Beatles, pero llevada al mundo de DevOps: servidores, despliegues, monitoreo y esa eterna lucha entre desarrollo y operaciones. El video se presenta como una canción de DevOps, hecha “con disculpas a John Lennon”, con letra atribuida humorísticamente a “un rogue shell script” y publicada en YouTube.

¿Por qué ver Imagine Devops?

Lo divertido del video no está solo en la parodia musical, sino también en que aborda situaciones que muchos hemos vivido en carne propia. Quienes han trabajado con servidores, despliegues o infraestructura saben que el mundo DevOps está lleno de momentos absurdos: cosas que funcionan en local pero fallan en producción, pipelines que se rompen sin explicación, permisos que nadie recuerda haber cambiado, alertas que llegan justo cuando uno está por descansar, o servicios que deciden caerse en el peor momento posible.

Por eso este tipo de humor funciona, no hace falta explicar demasiado el chiste, porque si alguna vez has tenido que revisar logs a medianoche, reiniciar un servicio sin saber muy bien por qué volvió a funcionar, o decir la clásica frase “pero en mi máquina sí corre”, entonces entiendes perfectamente de qué se trata.

También me gusta porque recuerda que DevOps no es solo sobre herramientas, sino también sobre Docker, Kubernetes o CI/CD. Al final, DevOps también es cultura, comunicación y aprender a reducir el caos entre quienes desarrollan y quienes mantienen los sistemas vivos.

Imagine DevOps es una pequeña broma interna para gente de tecnología, pero también una forma de reírnos de nuestros propios traumas técnicos. Y eso siempre es sano.

Si trabajas en desarrollo, sistemas, infraestructura, soporte, QA o simplemente has sufrido alguna vez con un despliegue, vale la pena verlo. Probablemente te saque una sonrisa y, con suerte, te recuerde que no eres el único que ha peleado contra la producción.

Finalmente, si te gusta este tipo de videos, recuerda ver mi lista de música geek donde comparto la mejor música para geeks.

Deja un comentario