Les modèles de service sont un élément constitutif typique des « chemins d’or » que les organisations créent pour leurs équipes d’ingénierie, afin de faciliter la bonne pratique. Les modèles sont censés être les modèles pour tous les services de l’organisation, représentant toujours les modèles et normes de codage les plus récents. L’un des défis des modèles de service est cependant qu’une fois qu’une équipe a instancié un service avec l’un d’eux, il est fastidieux de répercuter les mises à jour du modèle sur ces services. Birgitta Böckeler se demande si GenAI peut y contribuer.

Birgitta Böckeler examine l'évaluation des risques concernant le moment où utiliser le codage par vibration, en utilisant trois dimensions du risque : Probabilité, Impact et Détectabilité.

L'auteur partage ses réflexions sur les LLM et l'IA, se prépare pour des vacances et réfléchit aux tendances de l'industrie. Les enquêtes sur l'impact de l'IA dans le développement logiciel oublient souvent les usages variés des LLM, ce qui peut entraîner des résultats biaisés. L'auteur exprime son incertitude quant à l'avenir de la programmation, encourageant l'expérimentation avec les LLM et le partage d'expériences. Il pense que la vague d'IA est une bulle, similaire aux avancées technologiques passées, mais avec un potentiel de valeur durable malgré l'éclatement éventuel. L'auteur assistera à la conférence GOTO Copenhague, se reconnectant avec ses collègues de l'industrie. Les LLM sont considérés comme des moteurs d'hallucinations, soulignant la nécessité de vérifier les sorties et de considérer plusieurs prompts. L'ingénierie logicielle peut évoluer pour intégrer la non-déterminisme, à l'image d'autres disciplines d'ingénierie. L'auteur note que les LLM peuvent se comporter comme des collègues juniors peu fiables, fournissant des résultats trompeurs. Enfin, l'auteur met en évidence les risques de sécurité accrus introduits par les LLM, en particulier concernant les extensions de navigateur agentic.

Un problème d'entreprise courant : les systèmes hérités critiques deviennent des « boîtes noires » - essentiels pour les opérations mais opaques et risqués à modifier. Thiyagu Palanisamy et Chandirasekar Thiagarajan ont travaillé avec un client pour utiliser l'ingénierie inverse assistée par l'IA pour reconstruire les spécifications fonctionnelles à partir d'éléments d'interface utilisateur, de binaires et de lignée de données pour surmonter la paralysie d'analyse. Ils ont développé une approche méthodique « multi-facettes » - en partant d'artefacts visibles, en enrichissant de manière incrémentale, en triangulant la logique et en préservant toujours la lignée. La validation humaine reste centrale pour garantir l'exactitude et la confiance dans la fonctionnalité extraite. Cette mission a révélé que transformer un système de boîte noire en plan détaillé permet de prendre des décisions de modernisation éclairées et d'accélérer les efforts de migration.

Le système de gestion d'hôpital open-source Bahmni a été lancé il y a plus de neuf ans avec une interface utilisateur utilisant AngularJS et une API REST OpenMRS. Rahul Ramesh a souhaité le convertir pour utiliser une interface utilisateur React + TypeScript avec une API HL7 FHIR. Lors de l'exploration de la façon de moderniser cela, il a utilisé un workflow de prompts structurés de Recherche, Révision et Reconstruction - avec Cline, Claude 3.5 Sonnet, le serveur MCP d'Atlassian et un serveur MCP de système de fichiers. Changer un seul contrôle aurait normalement pris 3-6 jours d'effort manuel, mais avec ces outils, cela a été achevé en moins d'une heure à un coût de moins de 2 dollars.

Les agents de codage en ligne de commande sont un outil fondamentalement différent des chatbots ou des outils d'autocomplétion - ce sont des agents qui peuvent lire du code, exécuter des tests et mettre à jour une base de code. Ben O'Mahony explique que tandis que les outils commerciaux sont impressionnants, ils ne comprennent pas le contexte particulier de notre environnement et les excentricités de notre projet spécifique. Au lieu de cela, nous pouvons construire notre propre agent de codage en assemblant des outils open source, en utilisant nos normes de développement spécifiques pour : les tests, la documentation, la production, la raisonnerie de code et les opérations de système de fichiers.

