DEV Community: Solaris PKN

Orquestar, Auditar, Editar: del vibe coding a la programación consciente

Solaris PKN — Mon, 07 Sep 2026 02:44:48 +0000

"Si el conocimiento no se comparte, muere."

Veinte minutos contra un mes

En veinte minutos, Codex hizo lo que a mí me había llevado un mes.

Le pedí que creara un entorno de prueba, copiara uno de mis proyectos y empezara a revisar vulnerabilidades y oportunidades de optimización. El agente recorrió el repositorio, creó archivos, modificó otros, eliminó lo que consideró innecesario y reorganizó partes de la estructura.

El resultado era impresionante. También se sentía profundamente intrusivo.

No porque la herramienta hubiera hecho algo que yo no le había permitido, sino porque avanzó más rápido de lo que mi cabeza podía acompañar. Mientras yo intentaba entender una decisión, el agente ya había tomado diez más. Al final recibí un resumen correcto, un proyecto transformado y una sensación inesperada: vacío.

Yo había obtenido el resultado, pero no había acompañado su construcción.

Entonces me hice una pregunta que todavía me acompaña:

¿Estoy usando la IA para aprender y ampliar mis capacidades, o para reemplazar el proceso que me permitía aprender?

Para entender por qué esa pregunta me afectó tanto, hay que volver al chico que desarmaba todo.

El chico que aprendía rompiendo cosas

Nunca tuve demasiadas oportunidades económicas. Desde chico, la vida no me regaló cursos, laboratorios ni mentores. Pero había algo que nadie podía quitarme: la curiosidad.

Así terminé en el mundo de la infraestructura IT. No fue por un título universitario ni porque alguien me marcara un camino. Fue por necesidad, terquedad y amor por la tecnología.

Desarmaba computadoras para entender cada componente.
Configuraba y desconfiguraba routers hasta aprender a recuperarlos.
Probaba switches, VLAN, topologías y protocolos de red.
Instalaba Windows, Linux, dual boots y servidores.
Montaba servidores de juegos para mis amigos.
Levantaba Apache, peleaba con Cloudflare y migraba servicios buscando la mejor relación entre costo y rendimiento.

Cada necesidad abría una investigación. No buscaba solamente una solución: intentaba descubrir qué posibilidades, riesgos y dependencias rodeaban esa solución.

Mi mentor era la documentación, el error y la obligación de arreglar lo que yo mismo había roto.

La paternidad y el conocimiento compartido

En 2026 me enteré de que seré padre.

Durante mucho tiempo pensé que publicar lo que aprendía era regalar una ventaja que me había costado noches sin dormir. El conocimiento era interno, casi una propiedad privada. Pero la paternidad me obligó a mirar esa idea desde otro lugar:

¿De qué sirve acumular conocimiento si muere conmigo?

Desde junio empecé a construir una infraestructura virtual donde documentar investigaciones, configuraciones, errores y aprendizajes. Dejé de atesorar conocimiento y empecé a sembrarlo.

La IA tuvo un papel importante en ese cambio. Para alguien que aprendió casi siempre solo, se convirtió en una segunda voz: una forma de contrastar ideas, atravesar inseguridades y formular en voz alta preguntas que antes quedaban encerradas en mi cabeza.

No quería un oráculo ni un jefe. Quería un interlocutor.

Mi primer método: la IA como manual, yo como constructor

Durante mucho tiempo usé ChatGPT, Gemini, Claude o DeepSeek como si fueran manuales interactivos. Les pedía una estructura, un fragmento de código o una explicación; comparaba respuestas y después llevaba el resultado a mi entorno manualmente.

Mi flujo era más o menos así:

Describía el problema y pedía una propuesta.
Contrastaba la respuesta con otra IA o con documentación oficial.
Creaba las carpetas y los archivos en mi máquina.
Integraba el código en el lugar correspondiente.
Ejecutaba el proyecto y leía los errores.
Corregía, reorganizaba y volvía a probar.
Revisaba datos sensibles, dependencias y archivos redundantes.

La IA entregaba texto. Yo tocaba el sistema.

Ese método era lento y podía introducir errores manuales. Copiar código tampoco equivale automáticamente a comprenderlo: uno puede copiar de manera tan pasiva como puede aceptar el resultado de un agente. Pero el trabajo manual producía algo valioso: más puntos de contacto con el proyecto.

Al crear una carpeta, registraba su ubicación. Al integrar una función, veía qué importaba y quién la consumía. Al ejecutar un comando, descubría qué dependencias necesitaba. Cuando algo fallaba, tenía que leer el log, volver sobre mis pasos y construir un modelo mental del sistema.

