Técnicas

Durante muchos años, hemos utilizado el enfoque de canary release para fomentar el feedback temprano sobre nuevas versiones del software, mientras reducimos el riesgo mediante un despliegue incremental a usuarios seleccionados. El 1% canary es una técnica útil en la que desplegamos nuevas funcionalidades a un segmento muy pequeño (digamos, el 1%) de usuarios cuidadosamente seleccionados de varias categorías de usuarios. Esto permite a los equipos capturar rápidamente el feedback de los usuarios y observar el impacto de las nuevas versiones en aspectos como el rendimiento y la estabilidad, para aprender y responder según sea necesario. Esta técnica se vuelve especialmente crucial cuando los equipos están implementando actualizaciones de software en aplicaciones móviles o en una flota de dispositivos, como dispositivos de edge computing o vehículos definidos por software. Con una adecuada observabilidad y feedback temprano, ofrece la oportunidad de limitar el alcance del impacto en caso de que surjan escenarios inesperados en producción. Aunque las canary releases pueden ser útiles para obtener un feedback más rápido de los usuarios, creemos que comenzar con un pequeño porcentaje de los usuarios es obligatorio para reducir y contener el riesgo en despliegues de funcionalidades a gran escala.

Las pruebas automatizadas siguen siendo la piedra angular del desarrollo eficaz de software. Para las pruebas de front-end podemos discutir si la distribución de distintos tipos de pruebas debería ser la clásica pirámide de pruebas o si debe tener forma de un trofeo. En cualquier caso, los equipos deberían centrarse en las pruebas de componentes porque los conjuntos de pruebas deben ser estables y ejecutarse rápidamente. En cambio, lo que estamos viendo es que los equipos renuncian a dominar las pruebas de componentes en favor de pruebas end-to-end basadas en el navegador, así como pruebas unitarias muy limitadas. Las pruebas unitarias tienden a forzar a los componentes a exponer lo que debería ser una funcionalidad puramente interna, mientras que las pruebas basadas en navegador son lentas, más inestables y más difíciles de depurar. Nuestra recomendación es tener una cantidad significativa de pruebas de componentes y utilizar una biblioteca como jsdom para ejecutar pruebas de componentes en memoria. Las herramientas de navegador como Playwright por supuesto, siguen teniendo un lugar en las pruebas de end-to-end, pero no deberían utilizarse para pruebas de componentes.

Creemos que las compañías deben adoptar prácticas de despliegue continuo siempre que sea posible. El despliegue continuo es la práctica de desplegar automáticamente a producción cada cambio que pasa las pruebas automatizadas. Esta práctica es un factor clave para lograr ciclos rápidos de retroalimentación y permite a las organizaciones entregar valor a los clientes de manera más rápida y eficiente. El despliegue continuo difiere de la entrega continua en que esta última sólo requiere que el código pueda ser desplegado en cualquier momento; no requiere que cada cambio realmente esté desplegado en producción. En el pasado habíamos dudado si mover el despliegue continuo hacia el anillo de Adopción, ya que es una práctica que requiere un alto nivel de madurez en otras áreas de la entrega de software y por lo tanto no es apropiada para todos los equipos. Sin embargo, el reciente libro de la Thoughtworker Valentina Servile Continuous Deployment proporciona una guía exhaustiva para implementar esta práctica en una organización. Ofrece un roadmap para que las organizaciones la sigan y así logren alcanzar el nivel de madurez requerido para adoptar prácticas de despliegue continuo.

Generación mejorada por recuperación (RAG) es el patrón preferido por nuestros equipos para mejorar la calidad de las respuestas generadas por un modelo de lenguaje de gran tamaño (LLM). Lo hemos utilizado con éxito en muchos proyectos, incluyendo la plataforma de IA Jugalbandi. Con RAG, la información sobre documentos relevantes y confiables se almacena en una base de datos. Para un prompt dado, se consulta la base de datos, se recuperan los documentos relevantes y se amplía el prompt con el contenido de los documentos, proporcionando así un contexto más completo al LLM. Esto resulta en una salida de mayor calidad y reduce considerablemente las alucinaciones. La ventana de contexto —que determina el tamaño máximo de la entrada del LLM— ha crecido significativamente con los modelos más nuevos, pero seleccionar los documentos más relevantes sigue siendo un paso crucial. Nuestra experiencia indica que un contexto más pequeño y cuidadosamente construido puede generar mejores resultados que un contexto amplio y grande. Utilizar un contexto grande también es más lento y costoso. Antes dependíamos únicamente de incrustaciones almacenadas en una base de datos vectorial para identificar el contexto adicional. Ahora estamos viendo re-ranking y búsqueda híbrida: herramientas de búsqueda como Elasticsearch Relevance Engine, así también enfoques como GraphRAG que utilizan grafos de conocimiento creados con la ayuda de un LLM. El enfoque basado en grafos ha funcionado particularmente bien en nuestro trabajo sobre la comprensión de bases de código heredado con GenAI.