Il y a quelques semaines, Unmesh Joshi et moi avons commencé une conversation sur la façon dont il aime développer un langage d'abstractions lorsqu'il travaille avec un LLM. Nous avons pensé que cette conversation pourrait intéresser d'autres personnes, alors nous l'avons transformée en article. Nous y parlons de la façon dont la programmation consiste à la fois à construire et à appliquer des abstractions, et de la façon dont le LLM nous aide de différentes manières dans chaque activité.

L'auteur a développé une technique appelée « Jointures d'expansion » pour gérer efficacement le timing des présentations. Il s'agit de sujets optionnels préplanifiés qui peuvent être abordés brièvement ou en détail. Cela permet aux orateurs d'ajuster la durée de leur présentation sans paraître pressés ou mal préparés. Chaque Jointure d'expansion se compose généralement d'une seule diapositive avec des phrases clés, servant de stimuli pour la discussion. Si le temps est court, le sujet est résumé rapidement, souvent en indiquant qu'il est hors du cadre. Inversement, si suffisamment de temps est disponible, l'orateur peut développer le matériel optionnel. L'auteur a également maîtrisé l'art de sauter des diapositives de manière invisible pour le public, une compétence nécessitant une maîtrise de l'ordinateur portable. Cette technique a fourni de la confiance, notamment depuis que l'auteur n'a pas répété ses présentations de manière approfondie. Les Jointures d'expansion se sont avérées inestimables pour adapter les présentations à des créneaux horaires variables et gérer l'interaction avec le public. Ces segments flexibles sont les plus utiles vers la fin d'une présentation, lorsque le temps restant est le plus clair.

Les OKR sont devenus une façon populaire de connecter la stratégie à l'exécution dans les grandes organisations. Mais lorsque elles sont définies de manière descendante, elles perdent souvent leur sens. Les équipes reçoivent des objectifs qu'elles n'ont pas aidé à créer, et le résultat est un engagement faible et peu de changements réels. Paulo Caroli décrit comment les équipes à haute performance peuvent travailler différemment. Elles définissent leurs propres objectifs dans une organisation qui utilise un processus collaboratif pour aligner les OKR de l'équipe avec la stratégie plus large. Avec ces OKR d'équipe en place, elles créent un but partagé et deviennent la base d'un cycle régulier de planification, de vérifications et de rétrospectives.

Sriram Narayan conclut son article dans Impact Intelligence en abordant cinq objections courantes à cette activité, notamment le ralentissement, le manque d'agilité et de collaboration, et l'imprévisibilité de l'innovation.

Abi Noda a observé que tandis que les développeurs d'une grande entreprise d'ingénierie économisent deux heures par semaine avec Copilot, ils perdent beaucoup plus de temps en raison de builds lents, de tâches fastidieuses dans l'environnement de développement et de retards dans les révisions de code. Cela met en évidence que l'IA n'est pas une solution complète pour toutes les inefficacités de développement. Nik Malykhin a découvert que l'utilisation efficace d'un assistant IA nécessite d'abord d'articuler et de codifier ses propres règles de codage et son style de collaboration. Cela nécessite un effort métacognitif pour décharger le travail cognitif. Charity Majors distingue entre le code jetable et le code durable, affirmant que le coût est déterminé par la maintenance, l'extensibilité et la compréhension, et non par la méthode de création. Le code jetable est bon marché car il n'est pas destiné à une maintenance à long terme. Jim Highsmith suggère de considérer l'IA comme une "Intelligence Alternative", mettant en avant son processus de pensée différent plutôt que comme une déficience. Rod Johnson souligne le rôle critique des modèles de domaine en tant que forme de mémoire pour les systèmes d'IA. L'Event Sourcing offre une mémoire épisodique à travers des historiques d'événements immuables. Les modèles de repository fournissent des interfaces de mémoire spécifiques au domaine qui préservent la signification commerciale. Les contextes délimités partitionnent la mémoire sémantiquement, évitant la pollution de concepts. Les agrégats agissent comme des clusters de mémoire cohérents avec des limites de cohérence, cruciaux pour le comportement fiable des agents.