En ese recorrido aprendí metodologías que ni siquiera sabía que existían. Descubrí patrones, herramientas, validaciones y riesgos que no formaban parte de mi pregunta inicial.

Y más de una vez encontré algo que ninguna IA había señalado: una contradicción con la intención original, un archivo histórico que todavía cumplía una función, una variable sensible, una dependencia implícita o un comportamiento que solo aparecía en mi entorno real.

La IA puede procesar muchísimo contexto, pero no posee automáticamente toda la historia que yo tengo con el proyecto. Tampoco conoce una intención que nunca expresé. Por eso la auditoría humana sigue siendo necesaria.

Leer un libro no es construir una casa

La comparación que mejor representa esta diferencia no es humano contra máquina. Es teoría contra práctica.

El vibe coding se puede parecer a leer un libro sobre cómo se construye una casa. La IA hace el trabajo y después puede explicarme qué modificó, qué patrón utilizó y por qué tomó cada decisión. Esa explicación puede ser excelente. Puedo leerla, comprenderla e incluso repetirla.

Pero sigo recibiendo una construcción ya resuelta.

Leer que una pared necesita cimientos no es lo mismo que nivelar el terreno. Leer por qué se usa determinado material no es lo mismo que colocarlo, descubrir que no encaja y tener que corregirlo. La teoría transmite conceptos; la práctica construye criterio operativo.

Cuando copio e integro manualmente, o cuando uso una IA para codificar un sector específico y después lo audito, dejo de ser solamente lector. Tengo que relacionar lo nuevo con lo que ya existe, ejecutar, interpretar resultados y decidir qué hacer cuando la realidad contradice la explicación.

Ahí aparece el aprendizaje que más valoro:

Descubrir una metodología porque tuve que aplicarla.
Entender una dependencia porque rompí su integración.
Recordar una ruta porque tuve que crearla y recorrerla.
Detectar un supuesto equivocado porque el resultado real no coincidió con lo prometido.
Encontrar un problema que la IA no vio porque yo conocía mejor la intención o la historia del proyecto.

La teoría importa. Sin teoría podemos repetir errores sin entenderlos. Pero leer el resumen de una práctica que realizó otro no produce la misma experiencia que participar en ella.

Y participar no exige escribir cada carácter con mis dedos. También es práctica dividir el problema por sectores, pedir una implementación acotada, revisar el diff, ejecutar las pruebas, intervenir y corregir antes de pasar al siguiente sector.

La práctica comienza donde termina la aceptación pasiva.

Por qué el vibe coding puede ser más agresivo

Los agentes actuales pueden leer un repositorio, ejecutar comandos y modificar directamente el sistema de archivos. La diferencia frente a copiar manualmente no es solamente de velocidad: es una diferencia de superficie de acción.

Cuando trabajo manualmente, cada cambio pasa por un cuello de botella: yo. Para crear veinte archivos tengo que atravesar veinte decisiones. Ese límite es ineficiente para producir, pero puede ser muy valioso para aprender.

En cambio, un agente puede recorrer el repositorio completo en minutos. Puede cambiar una configuración, actualizar una dependencia, refactorizar una función y eliminar un archivo antes de que yo haya terminado de comprender la primera modificación.

Cuanto más vaga sea la instrucción —"revisá todo", "optimizalo", "arreglá lo que encuentres"— mayor puede ser la intrusión. No necesariamente porque el agente actúe mal, sino porque le cedimos demasiadas decisiones al mismo tiempo.

Eso es lo que vuelve peligroso al vibe coding puro: no que la IA escriba código, sino que la cantidad y la velocidad de sus decisiones superen nuestra voluntad o capacidad de revisarlas.

También entendí que Codex y el vibe coding no son sinónimos. Una herramienta agéntica puede trabajar con límites, permisos, diffs, puntos de control y revisiones. Se pueden inspeccionar los cambios antes de confirmarlos y decidir qué conservar, revertir o corregir.

El problema no es que el agente tenga manos. El problema aparece cuando nosotros dejamos de participar en la práctica.

Tres formas de trabajar con IA

No tenemos que elegir entre copiar absolutamente todo o entregar el proyecto entero a una máquina.

