IA como co-developer: ¿estamos delegando o colaborando?

En 2026, muchos developers ya integran herramientas de IA en su flujo de trabajo. Pero hay una diferencia enorme entre usar IA como autocompletado glorificado y usarla como un verdadero co-developer. Conversé con José Álvarez, CTO de Pernix, sobre dónde está la línea entre delegar y colaborar.

El amigo antes que el CTO

A José Álvarez lo conozco desde hace años. Fuimos vecinos, hemos conversado de tecnología en contextos muy distintos, y él me ayudó bastante en el desarrollo de mi carrera profesional cuando yo todavía estaba buscando rumbo. Por eso esta entrevista es especial — no es traer a un CTO con experiencia para que opine, es traer a un amigo que sé que piensa estos temas con profundidad.

José es de esas personas que en tecnología siempre va tres o cuatro pasos adelante. Su título dice CTO de Pernix, pero yo lo defino distinto: José es un solucionador de problemas. Te soluciona lo que sea — desde una arquitectura compleja hasta cómo abordar una conversación difícil con un cliente.

Le pasé 5 preguntas sobre IA como co-developer. Sus respuestas son las que están abajo, con mi punto de vista intercalado en cada una.

1. ¿Cómo ha cambiado el día a día del developer?

Le pregunté: En tu experiencia liderando equipos en Pernix, ¿cómo ha cambiado concretamente el día a día de un developer con la llegada de herramientas de IA como Copilot, Claude o Cursor?

José:

El día a día de los desarrolladores ha cambiado de manera significativa. Hoy se invierte mucho menos tiempo en escribir código desde cero o en definir cómo abordar una solución desde un nivel básico. El enfoque ha evolucionado hacia aspectos más estratégicos: arquitectura, estructuración del sistema y calidad del producto final.

Además, los desarrolladores que trabajan en aplicaciones orientadas al cliente han asumido un rol más integral, cercano a una combinación entre Product Owner, Product Manager y Project Manager. Esto se debe a la necesidad de definir con precisión los requerimientos: la calidad de los resultados generados por la IA depende directamente de la claridad del contexto que se le proporcione.

Mi lectura:

Estoy de acuerdo con que el rol se vuelve más estratégico, pero le agregaría una pieza: la spec como artefacto formal. Estoy usando GitHub Spec Kit en mi propio sitio y en proyectos del equipo, y la spec es el contexto que necesita la IA para producir algo útil. Si el developer no aprende a escribir specs, se va a quedar en autocompletar.

Y hay una capa más profunda que José insinúa cuando habla de "definir con precisión los requerimientos": antes de saber pedirle algo a la IA, hay que saber qué estás pidiendo. Si no sabés qué querés construir, ¿cómo vas a construir algo que ni vos mismo entendés? La IA no resuelve la falta de claridad — la amplifica. Por eso el rol cambia: no es que el developer escriba menos código, es que ahora tiene que pensar mejor antes de la primera línea.

2. ¿Dónde brilla la IA y dónde genera más trabajo?

Le pregunté: ¿Hay tipos de problemas donde la IA realmente brilla como "solucionadora", y otros donde todavía genera más trabajo del que ahorra?

José:

La inteligencia artificial ha demostrado ser altamente efectiva en una amplia gama de tareas que tradicionalmente realizaban los desarrolladores. Gracias a su entrenamiento con grandes volúmenes de código, hoy es capaz de acelerar significativamente la construcción de soluciones, incluso acercándose a productos listos para mercado en tiempos muy reducidos.

Sin embargo, más que evaluar si la IA resuelve o no ciertos problemas, el factor determinante es cómo se utiliza. La calidad de los resultados está directamente relacionada con la calidad del contexto y las instrucciones proporcionadas. El valor no radica únicamente en la capacidad de la herramienta, sino en la habilidad del desarrollador para guiarla de forma efectiva dentro de un proceso bien definido.

Mi lectura:

La frase clave de José es "cómo se utiliza". Yo lo estoy viviendo ahora con MCP servers conectados a Copilot leyendo infraestructura en Azure y generando Terraform automáticamente. Cuando le doy a la IA acceso al estado real — no solo el código, sino los recursos vivos — pasa de ser un autocomplete a un colaborador que realmente entiende el sistema.

Sin ese contexto, las mismas herramientas producen alucinaciones costosas: nombres de recursos que no existen, configuraciones que rompen el cluster, módulos de Terraform que parecen razonables pero referencian APIs deprecadas. El cambio no está en el modelo — está en cuánto contexto le diste antes de hacerle la pregunta.

3. Integrar IA en clientes complejos sin sacrificar calidad ni seguridad

Le pregunté: Para clientes en Estados Unidos que manejan productos con alta complejidad, ¿cómo estás integrando IA en el proceso de desarrollo sin sacrificar calidad o seguridad?

José:

Para nuestros clientes en Estados Unidos, la adopción de IA ha representado un punto de inflexión. La productividad de los equipos ha aumentado considerablemente, lo que a su vez ha elevado las expectativas de entrega. Procesos que antes requerían semanas hoy se ejecutan en cuestión de minutos.