Sriram Narayan poursuit son article sur l'intelligence d'impact en détaillant cinq actions qui peuvent être entreprises pour améliorer l'intelligence d'impact : introduire une gestion de la demande robuste, rembourser la dette de mesure, introduire la validation de l'impact, offrir à votre directeur financier/directeur des opérations une alternative au retour sur investissement (ROI), équiper vos équipes.

La productivité des travailleurs du savoir est difficile à quantifier et est souvent déconnectée des résultats commerciaux directs. Le manque de compréhension entraîne de nombreuses initiatives, des dépenses technologiques excessives et des efforts mal choisis pour améliorer cette productivité. Sriram Narayan commence un article qui examine comment éviter cela en développant une intelligence sur l'impact commercial de leur travail à travers un réseau qui relie la production à l'impact proximal et en aval.

Birgitta Böckeler rend compte d'une série d'expériences que nous avons menées pour explorer jusqu'où l'intelligence artificielle générative peut actuellement être poussée pour développer de manière autonome des logiciels de haute qualité et à jour sans intervention humaine. En tant que cas d'étude, nous avons créé un workflow agentic pour construire une application Spring Boot simple de bout en bout. Nous avons constaté que le workflow pouvait finalement générer ces applications simples, mais avons encore observé des problèmes significatifs dans les résultats - en particulier lorsque nous avons augmenté la complexité. Le modèle générerait des fonctionnalités que nous n'avions pas demandées, ferait des hypothèses changeantes autour des lacunes dans les exigences et déclarerait le succès même lorsque les tests échouaient. Nous avons conclu que bien que beaucoup de nos stratégies - telles que des prompts réutilisables ou une application de référence - soient précieuses pour améliorer les workflows assistés par l'IA, un humain dans la boucle pour superviser la génération reste essentiel.

Matteo Vaccari montre pourquoi la métrique commune d'acceptation du code IA a un grand défaut. Un modèle de langage large (LLM) peut être utile même si vous jetez son code.

Il est devenu une habitude courante pour les développeurs de donner une personnalité à des Modèles de Langage de Grande Taille (LLM) lorsqu'ils travaillent avec eux. Je décrit quatre d'entre eux, un âne entêté, un génie, une machine à sous et Uriah Heep.

Korny Sietsma a un excellent exemple de la façon dont l'utilisation d'un modèle de langage large (LLM) pour la programmation est très utile, mais avec des limitations… et un essai général réfléchi sur pourquoi l'hype et les sceptiques inflexibles manquent tous deux le train. Ici, un professeur de poésie réfléchit (lien cadeau) sur la valeur et les limites de l'IA dans l'écriture : L'un des défis réels ici est la façon dont l'IA mine la valeur humaine de l'attention, et l'individualité qui en découle. Ce que nous risquons de perdre, ce n'est pas juste une compétence, mais un mode d'être : le plaisir de l'invention, la vie sentie de l'esprit au travail.

« Trois articles que j'ai appréciés hier : Stephen O'Grady parle de la façon dont les outils d'IA générique brisent deux constantes courantes avec les outils de développement : ils sont prêts à passer d'un outil d'IA générique à un autre et ils sont prêts à payer pour eux. Cela implique que ce n'est pas trop tard pour que de nouveaux outils apparaissent, et que l'adoption d'entreprise sera ralentie par un manque de consensus sur la direction à prendre. Pete Hodgson poursuit son excellent écriture sur l'IA générique en proposant une approche pour guider les ingénieurs vers un avenir assisté par l'IA, centrée autour du concept d'autonomie alignée. Il préconise une phase d'expérimentation explicite, suivie d'un soutien à l'adoption et de la mesure de leur impact. Charity Majors réfléchit à sa carrière. J'ai vraiment résonné avec ses mots : « Je pense que je suis moins intéressé par mon propre bonheur (quel que soit ce que cela signifie) que je ne le suis par faire du travail qui en vaut la peine. » »

