Las herramientas de codificación con IA pueden generar código rápidamente, pero la velocidad por sí sola no resuelve los problemas más difíciles de la ingeniería de software. Los desarrolladores aún necesitan proporcionar contexto, validar resultados, proteger la mantenibilidad y seguir siendo responsables de lo que se publica.
Para aprender cómo los desarrolladores experimentados logran ese equilibrio, hablamos con tres Java Champions, todos con más de una década de experiencia usando Java. Compartieron ejemplos concretos del uso de GitHub Copilot en producción y en código abierto, junto con las prácticas que emplean para convertir el resultado generado por IA en software confiable.
Estos son los consejos que compartieron con nosotros.
Vlad Mihalcea
Perfil de GitHub: @vladmihalcea
¿Cómo te ha ayudado GitHub Copilot recientemente?
Lo he estado usando para analizar, diseñar e implementar varias funcionalidades tanto en Hypersistence Utils como en Hypersistence Optimizer.
Por ejemplo, llevaba mucho tiempo queriendo desarrollar una aplicación web que proporcione el historial de eventos de Optimizer para poder ver cómo se materializan los esfuerzos de mejora del rendimiento en el rendimiento de la aplicación. Antes de la IA, seguía posponiendo esta tarea porque me habría llevado semanas desarrollarla. Pero usar Copilot es como tener un nuevo miembro en el equipo, así que lo usé para crear una aplicación que se incluirá en la próxima versión de Hypersistence Optimizer. En lugar de semanas, esta tarea tomó solo dos días en implementarse.
¿Cuál es tu uso típico? ¿Usas GitHub Copilot como un plugin de IDE o la aplicación de GitHub Copilot?
Uso GitHub Copilot en IntelliJ IDEA porque es conveniente tenerlo en ejecución mientras reviso código fuente o durante una sesión de depuración.
Es muy útil como asistente de código y me ayuda a acelerar tanto las investigaciones como la creación de prototipos de funcionalidades que necesitan validación.
Sigo revisando los planes y el código generado por IA, ya que su objetivo es mejorar mi productividad, no reemplazarme por completo. Aunque la IA proporciona la respuesta correcta en muchas situaciones, todavía hay momentos en los que la respuesta no es satisfactoria y requiere mi intervención.
¿Puedes compartir algunos consejos y buenas prácticas? Por ejemplo, ¿qué skills estás usando?
Creé mis propias skills para que cualquier texto que genere Copilot parezca algo escrito por mí a mano.
Esta skill captura mi voz a partir de 65 de mis artículos publicados, de modo que un borrador vuelve sonando como mi blog en lugar de como un modelo de lenguaje. Esto es realmente útil al generar documentación para este proyecto, ya que permite que el LLM aprenda de 12 años de blogueo y proporcione ejemplos que siguen los mismos principios, como la expresividad, la testabilidad y la simplicidad.
A lo largo de mi carrera como ingeniero de software, he aprendido que pasamos mucho más tiempo en el mantenimiento del código que en su creación. Por lo tanto, dado que el mantenimiento y la estabilidad son críticos para los productos existentes, desarrollé skills que ayudan a la IA a imitar las prácticas de código existentes de acuerdo con el principio de mínimo asombro.
Un consejo es cambiar el tipo de modelo según el tipo de operación. Para un razonamiento profundo, uso Opus con la ventana de contexto de 1 millón y razonamiento Extra High o Max. Sin embargo, para tareas más simples, como generar informes, notas de versión o verificar documentación, uso modelos más ligeros que consumen menos tokens.
Patrick Baumgartner
Perfil de GitHub: @patbaumgartner
Tu trabajo implica asesorar a equipos. ¿Cuál es tu enfoque?
Gran parte de mi trabajo ocurre mientras la operación normal del negocio todavía debe seguir funcionando. No se puede detener todo durante seis meses para "transformarse". Normalmente comenzamos resolviendo problemas inmediatos juntos, entendemos dónde se encuentra actualmente el equipo, definimos a dónde queremos llegar y cómo sabremos que estamos mejorando, y luego avanzamos hacia allí paso a paso.
Dependiendo de la situación, eso puede significar prácticas de Software Craft como TDD, refactorización, entrega continua y XP; arquitectura y modularización con Spring Boot, Spring Modulith; Spring Security; optimizar aplicaciones Java y Spring Boot para contenedores; o, cada vez más, ingeniería agéntica.
La parte importante para mí es que trabajo con el equipo. Tomamos decisiones juntos. No quiero que un equipo se vuelva dependiente de mí. Idealmente, después de un tiempo ya no me necesiten, excepto quizás como compañero de sparring.
Y quizás eso explica por qué me parece tan interesante esta nueva generación de herramientas de IA: me gusta trabajar con personas, aprender, experimentar y resolver problemas. La IA nos ofrece otra herramienta muy poderosa para hacer exactamente eso.
¿Puedes compartir una buena historia sobre cómo GitHub Copilot te ha ayudado recientemente?
En realidad, hay tres ejemplos muy diferentes que cambiaron mi forma de pensar sobre cómo trabajar con GitHub Copilot.
Comencemos con el primero.
Una fue una migración de alrededor de 900 diapositivas de docencia a lo largo de 15 presentaciones de Reveal.js a Marp. No eran diapositivas simples. Muchas contienen código, animaciones e incluso ejemplos interactivos donde puedo modificar JavaScript en vivo mientras enseño. Más importante aún, las presentaciones ya habían sido probadas a fondo con estudiantes. El flujo funcionaba. Perder una pequeña pieza podría romper la historia que uso en el aula.
Hacer esa migración manualmente probablemente me habría llevado una semana o más, y en realidad, podría simplemente haberla evitado porque era un trabajo tan tedioso.
Con Copilot, lo abordé de manera diferente. Primero analizamos el material existente, definimos el objetivo, creamos un plan de migración, establecimos restricciones, proporcionamos ejemplos y definimos qué debía permanecer intacto. Luego trabajamos desde los grandes cambios estructurales hasta los detalles.
La parte realmente importante fue la verificación.
Generamos capturas de pantalla de las versiones de Reveal.js y Marp y las comparamos visual y algorítmicamente. Creamos una pequeña aplicación donde podía ejecutar ambos conjuntos de diapositivas uno al lado del otro para verificar las animaciones manualmente. Incluso comparamos los PDF generados.
Eso significó que el agente no solo dijera: «Migración completa». Teníamos evidencia.
Toda la migración me tomó aproximadamente de ocho a diez horas. Yo seguía siendo dueño del contenido, de la intención pedagógica y de cada cambio significativo. Copilot podía corregir un error tipográfico automáticamente, pero si cambiaba el contenido, las versiones, las fechas o el significado, eso era algo que discutíamos.
Para mí, esa experiencia reforzó un principio importante: delegar la ejecución, no la responsabilidad. Yo soy el responsable del resultado.
¿Puede compartir el segundo ejemplo?
Un segundo ejemplo surgió de crear una aplicación de interfaz de terminal con Tamboui. Al principio funcionaba perfectamente en Linux bajo WSL, y había olvidado por completo que alguien podría ejecutarla directamente en Windows CMD o PowerShell.
Y entonces un usuario real lo hizo.
Descubrieron que la tecla Enter simplemente se ignoraba en algunos formularios. Ese es otro principio en el que creo firmemente: publicar el software temprano, porque se aprende de cómo la gente realmente lo usa.
Usamos Copilot para convertir ese comentario en pruebas de UI reproducibles. En Linux, Copilot navegaba por la aplicación con tmux. Al trabajar con ello, aprendí sobre psmux y pude ejecutar flujos similares en PowerShell. Reprodujimos el problema, creamos una corrección local, rastreamos el problema real hasta Tamboui, y envié la corrección upstream, que fue aceptada.
Durante este trabajo, las descripciones de las pruebas se volvieron demasiado grandes para el contexto disponible. Así que le pedí a Copilot que me ayudara a rediseñar la forma en que se representaban las pruebas. En lugar de tablas verbosas que contenían identificadores, nombres y descripciones repetidas, propuso una notación de flechas mucho más compacta: step → step → input, con información adicional solo donde era crítico.
Eso me sorprendió. No estábamos usando la IA solo para ejecutar información; estábamos trabajando juntos en cómo debería representarse la información para la ejecución. No tenía que ser máximamente amigable para los humanos. Tenía que preservar la semántica siendo eficiente para el agente.
¿Y el tercer ejemplo?
El tercer ejemplo es completamente diferente de nuevo.
Alguien cercano a mí necesitaba practicar matemáticas, y pensé: ¿por qué no creamos una pequeña aplicación de aprendizaje?
Cubre la suma, la resta, la multiplicación, la división y la división con resto para los grados uno a cuatro. Pero no quería crear otra aplicación simple de cuestionarios. Junto con Copilot, investigué enfoques de aprendizaje como la repetición espaciada, la retroalimentación inmediata, la dificultad adaptativa, la motivación, el aprendizaje cooperativo y la gamificación sin dark patterns.
Curiosamente, durante esa investigación Copilot desafió una de mis suposiciones originales. Inicialmente quería que la aplicación fuera genérica para niños de todo el mundo. La investigación nos llevó a examinar el plan de estudios escolar real. Me di cuenta de que el orden en que se introducen los temas, las operaciones y los rangos numéricos difieren lo suficiente como para que hacerla «universal» de inmediato era innecesario.
Así que nos enfocamos primero en Suiza y alineamos la progresión en consecuencia. Debido a que Suiza es multilingüe, la aplicación está disponible en alemán, francés, italiano e inglés.
También tiene modos cooperativos y competitivos para dos jugadores, y cuando alguien responde mal, la aplicación explica una forma de resolverlo y vuelve a traer preguntas similares mediante repetición espaciada.
Elegí deliberadamente una arquitectura sin backend. No hay razón para que yo recopile datos personales de niños en un servidor, así que los datos permanecen en el dispositivo y la aplicación puede alojarse simplemente en GitHub Pages.
Lo que comenzó como un pequeño experimento ahora lo usan y comparten amigos. Accidentalmente se convirtió en un pequeño producto.
Esa experiencia me mostró otro lado de Copilot: no lo uses solo para implementar tu solución. Úsalo como un compañero de debate para expandir y desafiar el espacio de soluciones antes de empezar a construir.
¿Cómo usa típicamente Copilot?
En realidad, ya no uso la experiencia clásica de autocompletado de Copilot.
Mi trabajo se ha trasladado casi por completo hacia flujos de trabajo agénticos.
Uso VS Code cuando necesito un ciclo de retroalimentación visual muy ajustado, cuando quiero examinar de cerca documentos, código, presentaciones o resultados intermedios y adaptar el proceso sobre la marcha.
Para tareas más grandes orientadas a la ejecución, a menudo trabajo con el agente de código desde la terminal. Allí me siento más cómodo delegando una parte del trabajo, dejando que se ejecute y luego inspeccionando el resultado completo. La interfaz que elijo depende principalmente del ciclo de retroalimentación que necesito.
También tuve una experiencia fascinante usando el flujo de trabajo de agente de código a través de GitHub mientras viajaba a JavaLand. Había empezado a explorar una idea para un plugin de Maven que optimiza qué auto-configuraciones de Spring Boot se cargan. Durante un viaje de aproximadamente cuatro horas, dirigí al agente desde mi teléfono: le asignaba una tarea, revisaba lo que había hecho, pensaba en el siguiente paso y enviaba la siguiente instrucción.
Para cuando llegué, tenía un plugin de Maven funcional, un pipeline de CI, pruebas de rendimiento contra una aplicación de ejemplo e informes que podían demostrar si la optimización realmente funcionaba.
Era la primera vez que trabajaba de esa manera, y me sorprendió que realmente funcionara. No estaba intentando escribir Java en mi teléfono. Estaba revisando, decidiendo y dirigiendo mientras el agente ejecutaba.
También uso servidores MCP cuando me aportan capacidades o contexto útiles. Por ejemplo, he usado Context7 para documentación, integraciones con mi base de conocimiento Logseq, y he experimentado con una integración MCP para Adobe Premiere Pro.
Pero no uso MCP solo porque pueda. Si existe una buena CLI, a menudo prefiero la CLI porque me parece más directa y rápida.
El agente tampoco es un «desarrollador junior» en mi modelo mental. Lo considero mucho más como un compañero de sparring. Pero, igual que cualquiera que se une a un proyecto, primero necesita ponerse al día.
El contexto es el rey.
¿Puedes compartir algunos consejos y buenas prácticas?
Lo más importante que recomendaría es: dejar de hacer prompting de una sola vez.
Para cualquier cosa que no sea trivial, quiero entender el problema antes de que comience la ejecución. Muy a menudo le pido explícitamente al agente que primero me haga una entrevista. El propósito de esa entrevista es descubrir suposiciones y expectativas que todavía son implícitas.
Un buen agente puede ejecutar la idea equivocada increíblemente rápido. Eso no hace que el desvío sea más barato.
Lo experimenté yo mismo mientras trabajaba en mi optimizador de auto-configuración de Spring Boot. Inicialmente quería soportar tanto Spring Boot 3.5 como 4.x. Había diferencias arquitectónicas, así que implementamos ambos enfoques. Más tarde me di cuenta de que ya no necesitaba la vía de 3.5 y eliminarla fue doloroso.
La lección fue simple: los desvíos son caros. Consigue bien los requisitos antes de acelerar.
Una vez que la intención está clara, quiero un plan. Cuando reviso ese plan, cuatro cosas me importan especialmente: si las suposiciones son visibles, si las puertas de verificación están definidas, si el enfoque encaja con la arquitectura y si evita trabajo innecesario.
El segundo principio es definir puertas de verificación específicas de la tarea.
«Hecho» no debería significar que el modelo dice que está hecho.
Para una refactorización, las puertas podrían incluir pruebas que pasen, demostrar que todos los archivos previstos fueron tratados, actualizar la documentación y no dejar TODOs pendientes. Para la migración de diapositivas, las puertas incluían capturas de pantalla, diferencias visuales, animaciones, salida PDF y completitud del contenido.
Las puertas dependen de la tarea. El principio no: el agente debería poder proporcionar evidencia de que el trabajo satisface la definición de hecho.
Hace poco me encontré con una habilidad llamada unlazy que sigue una idea similar: crear puertas explícitas, trabajar a través de ellas deliberadamente y demostrar que se han completado en lugar de tomar atajos.
El tercer principio es convertir tus lecciones en habilidades reutilizables.
He empezado a escribir y mantener mis propias Agent Skills. Cuando aprendo algo de una ejecución—quizás el agente malinterpretó una convención, faltaba una comprobación útil, o encontré una mejor manera de abordar una tarea—actualizo la habilidad.
La próxima vez que realice esa tarea, la lección ya estará ahí.
Un ejemplo es una habilidad que llamo maintainer-audit, inspirada en el trabajo de la comunidad de open agent skills. La uso en todos mis repositorios. Comprueba y, cuando corresponde, corrige las cosas que espero que tenga un proyecto mantenido: documentación del repositorio, pipelines de CI, configuración de Dependabot, CodeQL, limpieza consistente y otros estándares de proyecto.
El objetivo no es generar otro informe de auditoría para que yo lo lea. Devuelve el repositorio automáticamente hacia la línea base que quiero. Eso hace que mis proyectos sean más consistentes y más fáciles de mantener.
Considero estas habilidades como ingeniería del conocimiento vivo en lugar de prompts estáticos.
El cuarto principio es colocar herramientas de ingeniería deterministas alrededor del modelo probabilístico.
Tengo mi propio arnés de calidad que envuelve herramientas como Checkstyle, PMD y las comprobaciones de arquitectura de Spring Modulith, y genera un informe consolidado que el agente puede consumir. Puedo ejecutarlo desde hooks y dejar que el agente itere:
cambiar → ejecutar comprobaciones → leer los hallazgos → corregir → ejecutar de nuevo.
Continúa hasta que no quedan hallazgos.
Eso no significa que deje de revisar el software. Sigo ejecutando la aplicación, interactúo con ella y decido si se comporta y se ve como espero. A veces implemento deliberadamente característica por característica porque el ciclo de retroalimentación es mucho más ajustado.
Aprendí que pedir todo de una vez porque «la IA puede hacerlo» suele ser una mala idea. Las especificaciones grandes y genéricas crean implementaciones grandes y genéricas, y limpiarlas después puede ser más difícil que construir incrementos más pequeños correctamente.
Más en general, creo que nosotros, los desarrolladores, necesitamos hablar mucho más sobre cómo usamos estas herramientas. Compartir los experimentos que funcionaron. Compartir los que no. Tomar prestadas ideas de los demás y adaptarlas a su propio contexto en lugar de buscar un proceso de desarrollo con IA universal.
Por eso también me gusta la idea de la IA como compañero de entrenamiento. Un viernes por la noche, cuando quiero experimentar con algo y no hay ningún compañero humano disponible, de repente tengo a alguien—o algo—with quien poner a prueba una idea, revisar un enfoque o usar como un patito de goma muy sofisticado.
Pero aun así llevo esas ideas a personas reales. La retroalimentación humana, la comprensión del producto y el contexto del mundo real siguen siendo esenciales.
¿Cómo crees que la IA está cambiando nuestra profesión?
No creo que los estudiantes de ingeniería de software deban aspirar principalmente a convertirse en máquinas productoras de código. Necesitan convertirse en solucionadores de problemas sólidos. Necesitan entender a los usuarios y a las partes interesadas, descubrir el problema real detrás de un requisito, cuestionar suposiciones, entender los productos y los mercados, hacer concesiones arquitectónicas, pensar de forma crítica, trabajar de manera estructurada y transferir soluciones útiles de un contexto a otro.
El modelo es extraordinariamente bueno generando posibilidades y ejecutando cosas. Pero como humano, normalmente sé mucho más del contexto real, incluidas las cosas que nadie documentó jamás.
Así que quiero seguir a cargo de dar forma a la solución y dejar que el agente se encargue de más parte de la ejecución.
En ese sentido, creo que la IA está devolviendo la ingeniería a la ingeniería de software.
Y me gusta eso.
Frank Delporte
Perfil de GitHub: @FDelporte
¿Cómo empezaste en el mundo de la tecnología?
He estado fascinado por las computadoras desde que tuve un Commodore 64 cuando tenía 11 años. Di algunos desvíos hacia la producción de video y el trabajo en televisión después de la escuela, pero volví a la programación porque ese video necesitaba ponerse en DVD y los primeros sitios web… Sí, soy de esa época ;-).
¿Cómo te ha ayudado GitHub Copilot recientemente?
Es un compañero perfecto para evaluar pull requests e investigar informes de errores.
Una historia notable es la de la biblioteca Pi4J que te permite construir aplicaciones Java para interactuar con componentes electrónicos en la Raspberry Pi. En febrero de 2026, lanzamos la V4, que tiene un nuevo plugin que usa la Foreign Function & Memory API. Lo probamos a fondo antes del lanzamiento, pero aun así, poco después del lanzamiento alguien informó que usar 5 botones de entrada no funciona como se esperaba. Pulsar uno de los primeros cuatro botones configurados desencadena una ejecución de código como se esperaba, mientras que el quinto botón no hace nada.
Este es el tipo de informe que no quieres recibir. Nada estaba visiblemente roto. Sin excepción, sin advertencia en los registros, el quinto botón simplemente estaba en silencio. Y empeoró: con el plugin gpiod más antiguo, exactamente el mismo hardware y exactamente la misma aplicación funcionaban bien. Así que el problema estaba en nuestro nuevo código FFM, que se sitúa sobre el dispositivo de caracteres GPIO del kernel de Linux y se comunica con él mediante llamadas nativas. Esa no es la parte del código donde esperas encontrar una respuesta rápida.
Así que asigné el issue al agente de código de Copilot y le di dos rutas de archivos como punto de partida, la clase proveedora y FFMDigitalInput. Unos media hora más tarde había un pull request, con una explicación que realmente no esperaba.
Cada entrada ejecuta un vigilante de eventos que se bloquea en una llamada nativa poll() , esperando que el kernel informe de un cambio en su línea GPIO. Esos vigilantes se ejecutaban en virtual threads. Y un virtual thread que se bloquea dentro de una llamada nativa no puede desmontarse de su hilo portador. Permanece anclado allí durante toda la duración de la llamada. Una Raspberry Pi 4 tiene cuatro núcleos, por lo que el planificador de virtual threads tiene cuatro hilos portadores. Registrar cuatro entradas, y los cuatro portadores quedan estacionados en poll() para siempre. El quinto vigilante se crea, pero nunca se programa. Ese es exactamente el error que se reportó. No "los eventos son inestables", sino "el quinto no hace nada".
Lo que más me gustó no fue el diff, fue la conversación que siguió en la revisión. Dejé un comentario pidiendo a Copilot que explicara esto con más detalle:
Pensé que el objetivo de los virtual threads era precisamente alejarse del límite de los platform threads? ¿Entonces cómo es un problema que cuatro virtual threads bloqueen los cuatro hilos en un procesador de cuatro núcleos como la Raspberry Pi?
Consulta el pull request para la conversación completa. Copilot fue capaz de vincular el uso de la Raspberry Pi, que tiene cuatro núcleos de CPU, con el problema reportado. Fue capaz de proponer una solución simple para el problema, además de algunas mejoras adicionales que encontró durante su investigación.
¿Puedes compartir algunos consejos y mejores prácticas?
- Dile dónde buscar: Para el issue #622 de Pi4J, añadí dos rutas de archivos. Es un pequeño esfuerzo que elimina una enorme cantidad de búsqueda en una base de código grande. Normalmente tienes una corazonada sobre el vecindario incluso cuando no tienes idea del error. Dásela a la herramienta para que no necesite investigar el código completo.
- Pide pruebas y tests: «Añade un unit test para validar el cambio» es algo que pido mucho estos días. Bueno, lo pedía, porque ahora se ha convertido en una regla en mi archivo de instrucciones. También evita casos en los que el diagnóstico era incorrecto, porque el test no fallará con el código antiguo.
- Pregunta por qué: Si no entiendes una corrección, dilo y pregunta. La explicación también es un entregable y debería añadirse a la documentación de tu proyecto o dentro del ticket o pull request. Enseña a todos los que lean esa información más adelante. Por ejemplo, esto también provocó más preguntas dentro del equipo de Pi4J sobre el pinning de virtual threads en llamadas nativas.
- Mantén el control: Todos estos pull requests en Pi4J fueron revisados y aprobados por los mantenedores antes de incorporarse. Ese es el modelo que mejor funciona en este proyecto: el agente hace la investigación, y los humanos siguen siendo responsables de lo que se publica. Pero también, en mis otros proyectos, siempre reviso el código que generó la herramienta. Siempre quiero mantener el código legible y mantenible. Muy a menudo, una herramienta crea métodos duplicados o recrea algo que ya está disponible en otro lugar y debería combinarse. Esa es tu responsabilidad. Hoy en día puedes ir muy rápido con la programación asistida por IA, lo que también significa que puedes crear un desastre muy rápido. No lo hagas; mantén tu código manejable, tus colegas y tu yo del futuro te lo agradecerán si tienen que investigar errores o hacer mejoras más adelante.
Etiquetas:
Escrito por
Principal Cloud Advocate
Publicaciones relacionadas
AI & MLCómo continuar una sesión de la aplicación de GitHub Copilot en VS Code
Aprende a mover una sesión de agente desde la aplicación de GitHub Copilot a VS Code sin perder la conversación, los cambios ni el contexto de trabajo.
AI & MLUn modelo para la detección de secretos: Encontrar más secretos con menos ruido
El clasificador de secretos mejora la calidad de la detección, aumenta la aceptación ponderada en un 11.5% y reduce el tiempo medio de ejecución de escaneo en un 86%.
AI & MLAplicación de GitHub Copilot para principiantes: Cómo enseñar a Copilot sobre tu base de código
Aprende a añadir instrucciones y habilidades personalizadas a tu repositorio, usar agentes personalizados y conectar servidores MCP como Playwright.