Soy de los que empezó a programar en editores de texto plano, sin IDEs, sin asistentes y sin ninguna red de seguridad.
Aprendí en un entorno mucho más austero que el de hoy: terminales puras, MS-DOS, redes sobre Novell NetWare y distintos sabores de Unix donde absolutamente todo se hacía por consola. Conexiones directas a servidores, documentación interminable y una buena dosis de conocimiento memorizado formaban parte del día a día.
Y gran parte de mi trabajo como administrador de sistemas sigue siendo así. En un servidor Linux remoto no hay interfaces gráficas que te salven: solo tienes una terminal, los logs y tu criterio.
Ahí sigo usando Vim o Nano sin ningún problema. Esa base no solo me resulta cómoda, me da independencia real. Sé que puedo diagnosticar y resolver problemas aunque todo lo demás falle.Pero precisamente porque sé hacerlo «a mano», en mi día a día no trabajo así.
Cuando desarrollo o gestiono sistemas más complejos, utilizo IDEs modernos, flujos de Git bien integrados, contenedores con Docker y, cada vez más, herramientas de inteligencia artificial. No porque no sepa hacerlo sin ellas, sino porque hacerlo de forma manual hoy en día es, objetivamente, menos eficiente.
No se trata de comodidad superficial. Se trata de coste.
Escribir boilerplate a mano, montar estructuras repetitivas o validar una query con múltiples JOINs y condiciones dinámicas ya no es donde está el valor real. Antes podía pasarme 20 o 30 minutos asegurándome de que todo estuviera correcto. Hoy, una herramienta de IA me da una base funcional en cuestión de segundos, y mi trabajo se centra en validarla, ajustarla y asegurarme de que encaja perfectamente en el contexto del sistema.
Eso no reduce mi aportación. Simplemente la desplaza hacia donde realmente importa.
La diferencia no está en la habilidad, sino en cómo usas tu tiempo
Hay una idea bastante extendida, y equivocada, de que hacer todo manualmente te convierte en un mejor profesional.
No necesariamente.
Conocer los fundamentos es imprescindible. Poder desenvolverte en un entorno sin ayudas sigue siendo una habilidad crítica. Pero insistir en resolver manualmente tareas que hoy están ampliamente automatizadas no demuestra mayor dominio técnico: demuestra una mala asignación del tiempo.
Cada minuto que inviertes en trabajo mecánico es un minuto que no dedicas a:
- Entender mejor el problema
- Mejorar la arquitectura
- Reducir complejidad real
- Anticipar posibles fallos
- O aportar valor real al negocio
La diferencia entre un desarrollador productivo y uno que simplemente «trabaja mucho» cada vez tiene menos que ver con cuánto código escribe y más con cómo decide usar su tiempo.
La IA no te hace mejor, pero sí te hace más eficiente
La inteligencia artificial no es magia. No toma decisiones por ti, no entiende el contexto completo del proyecto y tampoco sustituye el criterio técnico.
Pero sí elimina fricción innecesaria.
Reduce drásticamente el coste de tareas repetitivas:
- Generar estructuras de código estándar
- Sugerir refactorizaciones razonables
- Construir consultas complejas
- Explorar alternativas rápidamente
El resultado no es que el trabajo desaparezca, sino que cambia de naturaleza. Pasas de producir todo desde cero a iterar, validar y decidir con mucha mayor velocidad.
Y ahí es donde la experiencia de años sigue siendo insustituible.
El problema no es la herramienta, es el orgullo
He visto a buenos profesionales quedarse atrás no por falta de capacidad, sino por una resistencia que cuesta justificar.
«El que sabe de verdad no necesita esas herramientas.»
Es una frase peligrosa.
Porque convierte una preferencia personal en una supuesta virtud técnica. Y no lo es. Rechazar herramientas que reducen fricción sin eliminar el pensamiento crítico no te hace más riguroso. Simplemente te hace más lento.
Y en un entorno donde la complejidad sigue creciendo, ser más lento tiene consecuencias concretas:
- Entregas más tarde
- Iteras menos
- Cometes más errores por fatiga
- Y pierdes capacidad de adaptación
No usar estas herramientas no es una postura neutral. En muchos casos, es una desventaja competitiva que uno mismo se impone.
La ventaja real de venir de la «vieja escuela»
Paradójicamente, quienes venimos de ese entorno austero somos los que más deberíamos aprovechar estas herramientas.
Sabemos exactamente qué problema están resolviendo.
Hemos vivido lo que cuesta depurar a base de logs, navegar documentación durante horas o construir soluciones desde cero sin ninguna referencia. Por eso, cuando una herramienta reduce ese coste, no la vemos como una amenaza, sino como lo que realmente es: una mejora objetiva en nuestro flujo de trabajo.
La clave no es depender de ellas. Es saber usarlas con criterio.
Ahora somos administradores y desarrolladores con esteroides
Las herramientas modernas no nos hacen automáticamente mejores profesionales. Pero sí hacen algo mucho más importante: reducen el coste de hacer bien el trabajo.
Rechazarlas por purismo o por nostalgia no preserva ninguna esencia del oficio. Solo añade fricción innecesaria.
Seguir siendo capaz de abrir Vim en un servidor remoto y resolver un problema desde cero sigue siendo valioso. Pero elegir hacerlo siempre, cuando existen alternativas más eficientes, no es disciplina técnica. Es ineficiencia disfrazada.
Hoy el valor ya no está en cuánto sufres para llegar a una solución. Está en la calidad de las decisiones que tomas y en la velocidad con la que puedes iterar sobre ellas.
Yo sigo siendo perfectamente capaz de trabajar sin red de seguridad. Pero precisamente porque sé hacerlo, elijo no hacerlo cuando no tiene sentido.
Eso, también, forma parte del oficio.