Même avec les LLM, Birgitta Böckeler se soucie toujours du code : « Les LLM ne sont PAS des compilateurs, des interpréteurs, des transpileurs ou des assembleurs de langage naturel, ce sont des inféreurs. »

Dans des environnements complexes, les caractéristiques des généralistes experts rendent Gitanjali et moi-même en mesure de compléter notre article en résumant la valeur de cette compétence pour mener les tâches à leur terme. Unmesh, cette compétence.

Alors que nous avons passé cet article à louer l'Expert Généraliste, Unmesh, Gitanjali et moi-même ne nions pas simultanément la valeur des connaissances spécialisées. Pour être le plus efficace, une équipe a besoin de certaines compétences spécialisées. Nous avons également observé que les capacités d'Expert Généraliste sont considérablement plus précieuses lorsqu'elles travaillent avec les Modèles de Langage de Grande Échelle (LLM).

Pour développer des généralistes experts, nous devons porter notre attention sur les fondamentaux plutôt que sur les outils. Par exemple, Unmesh, Gitanjali et moi décrivons un atelier que nous avons utilisé pour briser les silos du développement d'applications, de l'ingénierie de données et du devops.

Comme la plupart des bavards dans ce domaine, j'ai prêté beaucoup d'attention au rôle que les systèmes d'IA générative pourraient jouer dans le développement logiciel. Je pense que l'apparition des LLM (Large Language Models) changera le développement logiciel dans une mesure similaire à la transition de l'assembleur aux premiers langages de programmation de haut niveau. Le développement ultérieur des langages et des frameworks a augmenté notre niveau d'abstraction et notre productivité, mais n'a pas eu d'impact de cette ampleur sur la nature même de la programmation. Les LLM sont en train d'avoir cet impact, mais avec la distinction que ce n'est pas juste une augmentation du niveau d'abstraction, mais également une obligation de réfléchir à ce que signifie programmer avec des outils non déterministes.

Nous avons deux points de contrôle cruciaux pour détecter - et ensuite cultiver - des généralistes experts. Unmesh, Gitanjali et moi examinons les embauches et la progression de carrière.

Unmesh, Gitanjali et moi terminons notre liste des caractéristiques d'un généraliste expert en décrivant comment ces personnes privilégient les connaissances fondamentales dans un domaine, possèdent un mélange de compétences larges et approfondies, et savent comment développer un sens grossier mais perçant - une sympathie - pour les domaines apparentés.

« À mesure que les systèmes informatiques deviennent plus sophistiqués, nous avons vu une tendance croissante à valoriser les spécialistes approfondis. Mais nous avons constaté que nos collègues les plus efficaces possèdent une compétence qui découle de la maîtrise de plusieurs spécialités. Nous commençons donc à reconnaître explicitement cette compétence comme une compétence de premier plan, celle d'« Expert Généraliste ». C'est le premier épisode d'un article détaillant notre vision de cette compétence, en commençant par les trois premières caractéristiques d'un Expert Généraliste. »

Durant les dernières semaines, plusieurs « agents de codage en arrière-plan autonomes » ont été mis en ligne. Birgitta Böckeler a tenté de confier une tâche à OpenAI Codex pour voir ce qu'elle pouvait apprendre. Elle décrit ici une exécution particulière de Codex, pour nous aider à jeter un coup d'œil derrière les scènes et à faire quelques observations sur sa contribution à notre travail.