Dimensión	Vibe coding pasivo	Integración manual	Agente orquestado por sectores
Cómo se trabaja	Doy una intención amplia y recibo el resultado	Creo e integro cada pieza	Delego áreas pequeñas y avanzo por etapas
Qué veo	Principalmente el resultado y su explicación	Cada archivo, comando y error	Planes acotados, diffs, logs y pruebas por sector
Tipo de aprendizaje	Mayormente teórico	Práctica directa	Práctica supervisada
Cómo valido	Acepto si parece funcionar	Ejecuto y reviso personalmente	Defino criterios, el agente prueba y yo audito la evidencia
Ventaja	Velocidad inmediata	Máxima exposición al proceso	Velocidad sin perder completamente el contacto
Riesgo	Cambios opacos y dependencia	Lentitud y errores manuales	Creer que una revisión parcial cubrió todo
Responsabilidad final	Mía	Mía	Mía

El método manual sigue teniendo una ventaja pedagógica real. Cuanto más nuevo es un tema para mí, más útil resulta recorrerlo paso a paso. La fricción me obliga a observar cosas que una automatización podría resolver sin enseñármelas.

Pero trabajar con un agente por sectores también es práctica. Puedo pedirle que analice solamente la carga de datos, después auditarla; luego pasar a la interfaz, revisar su comportamiento; finalmente comprobar pruebas, seguridad y despliegue. No pulso cada tecla, pero participo en cada decisión importante.

Automatizar una parte del trabajo no es lo mismo que delegar la comprensión completa.

Mi método actual: Orquestar, Auditar, Editar

Después de aquella primera sensación de vacío entendí que no necesitaba rechazar los agentes. Necesitaba aprender a dirigirlos.

1. Orquestar

Antes de permitir cambios, defino:

Qué problema quiero resolver.
Qué sector del proyecto está dentro del alcance.
Qué comportamiento, diseño o contenido debe preservarse.
Qué riesgos deben revisarse.
Qué acciones requieren mi aprobación.
Qué pruebas demostrarán que esa etapa está terminada.

Una instrucción como "optimizá el proyecto" entrega demasiadas decisiones implícitas. Prefiero dividir: primero diagnosticar, después proponer, luego modificar un sector, auditarlo y recién entonces continuar.

Orquestar significa conservar la intención y el orden del aprendizaje.

2. Auditar

Antes, durante y después de cada cambio reviso:

El estado inicial del repositorio.
El plan propuesto por la IA.
Los archivos creados, modificados y eliminados.
El diff completo, no solamente el resumen.
Los resultados reales de las pruebas.
Los cambios de dependencias y configuración.
Los datos sensibles, permisos y superficies de seguridad.
Aquello que la IA no pudo verificar.
Aquello que la IA ni siquiera consideró revisar.

Pido explicaciones, pero no confundo explicación con evidencia. Comparo lo que la IA afirma con el código, los logs, la documentación y el comportamiento real.

Auditar transforma teoría en práctica porque me obliga a comprobar si el relato coincide con el sistema.

3. Editar

Editar no significa necesariamente pulsar cada tecla. Significa conservar la autoridad para:

Corregir una decisión.
Rechazar un cambio innecesario.
Pedir una solución más pequeña.
Dividir una modificación demasiado amplia.
Recuperar una pieza eliminada por error.
Cambiar manualmente lo que necesita contexto humano.
Volver a ejecutar las validaciones antes de aprobar.

Si no puedo explicar razonablemente qué cambió, por qué cambió y qué evidencia demuestra que funciona, todavía no terminé.

Editar significa intervenir en la construcción y asumir la responsabilidad.

Cuándo prefiero cada método

No todos los trabajos persiguen el mismo objetivo.

Si estoy explorando una tecnología nueva, aprendiendo una arquitectura o tratando de comprender un error, prefiero copiar, integrar o modificar en pasos pequeños. Quiero sentir la fricción, recorrer los archivos y cometer algunos errores controlados. En ese contexto, tardar más no siempre es una pérdida: muchas veces es el precio de convertir teoría en experiencia.

Si ya conozco el terreno y enfrento una tarea repetitiva, una migración extensa o una auditoría amplia, un agente puede ahorrarme horas. Pero divido el trabajo por sectores, le doy límites, le exijo evidencia y reviso el resultado de cada etapa.

Y si la tarea afecta producción, seguridad, datos sensibles o decisiones difíciles de revertir, la velocidad nunca reemplaza los controles.

Mi pregunta dejó de ser "¿la IA debería tocar mis archivos?". Ahora pregunto:

¿Qué parte de este trabajo quiero automatizar y qué parte necesito practicar para aprender?

Para el chico que desarmaba computadoras

Si estás aprendiendo como aprendí yo —sin demasiado presupuesto, investigando a los golpes y construyendo con lo que tenés— no dejes que la comodidad te robe el conocimiento.

