DEV Community: jose muñoz

¿Debería el desarrollo de software tener un control de acceso?

jose muñoz — Mon, 04 May 2026 00:43:26 +0000

Cada vez es más fácil escribir código.

Hoy alguien puede abrir un editor, describir lo que quiere en lenguaje natural, y obtener una aplicación funcional en minutos. Herramientas de IA, frameworks más amigables, plantillas, tutoriales infinitos. Entrar a programar nunca había sido tan accesible.

Y eso parece una buena noticia.

Pero esa facilidad trae una pregunta incómoda: si entrar es tan fácil, ¿la base de quienes entran también se vuelve más débil?

Hablo de fundamentos.

Mucha gente hoy aprende a programar logrando resultados antes de construir comprensión. Una API funciona, una página carga, una feature sale. Pero detrás de eso muchas veces faltan cosas más profundas: entender por qué falla algo, qué hace realmente una abstracción, qué implica una decisión de diseño, por qué cierto código escala mal o por qué se rompe en producción.

El conocimiento efímero de la asistencia con IA

Hay una diferencia importante entre entender algo en el momento y realmente aprenderlo.

Cuando trabajas con una herramienta de IA, muchas veces ocurre esto:

lees una solución
la reconoces
incluso puedes explicarla superficialmente

Y eso da la sensación de comprensión.

Pero esa sensación puede ser engañosa.

Porque no pasaste por el proceso que normalmente consolida el conocimiento: equivocarte, explorar alternativas, construir la solución paso a paso. En lugar de eso, recibiste una versión ya resuelta.

El resultado es un tipo de conocimiento frágil.

Sabes seguirlo, pero no sabes reconstruirlo.

Y esa diferencia se nota más adelante.

Cuando vuelves a enfrentarte a un problema similar, muchas veces aparece el mismo bloqueo. No porque no lo hayas visto antes, sino porque no lo internalizaste.

Sin esfuerzo cognitivo real —sin tener que recordar, fallar, ajustar— el cerebro no consolida bien la información. Lo que obtienes es reconocimiento, no dominio.

Puedes avanzar muy rápido… pero con una base que no necesariamente te sostiene cuando el problema cambia.

Vibecoding, “slop” y la ilusión de calidad

Con herramientas como el vibecoding, producir código funcional es extremadamente fácil con los suficientes tokens.

El problema es que “funcional” no es un buen indicador de calidad.

Hoy un agente puede generarte algo que:

corre
pasa un caso básico
cumple con lo que pediste

Pero eso no significa que sea buen código.

Puede ser:

difícil de mantener
inconsistente
ineficiente
frágil ante cambios
lleno de decisiones que nadie entiende

En otras palabras, puede ser slop… que funciona.

Y si no tienes criterio —lo que muchos llaman taste— o estándares claros, ese tipo de código no solo pasa, sino que se acumula.

Ahí es donde sí aparece una degradación real.

No porque la herramienta sea mala, sino porque elimina fricción sin reemplazarla por juicio.

Antes, llegar a una solución requería suficiente esfuerzo como para cuestionar partes del proceso. Hoy puedes saltarte ese proceso por completo.

El resultado es claro:

la barrera para producir código bajó… pero la barrera para producir buen código no.

Y cuando ambas se separan, lo que crece más rápido no es la calidad, es el volumen.

Entonces… ¿necesitamos gatekeeping?

No creo que la solución sea hacer la entrada más difícil.

Hacer más dura la entrada no garantiza mejores programadores. Solo garantiza menos acceso. Históricamente, mucha gente brillante entró precisamente porque el camino estaba abierto, no porque pasó un filtro elitista.

El problema es otro.

Nunca había sido tan fácil parecer productivo sin entender realmente lo que estás haciendo.

Y ahí es donde entra algo interesante.

Tal vez no estamos eliminando el gatekeeping. Tal vez solo lo estamos moviendo.

Antes, el filtro estaba al principio. Muchos no podían ni entrar.

Ahora, casi cualquiera puede empezar. Casi cualquiera puede construir algo que funcione. Pero el verdadero filtro aparece después, cuando el proyecto crece, cuando el comportamiento no es obvio, cuando el error no tiene una respuesta copiable, cuando hay que depurar, mantener, diseñar, decidir.

En ese momento, una base débil empieza a notarse.

Entonces quizá el nuevo gatekeeping no está en el acceso. Está en la profundidad.

No te filtra el editor. No te filtra el lenguaje. No te filtra la sintaxis.

Te filtra la realidad.

Cierre

La industria no tiene un problema de acceso. Tiene un problema de profundidad.