L'auteur a configuré Google Analytics sur son site web en 2010 pour suivre les vues de pages, trouvant les données intéressantes et parfois utiles. Cependant, Google collecte plus d'informations que simplement les vues de pages, et l'auteur trouve le suivi trop envahissant. Après avoir découvert certaines informations, l'auteur a modifié son code Google Analytics pour désactiver certaines fonctionnalités de suivi, visant à éviter de devoir afficher un bandeau de cookies et à toujours suivre les vues. Le code modifié semblait fonctionner initialement, mais après quelques semaines, les vues de pages signalées par Google Analytics ont chuté drastiquement. L'auteur a utilisé Google Tag Assistant, qui indiquait que les événements de vue de page étaient envoyés correctement, mais les vues de page ne s'affichaient pas dans les données de Google Analytics. L'auteur est incertain sur la façon de procéder, ne voulant pas investir trop de temps ou d'argent pour résoudre le problème. Il a considéré des options de suivi alternatives, mais les a trouvées trop coûteuses, et les solutions open-source trop intensives en effort. L'auteur peut devoir vivre sans analytics, priorisant l'écriture et la rédaction sur le suivi des données du site web.

Le conseil de Bruce Eckel aux écrivains est de lire leur brouillon à voix haute afin d'identifier les passages qui sonnent faux et nécessitent des corrections. Ce conseil est particulièrement utile pour les écrivains qui cherchent à adopter un ton conversationnel dans leur écriture. Lire à voix haute aide à éliminer la prose flasque, qui peut être de style corporatif ou académique. La prose corporative donne souvent l'impression qu'elle pourrait provenir d'une société de conseil comme Accenture. La voix passive est également généralement déconseillée. Prononcer les mots au fur et à mesure de l'écriture peut aider à déclencher la partie du cerveau qui traite les mots parlés, rendant la fadeur plus perceptible. L'objectif est d'adopter un ton conversationnel, comme si l'on expliquait des concepts à des amis dans un pub. En matière d'écriture, on apprend souvent à écrire différemment de la façon dont on parle, mais le ton conversationnel rend la prose plus engageante. Lire à voix haute peut aider à éliminer la prose flasque et à la rendre plus concise et efficace. L'auteur prononce constamment les mots silencieusement pendant qu'il écrit pour parvenir à ce ton conversationnel.

"L'an dernier, lors de la conférence Goto à Copenhague, mon ami James Lewis m'a interviewé et Goto vient de publier la vidéo. J'y parle de l'époque où j'ai appris la conception itérative avec Kent Beck, des dangers que représentent les propriétaires de produits qui interfèrent avec la communication métier-développeur, et de l'écriture du manifeste agile. Il m'a spécifiquement demandé à propos de mon essai "La conception est-elle morte ?". Il y a également des questions du public qui demandent si la programmation en binôme est une mauvaise chose pour les introvertis comme nous (non), et (inévitablement) le rôle des modèles de langage LLM pour les programmeurs d'aujourd'hui.

La modélisation des menaces est une pratique d'ingénierie système où les équipes examinent la circulation des données au sein des systèmes afin d'identifier les points de défaillance – une action apparemment simple qui révèle des risques de sécurité que les outils automatisés ne peuvent pas anticiper. Souvent, cette tâche est effectuée par des analystes de sécurité en tant qu'activité distincte ou préalable, mais Jim Gumbly a écrit un article en 2020 expliquant comment les équipes pouvaient le faire par le biais de petits travaux réguliers. Aujourd'hui, Gayathri Mohan s'associe à Jim pour réécrire cet article, intégrant les enseignements tirés de la pratique et de l'enseignement de cette méthode au cours des dernières années. En particulier, ils ont étendu leur approche pour réaliser la modélisation des menaces avec les équipes plateforme.

"Les outils qui traitent les diagrammes comme du code, tels que PlantUML, sont inestimables pour communiquer le comportement complexe des systèmes. Mais Unmesh Joshi a souvent souhaité une extension pour parcourir ces diagrammes étape par étape. Cependant, étendre des outils établis comme PlantUML implique souvent un setup initial significatif - parsing, scripts de build, code de visualiseur, empaquetage - assez de "plomberie" pour décourager la mise en œuvre rapide. Il raconte maintenant comment il a utilisé un modèle de langage (LLM) pour construire une petite extension ajoutant une lecture étape par étape aux diagrammes de séquence PlantUML. Cela illustre comment la conception de la syntaxe, l'analyse, la génération de code, l'automatisation de la build et un visualiseur HTML ont été développés de manière itérative à travers une conversation avec un LLM - transformant les tâches fastidieuses en étapes gérables."

