ºÚÁÏÃÅ

Durante muchos a?os, hemos utilizado el enfoque de 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 ³Ù¨¦³¦²Ô¾±³¦²¹ ¨²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 ³Ù¨¦³¦²Ô¾±³¦²¹ 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 o si debe tener forma de un . 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 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 ±ð²õ³Ù¨¦ 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 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.

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 . 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 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 ³Ù¨¦³¦²Ô¾±³¦²¹s 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 ³Ù¨¦³¦²Ô¾±³¦²¹ prometedora que hemos encontrado recientemente es la . La narraci¨®n de dominio es una ³Ù¨¦³¦²Ô¾±³¦²¹ 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 ³Ù¨¦³¦²Ô¾±³¦²¹ 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 ³Ù¨¦³¦²Ô¾±³¦²¹ 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 ³Ù¨¦³¦²Ô¾±³¦²¹, 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 .

Impulsadas por la alianza FIDO y respaldadas por Apple, Google y Microsoft, las 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 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. 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 , 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 y 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. °Õ¨¦³¦²Ô¾±³¦²¹²õ como 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 ³Ù¨¦³¦²Ô¾±³¦²¹s y herramientas sobre el usar GenAI para entender las bases de c¨®digo heredado han evolucionado significativamente. Hemos utilizado con ¨¦xito algunas de estas ³Ù¨¦³¦²Ô¾±³¦²¹s en la pr¨¢ctica, especialmente para . Una ³Ù¨¦³¦²Ô¾±³¦²¹ 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. 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 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 , 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 , que implementan esta ³Ù¨¦³¦²Ô¾±³¦²¹ usando la b¨²squeda del vecino m¨¢s cercano para encontrar los ejemplos m¨¢s relevantes de acuerdo con la consulta del usuario. Esta 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 utiliza prompting din¨¢mico con pocas muestras para mejorar la precisi¨®n de sus resultados.

GraphQL para productos de datos es la ³Ù¨¦³¦²Ô¾±³¦²¹ 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 ³Ù¨¦³¦²Ô¾±³¦²¹ 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 y . Esta ³Ù¨¦³¦²Ô¾±³¦²¹ 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 ³Ù¨¦³¦²Ô¾±³¦²¹ 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 ofrecen un mayor control sobre las interacciones de los agentes, permitiendo definir el flujo como un gr¨¢fico. Si decides utilizar esta ³Ù¨¦³¦²Ô¾±³¦²¹, sugerimos implementar mecanismos a prueba de fallos, como l¨ªmites de tiempo y supervisi¨®n humana.

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 y . 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 , ¡°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 , 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 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 .

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 ³Ù¨¦³¦²Ô¾±³¦²¹s 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 . 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 . 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.