El diseño guiado por dominios (DDD) se ha convertido en un enfoque fundamental en la forma en que desarrollamos software. Lo utilizamos para modelar eventos, guiar diseños de software, establecer límites de contexto alrededor de microservicios y elaborar requisitos de negocio matizados. DDD establece un lenguaje ubicuo que tanto las partes interesadas no técnicas y los desarrolladores de software puedan usar para comunicarse efectivamente acerca del negocio. Una vez establecido, los modelos de dominio evolucionan, pero a muchos equipos les resulta difícil comenzar con DDD. No existe un enfoque único para construir un modelo de dominio inicial. Una técnica prometedora que hemos encontrado recientemente es la narración de dominio (domain storytelling) . La narración de dominio es una técnica donde a los expertos en negocio se les solicita que describan las actividades en el negocio. A medida que los expertos son guiados a través de la narración, un facilitador usa un lenguaje pictográfico para capturar las relaciones y acciones entre las entidades y actores. El proceso de realizar estas historias ayuda visiblemente a clarificar y desarrollar un entendimiento compartido entre los participantes. Ya que no existe un único método correcto para desarollar un modelo de dominio, la naracción de dominio ofrece una alternativa digna de mención o, para un enfoque más completo de DDD, complementar con Event Storming, que es otra técnica que utilizamos a menudo para empezar con DDD.

Al desarrollar aplicaciones LLM basadas en generación mejorada por recuperación (RAG por sus siglas en inglés), la calidad de los embeddings impacta directamente tanto en la recuperación de documentos relevantes como en la calidad de las respuestas. Aplicar fine-tuning a embeddings puede mejorar la precisión y relevancia de los embeddings para tareas o dominios específicos. Nuestros equipos hicieron fine-tuning a los embeddings al desarrollar aplicaciones LLM de dominios específicos, donde la extracción de información precisa es crucial. Sin embargo, hay que considerar las ventajas y desventajas de este enfoque antes de apresurarse a afinarlos.

Llamada a funciones con LLMs se refiere a la capacidad de integrar los LLMs con funciones, APIs o herramientas externas; esto se logra identificando e invocando la función adecuada basada en una consulta dada y en la documentación asociada. Esta capacidad extiende la utilidad de los LLMs más allá de la generación de texto, permitiéndoles realizar tareas específicas como la recuperación de información, la ejecución de código y la interacción con APIs. Al invocar funciones externas o APIs, los LLMs pueden realizar acciones que antes estaban fuera de sus capacidades individuales. Esta técnica permite a los LLMs actuar sobre sus propios resultados, cerrando así la brecha entre el pensamiento y la acción, de manera similar a cómo los humanos usan herramientas para completar diversas tareas. Con la introducción de la llamada a funciones, los LLMs añaden determinismo y veracidad al proceso de generación, logrando un equilibrio entre creatividad y lógica. Este método permite a los LLMs conectarse a sistemas internos y bases de datos o incluso realizar búsquedas en internet a través de navegadores conectados. Modelos como la serie GPT de OpenAI admiten la llamada a funciones, y modelos perfeccionados como Gorilla están específicamente diseñados para mejorar la precisión y consistencia en la generación de llamadas a APIs ejecutables a partir de instrucciones en lenguaje natural. Como técnica, la llamada a funciones se sitúa dentro de la generación mejorada por recuperación (RAG) y arquitecturas de agentes. Debería verse como un patrón abstracto de uso, destacando su potencial como una herramienta fundamental en diversas implementaciones, más que como una solución específica.

Varios sistemas que construimos comparten dos importantes características: ser capaces de responder una pregunta acerca de un conjunto de datos extenso y ser casi imposible de saber cómo se ha llegado a la solución. A pesar de esta opacidad nosotros aun queremos evaluar y mejorar la calidad de las respuestas. Con el patrón LLM como juez , nosotros usamos LLM para evaluar la respuesta de otro sistema, que a su vez podría estar basado en un LLM. Hemos visto este patrón ser usado para determinar la relevancia de los resultados de búsqueda en un catálogo de productos y evaluar si un chatbot basado en LLM estaba guiando a los usuarios en una dirección sensata. Naturalmente, el sistema evaluador debe estar configurado y calibrado de manera cuidadosa. Puede generar ganancias significativas en eficiencia, lo que, a su vez, se traduce en costos más bajos. Esta es una área de investigación en curso, con un estado actualizado y resumido en este artículo.