Nous avons longtemps reconnu que les environnements de développement représentent un point faible dans la chaîne d'approvisionnement de logiciels. Jim Gumbley et Lilly Ryan explorent comment les assistants de codage agents élargissent la surface d'attaque des chaînes d'approvisionnement de logiciels et quels mesures nous devons prendre pour sécuriser la sécurité lors de leur utilisation.

Alors que les LLM (Large Language Models) excellent dans la génération de texte cohérent basé sur leurs données d'entraînement, ils peuvent également avoir besoin d'interagir avec des systèmes externes. Kiran Prakash décrit comment nous les faisons construire des appels de fonction externes pour cela. Le LLM n'exécute pas directement ces appels, mais au lieu de cela, il crée une structure de données qui décrit l'appel, en passant cela à un programme séparé pour exécution et traitement supplémentaire. La prompt du LLM inclut des détails sur les appels de fonction possibles et lorsqu'ils devraient être utilisés.

Créer une interface utilisateur qui visualise une structure du monde réel — comme le miroir du télescope de trente mètres — pourrait sembler une tâche qui exige une connaissance approfondie de la géométrie, de D3.js et des graphiques SVG. Mais avec un Grand Modèle de Langage (GML) comme Claude ou ChatGPT, vous n'avez pas besoin de tout savoir d'emblée. Unmesh Joshi décrit comment travailler avec un GML lui a permis d'obtenir un prototype fonctionnel même s'il n'est pas familier avec la technologie sous-jacente.

Il y a quelques mois, mon collègue Shayan Mohanty a publié un aperçu technique de la série d'articles décrivant les modèles d'IA Deepseek. Il a maintenant retravaillé cet article, en ajoutant plus d'explications afin de le rendre plus accessible à ceux d'entre nous qui n'ont pas d'expérience dans la construction de ce type de modèles.

Les éditeurs d'IA comme Cursor peuvent générer du code avec une vitesse remarquable en utilisant les modèles de langage (LLM), en gérant les parties répétitives et en fournissant des extraits de code fonctionnels pour diverses tâches. Cependant, lors de la construction de systèmes robustes, la correction fonctionnelle n'est que le point de départ. Le code doit également être sûr, prévisible, maintenable et exempt de effets secondaires subtils. Unmesh Joshi démontre, à travers un dialogue entre un développeur et un LLM, à quel point les conseils d'experts sont cruciaux pour transformer un extrait de code initial, potentiellement non sécurisé, en un composant robuste et prêt pour le système.

Certaines personnes ont demandé combien de personnes ont cliqué sur les liens de ces publications sur les réseaux sociaux. J'ai ajouté quelques informations supplémentaires à l'article, en partie pour expliquer pourquoi je ne dispose pas de ces informations, et en partie pour montrer les données sources globales du trafic sur le site.

Il y a quelques années, à chaque fois que je publiais un nouvel article ici, je me contentais de l'annoncer sur Twitter. Cependant, depuis le "Muskover" (jeu de mots possible avec le nom de Elon Musk et une éventuelle métamorphose de Twitter, à préciser selon le contexte), son importance a décliné, et je publie maintenant des mises à jour sur plusieurs services. Pour comparer l'engagement sur ces services, j'ai examiné les partages, les "likes" et les réponses de deux douzaines de mes articles récents.

J'ai toujours aimé lire, et pendant la majeure partie de ma vie, j'ai particulièrement apprécié lire de l'histoire. J'ai entendu beaucoup de bien des livres de Robert Caro, mais leur taille m'a toujours dissuadé. Finalement, avec la disponibilité récente de son premier livre en format ebook, j'ai décidé de me lancer. Ces livres sont trop bons pour que je puisse m'en échapper.