Usá la IA. Pedile teoría, estructuras, alternativas, código y explicaciones. Usá agentes cuando la escala lo justifique. Pero mantenete dentro de la práctica:

Dividí el proyecto en sectores comprensibles.
Revisá cada archivo que se crea o elimina.
Leé el diff completo.
Buscá en la documentación oficial.
Preguntá qué supuestos tomó la IA.
Exigí pruebas y revisá sus resultados.
Investigá lo que no entendés.
Buscá también aquello que la IA no buscó.
Conservá una forma segura de volver atrás.

Porque la IA puede encontrar errores que nosotros no vemos, pero nosotros también podemos encontrar errores, intenciones perdidas y riesgos que la IA no detectó.

El objetivo no es demostrar que podemos hacer todo sin ayuda. Es evitar que la ayuda nos vuelva incapaces de comprender lo que construimos.

La conclusión que quiero dejar

El vibe coding puede ser un paso atrás cuando nuestro objetivo es aprender y terminamos leyendo explicaciones sobre cambios que nunca atravesamos en la práctica. También puede producir software funcional a una velocidad extraordinaria. Ambas cosas pueden ser ciertas.

La programación asistida puede ser un paso adelante si usamos esa velocidad para explorar más, practicar mejor y ampliar lo que somos capaces de construir sin entregar nuestras decisiones.

Hoy no creo que la diferencia esté solamente en quién pulsa las teclas. Creo que está en quién participa en la construcción, quién audita la evidencia y quién responde por las consecuencias.

La IA puede ofrecer la teoría y ejecutar parte de la práctica. El criterio se forma cuando nosotros intervenimos.

Si voy a dejarle un ejemplo a mi hijo, no quiero que sea el de alguien que rechazó las herramientas nuevas por miedo ni el de alguien que les entregó su criterio por comodidad. Quiero mostrarle que se puede avanzar más rápido sin dejar de preguntar, practicar, aprender y hacerse responsable.

Desde junio de 2026 publico lo que aprendo porque entendí algo sencillo: el conocimiento atesorado termina muriendo. El conocimiento que se explica, se pone en práctica, se corrige y se comparte permanece vivo.

Si esta experiencia te resonó, compartila. Y antes de aceptar el próximo cambio generado por IA, preguntate:

¿Estoy practicando con una herramienta o solamente leyendo lo que la herramienta hizo por mí?

La experiencia, las decisiones y la responsabilidad son mías. La IA me ayudó a ordenar y editar las palabras.

StackBlitz + GitHub: The Missing Link in the Developer Portfolio

Solaris PKN — Fri, 28 Aug 2026 00:58:21 +0000

If I can open a repository, run it, and work with it... why can't I simply keep it linked to my profile?

🔗 The problem: GitHub gets in... but it doesn't stay

I really like StackBlitz for one pretty simple reason: you grab a GitHub repository, open it, and within seconds you have a working development environment running directly in your browser.

No installations.

No manual cloning.

No local environment to set up.

You open the project and you're done. 🚀

For compatible repositories — for example, projects built with Astro — it works incredibly well.

Here's a real example:

stackblitz.com

The problem comes afterward.

Because the project you just opened, ran, and even modified inside StackBlitz is basically ephemeral from the perspective of your public profile.

You can use it.

You can share the link.

You can work on it.

But you can't say:

“I want this repository to permanently appear among my projects.”

And that's where the experience starts to feel a little off.

🧪 Obviously, I tried to find a workaround

Before reaching this conclusion, I tried several things because I thought:

“There has to be some hidden option I'm missing.”

But no. 😅

🔄 Syncing a project

If you create a project directly inside StackBlitz, there isn't a really convenient workflow for later turning it into a synchronized representation of a GitHub repository.

🍴 Creating an internal fork

If you open a repository directly from GitHub, there also isn't a simple option like:

Add to my projects

Show on my profile

The project works, but it stays disconnected from your public identity inside StackBlitz.

📚 Using Collections

And this was the solution that made the most sense to me.

StackBlitz already has Collections, which are conceptually perfect for organizing projects.

The problem is that they're designed around projects that live inside StackBlitz.

I can't simply create something like:

SolarisPKN Projects
├── SolarisPKN-Labs
├── SolarisPKN-Stats
├── SolarisPKN-Transport
└── Other repositories

and point each entry to its corresponding GitHub repository opened through StackBlitz.

And that's where the question that ultimately led me to write this appears:

If StackBlitz already knows how to open the repository, why does it need to own the project in order to show it on my profile?

💡 I don't want another GitHub

I think this point is important.

I'm not proposing that StackBlitz clone all of our repositories and store them internally.