Algunas ideas las obtuve de este video por gonz:

Estamos optimizando para que más gente escriba código, pero no necesariamente para que más gente entienda sistemas.

Y esas dos cosas no son lo mismo.

El problema no es que ahora cualquiera pueda escribir código.

Es que ahora cualquiera puede crear código que nadie debería haber escrito.

Y quizá lo más peligroso no es eso.

Quizá lo más peligroso es que, al principio… funciona.

Sin Containers no hay paraíso.

jose muñoz — Wed, 05 Nov 2025 05:30:13 +0000

La primera vez que escuché hablar de Docker fue gracias a uno de mis mentores,fue como cuando alguien te recomienda una serie buenísima… y tú dices “sí, la voy a ver”, pero nunca la ves.

Hasta que un día, recibí una aplicación que debía mantener. El deploy se hacía con Docker.

En ese momento tenía dos caminos:

Seguir los comandos del manual sin entender nada.
Aprovechar la oportunidad para aprender el porqué detrás del cómo.

Después de un tiempo, decidí hacer lo segundo.

Docker no es solo una herramienta, es un superpoder.

El poder del encapsulamiento

Pero antes de seguir, vale la pena responder la gran pregunta:

¿qué es Docker realmente?

Imagina que tu aplicación es como un platillo de cocina.
Necesita ingredientes (dependencias), una receta (tu código) y una cocina con las mismas condiciones (el ambiente donde se ejecuta).

El problema es que cada computadora es una cocina distinta:
en una falta la harina, en otra el horno calienta demasiado, y en otra ni siquiera hay gas.

Docker soluciona eso creando una cocina portátil.

Empaqueta todo lo necesario —el código, las librerías / el ambiente dentro de un contenedor que puedes llevar y ejecutar donde sea.
Y lo mejor: siempre sale igual.

Técnicamente, Docker utiliza contenedores, entornos aislados que comparten el mismo kernel del sistema operativo, pero se comportan como si fueran máquinas independientes.
Eso los hace ligeros, rápidos de iniciar y consistentes entre desarrollo, pruebas y producción.

En resumen:

Docker te deja decirle al mundo “mi aplicación corre aquí”
y saber que también correrá allá.

Lo que realmente enseña Docker

Más allá de la magia técnica, Docker te enseña algo que todos los desarrolladores aprendemos tarde o temprano: los entornos importan.
No basta con que el código funcione, tiene que funcionar igual sin importar dónde se ejecute.

Y eso es precisamente lo que Docker hace tan bien.
Empaqueta tu aplicación, tus dependencias, tu configuración.

Lo que antes requería una lista de pasos, versiones y oraciones tipo:

Primero instala esto, luego corre esto otro

ahora se reduce a:
docker run calculadora

Y listo.
Simplemente funciona.

Antes de Docker:

“No sé por qué no te corre.”

“En mi máquina sí funciona.”

“Debe ser tu versión de Node.”

Después de Docker:

“Corre el contenedor y listo.”

Silencio… porque simplemente funciona.

Docker te da algo que muy poco he visto: consistencia.

Esa sensación de que lo que probaste localmente será exactamente lo que verás en producción.
Y eso, para cualquiera parecera un milagro.

Porque con Docker ya no hay “funciona en mi máquina”.
Hay algo mucho mejor:

“Funciona en todas.”

La cima inalcanzable-Perspectiva de un junior

jose muñoz — Wed, 06 Aug 2025 02:54:19 +0000

"No hay cima, solo nuevas montañas por escalar."

La industria tecnológica avanza constantemente. Cada año surge algo nuevo, sea lenguajes, frameworks, metodologías, herramientas. Para quienes estamos dando nuestros primeros pasos como desarrolladores, esta velocidad puede sentirse como una oportunidad... pero también como una carga.

Aprender constantemente: parte del oficio

Una de las primeras realidades que se asimilan al entrar en este mundo es que nunca vas a saberlo todo. Incluso después de meses o años de estudio, siempre hay una sensación de que falta algo por aprender. No importa cuánto tiempo lleves programando: siempre habrá algo nuevo que entender, una nueva herramienta que explorar, una nueva tendencia que analizar.

"Avanzar es obligatorio, pero descansar no siempre es una opción."

Esto no necesariamente es algo negativo. Es parte de la naturaleza del campo. Trabajar en tecnología implica comprometerse con el aprendizaje constante. No como una excepción, sino como una norma.

Una espada de doble filo