En tant que développeur de bibliothèques, vous pouvez créer une utilité populaire sur laquelle des centaines de milliers de développeurs comptent quotidiennement, comme lodash ou React. Au fil du temps, des modèles d'utilisation peuvent émerger qui dépassent votre conception initiale. Lorsque cela se produit, vous devrez peut-être étendre une API en ajoutant des paramètres ou en modifiant les signatures de fonction pour résoudre les cas limites. Le défi consiste à déployer ces changements cassants sans perturber les flux de travail de vos utilisateurs. Juntao Qiu commence un article pour expliquer comment nous pouvons utiliser des codemods pour relever ce défi. Les codemods sont un outil qui automatisent les transformations de code à grande échelle, permettant aux développeurs d'introduire des changements cassants d'API et de réorganiser des bases de code héritées.

Les jetons de conception sont des décisions de conception fondamentales représentées sous forme de données. Andreas Kutschmann explique comment ils fonctionnent et comment les organiser pour équilibrer la scalabilité, la maintenabilité et l'expérience développeur.

Une fois que nous avons conçu nos premiers produits de données, Kiran Prakash termine son article en nous guidant à travers les étapes suivantes : identifier les modèles courants, améliorer l'expérience du développeur et gérer la gouvernance.

Après avoir obtenu un premier produit de données, Kiran Prakash nous guide à travers les étapes suivantes : couvrir des cas d'utilisation similaires pour généraliser le produit de données, déterminer les domaines dans lesquels les produits s'intègrent et tenir compte des objectifs de niveau de service.

De plus en plus, l'industrie reconnaît la valeur de créer des produits de données comme un principe d'organisation fondamental pour les données analytiques. Kiran Prakash a aidé de nombreux clients à concevoir leurs produits de données et partage ce qu'il a appris. En particulier, son approche méthodique ne commence pas par réfléchir à des données qui pourraient être utiles à partager, mais travaille plutôt à partir des besoins des consommateurs d'un produit de données.

Une nouvelle fonctionnalité d'assistance de codage très puissante a fait son apparition dans GitHub Copilot à la fin d'octobre. Cette nouvelle capacité d'« édition multi-fichier » élargit la portée de l'assistance de l'IA des petites suggestions localisées aux implémentations plus importantes sur plusieurs fichiers. Birgitta Böckeler teste cette nouvelle fonctionnalité et découvre à quel point ses modifications sont utiles, et se demande quels boucles de rétroaction sont nécessaires avec elles.

Avec la récente augmentation d'activité technologique sur Bluesky, j'ai décidé que je vais commencer à poster là-bas en plus de mes emplacements actuels. J'ai également rassemblé mes réflexions générales sur l'état des médias sociaux et la façon dont je les utilise, maintenant que deux ans se sont écoulés depuis The Muskover.

Matthew Foster et John Mikel Amiel concluent leur compte-rendu de la manière dont ils ont modernisé de manière progressive une application mobile en examinant les résultats de leur travail. Ils ont réussi à raccourcir significativement le temps jusqu'à la nouvelle valeur, et ont constaté que les modifications apportées à la nouvelle application pouvaient être préparées en environ la moitié du temps qu'il fallait pour le faire sur l'ancien codebase.

Matthew Foster et John Mikel Amiel plongent dans les détails de la modernisation incrémentale d'une application mobile héritée. Ils examinent comment implanter la figue étrangleuse dans l'application existante, mettre en place une communication bidirectionnelle entre la nouvelle application et l'ancienne, et assurer des tests de régression efficaces sur l'ensemble du système.

Mes collègues sont souvent impliqués dans la modernisation des systèmes hérités, et notre approche consiste à le faire de manière incrémentale. Faire cela avec une application mobile soulève certains défis spécifiques. Matthew Foster et John Mikel Amiel Regida partagent leurs expériences d'un récent engagement pour le faire, en passant d'une application héritée monolithique à une utilisant une architecture de micro-applications modulaires.