Impulsadas por la alianza FIDO y respaldadas por Apple, Google y Microsoft, las passkeys están cerca de alcanzar un nivel de usabilidad masivo. Al configurar un nuevo inicio de sesión con llaves de acceso, se generan un par de claves: el sitio web recibe la clave pública y el usuario mantiene la clave privada. El proceso del inicio de sesión utiliza criptografía asimétrica. El usuario demuestra que está en posesión de la clave privada, que se almacena en el dispositivo del usuario y nunca se envía al sitio web. El acceso a las llaves está protegido mediante biometría o un PIN. Las llaves de acceso pueden almacenarse y sincronizarse en los ecosistemas de las grandes tecnológicas, utilizando iCloud Keychain de Apple, Google Password Manager o Windows Hello. Para usuarios multiplataforma, el Client to Authenticator Protocol (CTAP) permite que las llaves de acceso se guarden en un dispositivo diferente al que crea la clave o la necesita para el inicio de sesión. La objeción más común al uso de las passkeys es que representan un desafío para los usuarios con menos conocimientos técnicos, lo cual creemos que es una visión contraproducente. Estos suelen ser los mismos usuarios que tienen una gestión deficiente de las contraseñas y, por lo tanto, serían los más beneficiados por métodos alternativos. En la práctica, los sistemas que usan llaves de acceso pueden recurrir a métodos de autenticación tradicionales si es necesario.

Los modelos de lenguaje de gran tamaño (LLM) han demostrado su utilidad en muchas áreas de aplicación, pero el hecho de que sean grandes puede ser una fuente de problemas: responder a una consulta requiere muchos recursos de cómputo, lo que hace que las consultas sean lentas y caras; los modelos son propietarios y tan grandes que deben ser alojados en una nube por un tercero, lo que puede ser problemático para los datos sensibles; y entrenar un modelo es excesivamente caro en la mayoría de los casos. El último problema puede resolverse con el patrón RAG, que evita la necesidad de entrenar y afinar los modelos básicos, pero los problemas de costo y privacidad suelen persistir. Por ello, cada vez hay más interés en los modelos de lenguaje pequeños (SLM). En comparación con sus hermanos más populares, tienen menos pesos y menos precisión, normalmente entre 3,5 y 10B parámetros. Investigaciones recientes sugieren que, en el contexto adecuado y si se configuran correctamente, los SLM pueden rendir o incluso superar a los LLM. Y su tamaño permite ejecutarlos en dispositivos periféricos. Ya hemos mencionado el Gemini Nano de Google, pero el panorama está evolucionando rápidamente, con Microsoft presentando su serie Phi-3, por ejemplo.

La creación de sets de datos sintéticos implica generar datos artificiales que puedan imitar escenarios del mundo real sin depender de fuentes de datos sensibles o de acceso limitado. Aunque los datos sintéticos para sets de datos estructurados se han explorado ampliamente (por ejemplo, para pruebas de rendimiento o entornos seguros para la privacidad), estamos viendo un uso renovado de los datos sintéticos para datos no estructurados. A menudo, las empresas se enfrentan a la falta de datos etiquetados específicos del dominio, especialmente para su uso en el entrenamiento o el ajuste de los LLM. Herramientas como Bonito y Microsoft's AgentInstruct pueden generar datos sintéticos de ajuste de instrucciones a partir de fuentes crudas como documentos de texto y archivos de código. Esto ayuda a acelerar el entrenamiento del modelo al tiempo que reduce los costes y la dependencia de la curación manual de datos. Otro caso de uso importante es la generación de datos sintéticos para tratar datos desequilibrados o dispersos, algo habitual en tareas como la detección de fraudes o la segmentación de clientes. Técnicas como SMOTE ayudan a equilibrar conjuntos de datos creando artificialmente instancias de clases minoritarias. Del mismo modo, en sectores como el financiero, las redes generativas adversariales (GAN) se utilizan para simular transacciones poco frecuentes, lo que permite que los modelos sean robustos a la hora de detectar casos extremos y mejorar el rendimiento general.