That would duplicate infrastructure without much reason.

GitHub already stores the code.

Git already handles versioning.

GitHub already manages permissions, branches, commits, releases, and the entire history.

I don't need StackBlitz to become GitHub.

What I want is much simpler:

Let StackBlitz also act as an index for the projects it can already run.

🗂️ An index, not a mirror

The solution could be extremely lightweight.

If my StackBlitz account is connected to GitHub and I open a compatible repository, StackBlitz could let me mark it as:

⭐ Show on my profile

Internally, it would barely need to store anything beyond metadata.

Conceptually, it could be as simple as:

{
  "projects": [
    {
      "provider": "github",
      "repository": "SolarisPKN/SolarisPKN-Labs",
      "featured": true
    },
    {
      "provider": "github",
      "repository": "SolarisPKN/SolarisPKN-Stats",
      "featured": true
    }
  ]
}

That's it.

No need to duplicate the repository.

No need to store hundreds of megabytes.

No need to maintain two sources of truth.

GitHub remains the source of the project.

StackBlitz simply stores the reference.

⚙️ What happens when someone opens the project?

Exactly what happens today.

StackBlitz Profile
        │
        ▼
Indexed Project
        │
        ▼
GitHub Repository
        │
        ▼
StackBlitz WebContainer
        │
        ▼
Runnable Environment

The difference is that now there's a persistent layer that makes the project discoverable from the developer's profile.

The code still lives on GitHub.

StackBlitz simply provides the interactive experience.

🧠 And I think this would be better for StackBlitz too

There's something a little paradoxical about the current workflow.

One of StackBlitz's most powerful features is precisely its ability to run external projects...

...but afterward, those same projects practically disappear from the platform's social ecosystem.

That significantly limits the value of the public profile.

A developer could have:

30 public repositories on GitHub
15 projects perfectly compatible with StackBlitz
several fully functional web projects

and still open their StackBlitz profile and find it practically empty.

🤨

From a technical standpoint, it works.

From a Developer Experience standpoint, it feels incomplete.

🌐 GitHub as the backend, StackBlitz as the experience

I think that's the core idea.

Don't turn StackBlitz into another repository hosting platform.

Instead, make better use of the relationship between both platforms.

GitHub

It handles:

Code
Git
Commits
Issues
Releases
Branches
Permissions
History

StackBlitz

It handles:

Running the project
Presenting it
Letting people try it
Creating an instant development environment
Turning a repository into an interactive experience

And between the two, only one thing is missing:

🔗 The index

A minimal layer that says:

These are the repositories this developer wants to show on their profile.

Nothing more.

🚀 The profile could become a real developer portfolio

And this is where I think the feature would go from being a small UX detail to something much more interesting.

Today, many developer profiles are fragmented.

You have:

GitHub → Code

LinkedIn → Professional profile

Portfolio → Selected projects

StackBlitz → Runnable demos

Vercel / Netlify → Deployments

But StackBlitz has something pretty special:

it can turn code into a runnable experience almost instantly.

If it also allowed external repositories to be indexed on a profile, that profile could become something like:

An interactive developer portfolio.

You wouldn't just show a card saying you built a project.

Someone opens it.

They inspect the code.

They run the project.

They modify it.

They test it.

All from the browser.

That's far more valuable than a simple screenshot.

🧩 Even Collections would make much more sense

Imagine being able to create:

🌐 Web Projects

SolarisPKN-Labs
Portfolio
Astro experiments

⚙️ Backend & Automation

Workers
APIs
Automations

🧪 Experiments

Prototypes
Tests
Concepts

And each item would simply reference an external repository.

At that point, Collections would stop organizing only projects that live inside StackBlitz and start organizing the developer's actual work.

To me, that's a huge difference.

🎯 Conclusion

StackBlitz has already solved the hard part.

It can take external code, spin it up inside a WebContainer, and give you a complete development environment directly in the browser.

What's strange is that a much simpler feature is still missing afterward:

The ability to save that project as a reference on your profile.

I don't need them to duplicate my code.

I don't need extra storage.

I don't need another Git system.

I just need to be able to say:

“This repository is mine, you already opened it successfully, and I want to show it on my profile.”

An index.

A reference.

A button.

Done. 🔗

Sometimes a huge UX improvement doesn't require a huge architecture behind it.

And I think this is one of those cases.

💬 What do you think?

If you use StackBlitz together with GitHub, you've probably run into this separation at some point.

Would you use your StackBlitz profile as a developer portfolio if you could add your GitHub repositories directly to it?

I would.

And I'd probably end up using StackBlitz a lot more because of it. 🚀