"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.
Top comments (0)