La IA Generativa (GenAI) y los modelos de lenguaje de gran tamaño (LLMs) pueden ayudar a los desarrolladores a escribir código y entenderlo. Esta ayuda es especialmente útil en el caso de bases de código heredado con documentación deficiente, incompleta y/o desactualizada. Desde nuestra última actualización sobre este tema, las técnicas y herramientas sobre el usar GenAI para entender las bases de código heredado han evolucionado significativamente. Hemos utilizado con éxito algunas de estas técnicas en la práctica, especialmente para apoyar esfuerzos de ingeniería inversa en la modernización de mainframes. Una técnica especialmente prometedora que hemos utilizado es un enfoque de generación aumentada por recuperación(RAG), en el cual la recuperación de información se realiza a partir de un grafo de conocimiento del código. Este grafo puede conservar información estructural sobre la base de código que va más allá de lo que un modelo de lenguaje de gran tamaño (LLM) podría extraer únicamente del código textual. Esto resulta particularmente útil en bases de código heredado que son menos autodescriptivas y cohesivas. Además, hay una oportunidad adicional para mejorar la comprensión del código, ya que el grafo puede enriquecerse aún más con documentación existente y generada por IA, dependencias externas, conocimientos del dominio de negocio o cualquier otro recurso disponible que facilite el trabajo de la IA.

Las herramientas de asistencia de codificación de IA se mencionan principalmente en el contexto de la asistencia y la mejora del trabajo de un colaborador individual. Sin embargo, la entrega de software es y seguirá siendo un trabajo en equipo, por lo que se debería buscar formas de crear asistentes de IA para equipos que ayuden a crear el equipo 10x, en lugar de un grupo aislado de ingenieros 10x asistidos por IA. Afortunadamente, los recientes desarrollos en el mercado de herramientas nos acercan a hacer de esto una realidad. Unblocked es una plataforma que reúne todas las fuentes de conocimiento de un equipo y las integra de forma inteligente en las herramientas de los miembros del equipo. Rovo de Atlassian incorpora la IA a la plataforma más utilizada de colaboración en equipo, brindando a los equipos nuevos tipos de búsqueda y acceso a su documentación, además de desbloquear nuevas formas de automatización y soporte a prácticas de software con agentes Rovo. Mientras esperamos que el mercado siga evolucionando en este ámbito, hemos estado explorando el potencial de la IA para la amplificación del conocimiento y el soporte a las prácticas de equipo: abrimos nuestro asistente de equipo Haiven y comenzó a recopilar aprendizajes con asistencia de IA para tareas no asociadas a la programación, como el análisis de requerimientos.

El prompting dinámico con pocas muestras se basa en el prompting con pocas muestras, incluyendo de forma dinámica ejemplos específicos en la instrucción (prompt) para guiar las respuestas del modelo. Ajustar el número y relevancia de estos ejemplos optimiza la extensión del contexto y su relevancia, mejorando así la eficiencia y el rendimiento del modelo. Hay librerías de código, como scikit-llm, que implementan esta técnica usando la búsqueda del vecino más cercano para encontrar los ejemplos más relevantes de acuerdo con la consulta del usuario. Esta técnica permite hacer un mejor uso del limitado marco contextual del modelo y reducir el consumo de tokens. El generador de código SQL de código libre vanna utiliza prompting dinámico con pocas muestras para mejorar la precisión de sus resultados.

GraphQL para productos de datos es la técnica de usar GraphQL como un punto de acceso para los productos de datos para que clientes consuman el producto. Hemos hablado acerca de GraphQL como un protocolo de API y cómo permite a desarrolladores crear una capa unificada de API que abstrae la complejidad de los datos subyacentes, entregando una interfaz más cohesionada y manejable a los clientes. GraphQL para productos de datos facilita a los consumidores la tarea de descubrir el formato y relaciones de los datos con el esquema de GraphQL y usar herramientas de cliente familiares para GraphQL. Nuestros equipos están explorando esta técnica en casos de uso específicos como talk-to-data para explorar y descubrir insights de big data con la ayuda de grandes modelos de lenguaje (LLMs por sus siglas en inglés) donde las consultas de GraphQL están construidas por LLMs basadas en los prompts del usuario y el esquema de GraphQL es usado en los prompts de la LLM como referencia.