Esta dinámica tiene ventajas claras. Por un lado, siempre hay espacio para crecer, reinventarse y adaptarse. Es difícil quedarse estancado cuando el entorno te obliga a evolucionar.
Por otro lado, esta misma presión puede generar ansiedad o frustración. Especialmente cuando se siente que lo aprendido rápidamente queda desactualizado, o cuando el tiempo no alcanza para mantenerse al ritmo del cambio.

En ese sentido, la tecnología funciona como una espada de doble filo: te ofrece herramientas para avanzar y mejorar, pero también puede hacerte sentir que nunca es suficiente.

La experiencia no lo resuelve todo

"La sabiduría está en reconocer lo que no se sabe."

A medida que interactúas con profesionales más experimentados, descubres que incluso quienes llevan años en la industria enfrentan dudas similares.

El conocimiento profundo en ciertas áreas convive con brechas en otras.

La experiencia ayuda, sí, pero no elimina la complejidad del entorno ni garantiza certezas absolutas.

Aceptar eso es útil. No como resignación, sino como ajuste de expectativas. No se trata de dominarlo todo, sino de construir un criterio sólido para moverse con confianza entre lo que sí conoces y lo que aún no.

Lo técnico es solo una parte

También vale la pena recordar que no es solo saber escribir código. Un buen desarrolador es quien trabaja en equipo, comunica ideas con claridad, entiende las necesidades de negocio, mantiene sistemas, toma decisiones técnicas con impacto real.

En ese sentido, el aprendizaje no se limita a lo puramente técnico. Y a veces, saber en qué enfocarse (y qué ignorar por ahora) es más valioso que intentar absorberlo todo al mismo tiempo.

Conclusión: avanzar sin la necesidad de llegar

En tecnologia, no hay una cima definitiva. Siempre habrá una nueva herramienta, una mejor forma de hacer las cosas, o una tecnología emergente. Pero más que una desventaja, esto puede verse como una característica estructural del oficio.

La clave no está en intentar abarcarlo todo, sino en avanzar con criterio, mantener una mentalidad abierta y saber que estar aprendiendo constantemente no es señal de debilidad, sino parte del trabajo.

"El equilibrio entre técnica y criterio es lo que define a un profesional."

Herramientas con IA-Perspectiva de un junior

jose muñoz — Thu, 26 Jun 2025 16:52:03 +0000

La comodidad es enemiga del aprendizaje.

La premisa de las herramientas con IA —como Cursor, ChatGPT o V0— es amplificar tus habilidades. Pero ¿cómo amplificas algo que aún estás desarrollando?
Ahí es donde aparece el dilema para quienes estamos empezando.

Hace poco le pregunté a un compañero de la universidad por qué usaba estas herramientas, y su respuesta me pareció interesante:

"Me ahorra tiempo. Me ahorro el tener que aprenderlo."

Y sí, a corto plazo eso suena como un beneficio real: menos tiempo investigando, más productividad, menos frustración.
Pero a largo plazo, esa factura llega.

¿Por qué usar herramientas de IA desde el inicio puede ser desventajoso?

El beneficio inmediato es claro: desarrollo más rápido, bugs resueltos casi al instante.
Pero ¿quién entiende realmente el código?
¿Quién hizo el razonamiento para solucionar el problema?
Muchas veces, no fuiste tú, fue el agente.

Y aquí nace una pregunta clave, que define dos perfiles distintos en este nuevo ecosistema:

¿La IA es tu ayudante, o tú eres el ayudante de ella?

Usar herramientas con IA no es el problema.

El problema aparece cuando "desarrollas" sin tener idea de lo que está pasando.
Cuando el único que tiene el contexto real es el agente.
Todos caemos en esto en mayor o menor medida: la posibilidad de crear algo sin dominar la tecnología es demasiado atractiva, sobre todo cuando estás empezando y lo único que quieres es entrar al mercado laboral.

“Quien a hierro mata, a hierro muere.”

Para sorpresa de pocos, el vibecoding es muy común entre desarrolladores junior.
En la búsqueda de resultados, lo único que importa es que el código funcione, no por qué funciona.
Pero si solo te enfocas en eso y no en entender, tu crecimiento técnico se estanca.
Y mientras herramientas como Cursor entienden qué hacer y cómo hacerlo, tú seguirás siendo un junior.

¿Entonces, cómo crecer usando estas herramientas?

Recientemente vi una entrevista de un ingeniero distinguido de google, en donde menciona una frase con la que resoné.

Nunca me robaría a mi mismo de los fundamentos

Ese es el punto. Las herramientas están ahí para ayudarte, pero no para pensar por ti.
No se trata de no usarlas, sino de no delegar tu aprendizaje.