La integración se da en dos frentes. Por un lado, dentro del proceso de desarrollo: generación de código, pruebas, documentación, refactorización. Por otro, dentro de los propios productos: detección de errores, identificación de vulnerabilidades, análisis automatizados.

Para garantizar calidad y seguridad, todo el código generado pasa por revisiones humanas rigurosas y se apoya en estándares reconocidos como OWASP. Estos lineamientos pueden integrarse directamente en revisión de pull requests o en pipelines automatizados, permitiendo detectar riesgos antes de que lleguen a producción. El desafío principal no es la herramienta — es su uso adecuado. La combinación de velocidad con disciplina en calidad y seguridad es lo que genera valor sostenible.

Mi lectura:

Lo que José describe — OWASP integrado en revisión de pull requests — es exactamente el patrón que estamos implementando del lado de banca. Pero le agregaría una distinción que me parece crítica: la diferencia entre tener OWASP como guía moral y como gate automático es enorme. Si no falla el build, no existe.

Spec-driven security significa que la política vive en un archivo versionado en el repo, no en un wiki que nadie lee. El pipeline aplica la regla siempre, independientemente de quién o qué escribió el código. Esa es la única forma honesta de combinar velocidad con seguridad cuando la IA está generando código a escala: el contrato del pipeline no cambia, solo cambia quién o qué entra al embudo.

4. Las habilidades que se vuelven (más y menos) importantes

Le pregunté: ¿Qué habilidades creés que un developer necesita desarrollar ahora que la IA escribe código? ¿Qué se vuelve más importante y qué se vuelve menos relevante?

José:

Las habilidades requeridas están evolucionando, y en muchos casos la formación tradicional no avanza al mismo ritmo. Sigue siendo importante comprender programación, arquitectura y patrones de diseño, pero el énfasis en la ejecución técnica pura está disminuyendo — la IA puede encargarse de gran parte de esas tareas.

En contraste, adquieren mayor relevancia las habilidades relacionadas con el entendimiento del producto y la generación de valor: toma de decisiones, análisis de requerimientos, evaluación de soluciones, interpretación de resultados. Y se vuelven fundamentales los soft skills: comunicación, pensamiento estructurado, capacidad de proporcionar contexto claro y preciso.

El desarrollador más efectivo será aquel que logre guiar a la IA de manera eficiente, estructurando información, documentando procesos y estableciendo estándares que minimicen errores y maximicen la calidad de los resultados.

Mi lectura:

Yo lo resumiría más simple: la habilidad que más sube de valor es saber pensar bien. Antes la podías ocultar detrás de saber muchos frameworks — si dominabas React, Spring, Kubernetes o Terraform, había un piso de empleabilidad garantizado. Hoy ya no. La IA sabe los frameworks, y los aprende más rápido que cualquiera.

Lo que la IA no sabe — y no parece que vaya a saber pronto — es qué problema realmente estás tratando de resolver. Para eso hace falta humano. El developer que sabe leer un negocio, hacer las preguntas correctas, distinguir el síntoma de la causa, va a ser cada vez más valioso. Y el que solo sabe ejecutar tickets, cada vez menos.

5. Consejo para un developer junior en 2026

Le pregunté: Si pudieras darle un consejo a un developer junior que está empezando su carrera en 2026, ¿cuál sería?

José:

Para un desarrollador que está iniciando en 2026, aprender herramientas de IA no es opcional, es esencial. Hay que experimentar activamente con las distintas plataformas, entender su funcionamiento en la práctica y desarrollar criterio sobre cuándo y cómo usarlas.

Es clave mantenerse actualizado de forma constante. La evolución en este campo es acelerada — hay cambios relevantes semana a semana. Seguir fuentes confiables, líderes de opinión y comunidades técnicas permite estar al día con nuevas herramientas, enfoques y mejores prácticas.

La capacidad de adaptación y aprendizaje continuo se convierte en una de las habilidades más valiosas. Quienes se integren rápido a estos cambios tendrán una ventaja significativa en su carrera.

Mi lectura:

Si me hubieran dicho esto cuando empecé, capaz me ahorraba dos años de cosas. A los juniors les diría algo más: experimenten, sí, pero también construyan algo propio en público. Un blog, un sitio, un proyecto open source — donde se vea cómo piensan, no solo qué saben usar.

La IA democratizó el saber-usar: cualquiera puede aprender una herramienta nueva en una tarde. Lo que diferencia ahora es el saber-pensar visible. Si tu única evidencia profesional es un CV con stack y certificaciones, estás compitiendo en la misma cancha que millones de personas con un asistente de IA al lado. Si en cambio tenés un repo público donde se vean tus decisiones, tus errores y cómo los corregiste, ahí sí hay algo que un modelo no puede replicar.

Cierre

Lo que más me llevo de esta conversación con José no es ninguna predicción concreta sobre IA — es una idea que atraviesa sus cinco respuestas: la herramienta no es el problema, el uso adecuado sí lo es. Spec-driven, contexto explícito, pipelines disciplinados, soft skills, construir en público. Todo apunta a lo mismo: el developer del 2026 va a ser tan bueno como su capacidad de pensar bien y comunicar mejor.

Gracias José, por el tiempo, la claridad y los años de amistad que están detrás de esta conversación.