Los agentes autónomos impulsados por modelos de lenguaje a gran escala (LLM) están evolucionando más allá de agentes individuales y sistemas multiagente estáticos con la aparición de frameworks como Autogen y CrewAI. Esta técnica permite a los desarrolladores descomponer una actividad compleja en varias tareas más pequeñas, realizadas por agentes a los que se les asigna un rol específico. Los desarrolladores pueden utilizar herramientas preconfiguradas para ejecutar las tareas, mientras que los agentes se comunican entre sí y orquestan el flujo de trabajo. La técnica aún se encuentra en sus primeras etapas de desarrollo. En nuestros experimentos hasta ahora, nuestros equipos han encontrado problemas como agentes que entran en bucles continuos y comportamientos descontrolados. Librerías como LangGraph ofrecen un mayor control sobre las interacciones de los agentes, permitiendo definir el flujo como un gráfico. Si decides utilizar esta técnica, sugerimos implementar mecanismos a prueba de fallos, como límites de tiempo y supervisión humana.

Observabilidad 2.0 representa un cambio de las herramientas de monitoreo tradicionales y dispersas hacia un enfoque unificado que aprovecha datos estructurados y de alta cardinalidad de eventos en un único repositorio de datos. Este modelo captura eventos enriquecidos y sin procesar con metadatos detallados para proporcionar una fuente de verdad única para un análisis exhaustivo. Al almacenar los eventos en su forma cruda, simplifica la correlación y soporta el análisis forense y en tiempo real, permitiendo obtener una visión más profunda sobre sistemas distribuidos complejos. Este enfoque permite un monitoreo de alta resolución y capacidades de investigación dinámicas. Observabilidad 2.0 da prioridad a la captura de datos con alta cardinalidad y alta dimensión, permitiendo un análisis detallado sin cuellos de botella de rendimiento. El repositorio de datos unificado reduce la complejidad, ofreciendo una visión coherente del comportamiento del sistema y alineando las prácticas de observabilidad más estrechamente con el ciclo de vida del desarrollo de software.

Los modelos de lenguaje de gran tamaño o LLMs (siglas en inglés para Large Language Model) ahora son capaces de correr en navegadores web y dispositivos de usuario final, como teléfonos inteligentes y computadores portátiles, permitiendo que aplicaciones de AI se ejecuten en el dispositivo. Esto permite el manejo seguro de datos sensibles sin necesidad de transferir datos hacia la nube, muy baja latencia en tareas como edge computing y procesamiento de imagen o video en tiempo real, costos reducidos al realizar cómputos localmente y mantener funcionalidad incluso cuando no se cuenta con una conexión estable a internet. Ésta es un área de continua investigación y desarrollo. En ediciones pasadas mencionamos MLX, un framework de código abierto para machine learning eficiente en procesadores Apple silicon. Otras herramientas que están emergiendo incluyen Transformers.js y Chatty. Transformers.js nos permite correr Transformers en el navegador usando el ONNX Runtime, soportando modelos convertidos desdecomo PyTorch, TensorFlow y JAX. Chatty se apalanca en WebGPU para correr LLMs de forma nativa y privada en el navegador, ofreciendo una experiencia de AI enriquecida dentro del mismo.

La salida estructurada de LLMs se refiere a la práctica de restringir la respuesta de un modelo de lenguaje, a un esquema definido. Esto se puede lograr ya sea a través de instruir a un modelo generalizado que responda en un formato particular o realizando fine-tuning a un modelo para obtener una salida “nativa”, por ejemplo, JSON. OpenAI ahora soporta salida estructurada, permitiendo a los desarrolladores proporcionar un esquema JSON, pydantic o un objeto Zod para limitar las respuestas de un modelo. Esta capacidad es particularmente valiosa ya que permite llamadas a funciones, interacciones con una API e integraciones externas, donde la precisión y el cumplimiento de un formato son críticas. La salida estructurada no solo mejora la forma en que los LLMs pueden interactuar con el código, sino que también soporta un mayor cantidad de casos de uso, como generación de markup para el renderizado de gráficos. Adicionalmente, la salida estructurada ha demostrado reducir las posibilidades de alucinaciones en la salida de un modelo.

Los asistentes de código con IA como GitHub Copilot y Tabnine se han hecho muy populares. Según la encuesta para desarrolladores de StackOverflow de 2024, “el 72% de todos los encuestados están a favor o muy a favor de las herramientas con IA para el desarrollo”. Aunque también vemos sus ventajas, desconfiamos del impacto a medio y largo plazo que esto tendrá en la calidad del código y advertimos a los desarrolladores sobre la complacencia con el código generado por IA. Tras unas cuantas experiencias positivas con un asistente, resulta demasiado tentador ser permisivos al revisar las sugerencias de la IA. Estudios como éste, de GitClear, muestran una tendencia a un crecimiento más rápido de las bases de código, que sospechamos coincide con un mayor número de pull requests. Y este estudio de GitHub nos hace preguntarnos si el mencionado aumento del 15% de la tasa de fusión de pull requests es realmente algo bueno o si la gente está fusionando pull requests más grandes más rápido porque confían demasiado en los resultados de la IA. Seguimos utilizando los consejos básicos “para empezar” que dimos hace más de un año, que consisten en tener cuidado con el sesgo de automatización, la falacia del costo hundido, el sesgo de anclaje y la fatiga de revisión. También recomendamos que los programadores desarrollen un buen framework mental sobre dónde y cuándo no utilizar o confiar en la IA.

Crear entornos de pruebas de integración para toda la empresa es una práctica frecuente y costosa que lo ralentiza todo. Estos entornos invariablemente se convierten en recursos valiosos que son difíciles de replicar y un cuello de botella para el desarrollo. También proveen de una falsa sensación de seguridad por sus inevitables discrepancias en los datos y configuraciones entre entornos. Irónicamente, la objeción habitual a sus alternativas — ya sean entornos efímeros o múltiples entornos de prueba locales — es su costo. Sin embargo, no se considera el costo de los retrasos causados por los entornos de integración para toda la empresa, como tener equipos de desarrollo en espera de que otros equipos terminen, o a los despliegues de nuevas versiones de sistemas dependientes. En su lugar, los equipos deberían usar entornos efímeros y, preferiblemente, un conjunto de pruebas propias del equipo de desarrollo que puedan ser ejecutadas y descartadas a bajo costo, usando stubs para sus sistemas en vez de réplicas reales. Para otras técnicas que soportan esta alternativa echa un vistazo a pruebas de contrato guiados por el consumidor, desacoplar el despliegue de la publicación, centrarse en el tiempo medio de recuperación y pruebas en producción.

En lugar de imponer prohibiciones al uso de LLMs en el lugar de trabajo, las organizaciones deberían enfocarse en proveer acceso a un conjunto de herramientas de IA aprobadas. Una prohibición sólo empuja a los empleados a encontrar soluciones alternativas no aprobadas y potencialmente inseguras, creando riesgos innecesarios. Como en los días primarios de la computadora personal, la gente va a utilizar cualquier herramienta que sienta efectiva para hacer su trabajo, a pesar de las barreras impuestas. Al no proveer una alternativa segura y respaldada, las compañías corren el riesgo de que los empleados utilicen LLM no aprobados que vienen acompañados de riesgos de propiedad intelectual, fuga de datos y responsabilidad. Por otro lado, ofrecer LLMs o herramientas de IA seguras y aprobadas por la empresa, garantiza la seguridad y productividad. Un enfoque bien gobernado permite a las organizaciones manejar sus inquietudes sobre privacidad de datos, seguridad, cumplimiento y costos, al mismo tiempo que empodera a los empleados con las capacidades que los LLMs ofrecen. En el mejor de los casos, un acceso bien manejado a herramientas IA puede acelerar el aprendizaje organizacional acerca de las mejores maneras de usar IA para el trabajo.

Cuando se habla de codificación en pares, inevitablemente surge el tema de pair programming. Nuestra profesión tiene una relación de amor-odio con ella: algunos la adoran, otros no la soportan. Los codificadores en pares plantean ahora la siguiente pregunta: ¿puede un humano trabajar en par con la IA, en lugar de con otro humano, y obtener los mismos resultados para el equipo? GitHub Copilot incluso se llama a sí mismo «tu codificador en parejas de IA». Aunque creemos que un asistente de programación puede aportar algunas de las ventajas de la programación en parejas, desaconsejamos totalmente reemplazar la programación en parejas por la IA. Enmarcar a los asistentes de programación como codificadores en pareja ignora uno de los principales beneficios de la programación en pareja: mejorar el equipo, no sólo a los colaboradores individuales. Los asistentes de programación pueden ser útiles para desbloquearse, aprender sobre una nueva tecnología, incorporarse o agilizar el trabajo táctico para que podamos centrarnos en el diseño estratégico. Pero no contribuyen a ninguno de los beneficios de la colaboración en equipo, como mantener bajo el trabajo en curso, reducir los traspasos y el re-aprendizaje, hacer posible la integración continua o mejorar la propiedad colectiva del código.