Cette semaine, le bulletin est parrainé par Débloqué.

[Webinaire] Pouvez-vous prouver que l'IA fonctionne ?

L'IA est dans votre workflow d'ingénierie. Alors que le jeton dépense le montre, le débit ne fait pas. L'humain est encore beaucoup dans la boucle, et c'est un problème de contexte.

Rejoignez en direct le 19 août (FREE) pour apprendre:

• Les 4 mesures pour mesurer l'écart où les gains s'écoulent avant la production.

• Les 8 étapes de maturité contextuelle, les murs spécifiques qui captent vos mesures, et un outil gratuit pour identifier où se trouve votre équipe.

• Pourquoi plus de MCP et de fenêtres de contexte plus grandes sont assez, et ce qu'il faut pour obtenir la valeur réelle de vos agents.

Inscrivez-vous maintenant

Merci à Débloqué pour avoir sponsorisé cette newsletter. Revenez à la pensée de cette semaine !

Introduction

Plus tôt cette année, j'étais à San Francisco en train de parler avec différentes entreprises, et l'une d'entre elles était Larridine. Funnily, je suis venu en plein milieu de leur réunion d'équipe (désolé les gars).

Ils construisent une plateforme pour ce que beaucoup d'entreprises se demandent de nos jours → comment mesurer l'adoption de l'IA et la fluidité de l'IA.

Des choses qui se sont particulièrement distinguées de nos conversations :

• Ils sont une véritable définition d'une équipe d'IA-native, l'IA étant au cœur de tout ce qu'ils font.

• Ils sont de grands défenseurs du développement axé sur les spécifications. La spécification doit être presque parfaite avant qu'ils ne commencent avec l'implémentation.

• Chaque ingénieur possède la fonctionnalité de bout en bout → de la création de la spécification à sa mise en œuvre, à l'assurer de fonctionner correctement.

• Ameya Kanitkar, CTO, Larridin, ont mentionné qu'ils aiment aussi travailler avec plus d'ingénieurs de niveau junior, mais ils doivent quitter et respirer l'IA et toujours chercher à améliorer et améliorer dans ce domaine.

• Une grande analogie sur l'utilisation de l'IA → Vous avez une voiture à conduite rapide juste devant vous, pourquoi ne pas l'utiliser?

J'ai parlé avec les devs, et aussi avec Ameya, dont je partage les idées aujourd'hui. Dans l'article d'aujourd'hui, nous allons plonger dans la façon dont ils font le développement de spécifications à Larridin.

Commençons !

Qu'est-ce que le développement axé sur les spécifications?

Il y a beaucoup de définitions différentes, mais voici ce que cela signifie pour moi:

Le développement axé sur les spécifications est une façon de construire un logiciel où vous vous concentrez d'abord sur la construction d'une bonne spécification, puis utilisez l'IA pour mettre en œuvre le projet.

Il y a plusieurs façons d'écrire la spécification, par exemple, Michael Bolin, Codex Tech Lead, utilise Notion pour créer une spécification, puis demande à tous les autres ingénieurs de l'équipe de jeter un coup d'oeil et de fournir des commentaires.

Cela permet de repérer les problèmes à l'avance et améliore la mise en œuvre globale par les LLM. Pour apprendre le processus complet de Michael pour l'ingénierie assistée par l'IA, lire cet article:

La popularité du développement axé sur les spécifications augmente

Je vois dans le développement axé sur les spécifications la façon de construire des logiciels utilisés par de plus en plus d'entreprises, et c'est certainement logique.

Surtout avec le coût des jetons il suffit de continuer à augmenter, vous n'avez pas le luxe de simplement infiniment inviter afin d'obtenir la sortie désirée (à moins que vous travaillez avec des jetons illimités).

Avec une grande spécification, vous pouvez généralement utiliser un modèle de niveau inférieur et obtenir une sortie très similaire, la raison pour laquelle les instructions dans une grande spécification sont très claires.

Donc, c'est aussi le flux de travail que je vois beaucoup d'entreprises utilisent:

• Écrire une spécification (avec l'aide de LLM de niveau supérieur)

• Construire la spécification (avec les LLM de niveau inférieur)

Maintenant, laissez-nous entrer plus de détails sur la façon dont Larridin fait le développement de spécifications!

1. Commencez par un pic d'abord

Ameya a mentionné qu'avant qu'ils commencent à écrire les spécifications, ils prouvent que les choses "Risky" fonctionnent.

Dans le développement logiciel, il ya beaucoup d'inconnus quand vous construisez des choses, et il est impossible d'écrire une spécification complète si vous avez affaire à des inconnus.

Donc, ce qu'ils font est, ils créent un pic tâche de résoudre d'abord ces inconnues d'un projet spécifique.

L'objectif n'est pas de construire un MVP complet, il peut être un petit, laid, travail de qualité à jeter. Juste assez pour répondre à la question, cela fonctionne-t-il réellement?

L'objectif n'est pas de l'étendre ensuite, comme vous le feriez normalement avec le MVP, mais l'objectif est d'éliminer toute incertitude technique, qui, alternativement, contaminerait simplement la spécification avec différentes options.

Quelques exemples:

• Si l'API que vous allez construire a 3 cas de bord, cliquez sur ceux-ci.

• Si tout votre système dépend de la rapidité de votre API, cliquez sur le chemin chaud et mesurez-le.

• Si vous construisez une nouvelle vue qui contient beaucoup d'enregistrements, prouvez que l'API peut renvoyer les résultats assez rapidement.

Et un autre exemple que Ameya a partagé de leur travail:

Nous voulions créer un modèle pour mesurer la fluence de l'AI. Nous avons donc écrit un pic pour nous assurer que notre logique fondamentale fonctionne. Une fois que nous avons été satisfaits des résultats, le reste de la conception a suivi (queue, surveillance, base de données, etc.). Spec était simplement pour assurer le fonctionnement logique de base et est jeton efficace.

Le but est d'arrêter quand vous avez une réponse, pas quand le code est joli. Si vous êtes inquiet de nommer des variables, des fonctions et une structure de fichier, arrêtez, cela signifie que vous mettez trop de réflexion dans les détails de l'implémentation.

2. Promouvoir la mise en œuvre de référence

Une fois que le pic fonctionne, ne le jette pas. C'est maintenant votre implémentation de référence.

C'est maintenant une référence que vous pouvez pointer le LLM et dire que je sais que ce modèle fonctionne, parce que ici il fonctionne !

Ameya croit que c'est l'une des choses les plus sous-estimées quand vous êtes en train de développer des spécifications. Un exemple de travail vaut beaucoup plus qu'une page complète dans les spécifications. C'est ainsi que le modèle arrête d'halluciner et arrête d'envisager le comportement ainsi.

La raison en est que le modèle peut maintenant vérifier la référence et voir l'approche qui a été adoptée pour mettre en œuvre cette partie spécifique.

L'implémentation de référence appartient à la repo dans un endroit connu. Toutes les références se trouvent à un endroit : spec/spikes/référence/nom de référence.

Et aussi un autre conseil ici est de commenter les parties spécifiques qui prouvent l'approche, et aussi ajouter des commentaires aux parties où les choses sont codées en dur, peut-être que le traitement des erreurs est manquant, ou l'implémentation n'est pas sur le point.

Plus vous donnez d'informations dans la base de codes, plus la mise en œuvre globale par le LLM sera précise.

Ameya pense qu'un pic sans commentaires peut être tout aussi dangereux que de ne pas le faire du tout, parce que le modèle peut simplement reproduire les mauvaises parties aux côtés des bonnes.

3. Écrivez les spécifications

Maintenant que vous avez l'implémentation de référence avec des commentaires, il est temps d'écrire la spécification! Les spécifications doivent être suffisamment détaillées pour être transmises à un ingénieur junior ou à un petit modèle.

Vous pouvez et devriez, bien sûr, utiliser l'IA pour vous aider à écrire les spécifications. Lorsque vous utilisez l'IA pour écrire les spécifications, Ameya suggère de forcer le modèle à répéter ce qui doit être fait, lister toutes les hypothèses, et aussi signaler toute sorte d'ambiguïté.

Donc, dans le cas où il reste des hypothèses et ambiguïtés non gérées, vous pouvez soit créer un nouveau pic ou mettre à jour celui existant.

Voici également une structure de spécifications souhaitée qu'ils utilisent chez Larridin:

• Déclaration du problème en haut

Ce que vous résolvez et pour qui. Un paragraphe.

• Autres objectifs

Ce que ce système ne fera pas explicitement. C'est là que vous sortez la moitié de la suringénierie avant qu'elle ne commence.

• Hypothèses

Les détails que vous avez déjà décidé, de sorte que le modèle ne les sélectionne pas silencieusement. Curseur ou pagination offset ? Chargement paresseux des composants ? Tu dois écrire tout ça.

• Mise en œuvre des références

Lien vers la pointe. Demander (si ce n'est pas déjà dans les commentaires) quelles parties sont des raccourcis, et quelles parties prouvent l'implémentation.

• Architecture

Modèle de données, limites des modules, interfaces, gestion des erreurs, etc.

• Plan d'essai

Quels tests d'unité, d'intégration et/ou e2e sont nécessaires et comment ils doivent être effectués. Plus sur cela dans la prochaine phase.

Exemple d'une bonne spécification partagée par Ameya: Exemple complet de la spécification.

Et une recommandation qu'il a partagée :

Ma recommandation est d'écrire la plus petite spécification qui précise sans ambiguïté le système. Si une section a l'impression d'être molle, coupez-la. Si une décision semble évidente, écrivez-la de toute façon. C'est faux pour vous C'est pas pareil que C'est évident pour le modèle.

4. Rédiger/ajuster le plan d ' essai avant le plan de mise en œuvre

Le développement axé sur les essais et le développement axé sur les spécifications sont faits l'un pour l'autre. Une fois que vous savez ce que le système fait, vous pouvez écrire le plan de test avant le plan de mise en œuvre, pas après.

Le plan de test fait partie de la spécification, et vous devriez y aller et ajuster si quelque chose n'est pas bien ou quelque chose manque.

Il est important que votre plan de test utilise des points de balle ou que la séparation entre les tests soit claire. Et aussi vous devez surveiller tous les tests ambitieux.

Voici 2 exemples :

• Au lieu de "Handles grandes entrées gracieusement" il devrait être "process 10k lignes en moins de 2 secondes avec la mémoire sous 500 Mo.

• Au lieu de "Fails security on wrong input" il devient "returns a 400 with a specific error code when the payload is absented the customer id field".

Il n'y a pas besoin d'implémenter les tests encore, il est important que vous les énumériez, nommiez chacun, et spécifiez les entrées et les sorties attendues.

Cette liste devrait être une définition claire de ce qui a été fait, à laquelle le plan de mise en œuvre sera comparé.

Nous allons passer par le plan de mise en œuvre dans la prochaine étape!

5. Créer le plan de mise en œuvre

Nous avons maintenant la mise en œuvre de référence prête, la spécification est prête, et le plan de test est sur le point. Maintenant, il est temps d'aller à la dernière étape, qui est de créer le plan de mise en œuvre.

Le plan de mise en œuvre est la partie ennuyeuse. Une séquence d'étapes qui transforme la spécification en code. Fichier par fichier, fonction par fonction, chaque étape est clairement définie, il n'y a donc aucune chance pour un LLM d'aller dans une direction différente.

C'est beaucoup plus détaillé qu'une spécification. Si la spécification est d'environ 800 lignes, alors le plan de mise en œuvre serait d'environ 3k lignes.

Donc, tout ce que vous devez faire ici est de demander à un LLM de créer un plan d'implémentation basé sur la spécification, et de le sortir dans un dossier séparé. Vous pouvez avoir un dossier séparé dans votre repo appelé plans.

Une fois le plan créé, il est important que vous fassiez un examen détaillé. Si vous trouvez que le plan de mise en œuvre fait un nouvel appel architectural mi-mise en œuvre, qui est un signal que la spécification n'était pas terminée.

Assurez-vous de revenir en arrière et de la mettre à jour, ne mettez à jour manuellement le plan d'implémentation avec les détails de l'architecture et laissez la spécification inchangée.

Le but de ce workflow est que vous arrêtez de prendre des décisions dans la phase 3, où vous avez écrit la spécification. Faire de nouvelles dans la dernière phase peut introduire silencieusement des problèmes.

Voici également un exemple de bon plan de mise en œuvre: Exemple complet du plan de mise en œuvre. Et vous pouvez trouver beaucoup d'autres exemples dans le même dossier.

6. Appliquer

Donc une fois que vous êtes satisfait du plan de mise en œuvre, vient maintenant la partie facile. Vous pouvez utiliser n'importe lequel des petits LLM pour faire cela. Même Haiku fonctionne bien.

Tout ce que vous devez faire est de dire au LLM de créer le code basé sur le plan de mise en œuvre. C'est votre choix si vous voulez créer le PR vous-même, ou si vous voulez diviser le projet en PR séparés, ou dire à un LLM de créer les PR, basé sur une convention spécifique, etc.

Une fois que vous avez le plan de mise en oeuvre, la mise en œuvre est la partie facile.

Quand utiliser le développement guidé par les spécifications (et quand pas à)

Le développement axé sur les spécifications est certainement un frais supplémentaire pour les petits changements. Si vous faites un petit changement, comme refactoring d'un fichier spécifique ou un petit ajustement d'une fonctionnalité, il est certainement pas la bonne façon de le faire.

Demander → revoir le code est la bonne façon d'aller pour ces petits changements.

Mais quand vous travaillez sur un projet plus grand, et surtout si vous ne savez pas si il est même réalisable en premier lieu, il peut vous sauver un LOT de temps réécrire et examiner mauvais code généré par l'IA.

Et aussi prendre des décisions à la volée est généralement bien pire que de prendre des décisions au préalable. Surtout si vous prenez des décisions d'architecture importantes. Créer les spécifications vous force à vraiment penser si c'est la bonne approche.

Si vous n'avez qu'à vous lancer et à vous ajuster au fur et à mesure que vous partez, alors vous ne pensez pas vraiment à savoir si l'approche est correcte ou non.

Dernier mot

Pour terminer cet article:

Comme vous pouvez le voir dans le processus qu'ils utilisent chez Larridin, la pensée claire et le bon jugement sont les parties les plus importantes. Une fois que vous avez fait cela, écrire le code est la partie facile. Gardez toujours cela à l'esprit.

Merci à l'équipe Larridin pour l'hospitalité et Ameya pour avoir partagé toutes ces idées intéressantes sur leur fonctionnement!

Vous avez aimé cet article ? Assurez-vous de cliquer sur le bouton comme.

Rétroaction ou ajout? Assurez-vous de commenter.

Tu connais quelqu'un qui trouverait ça utile ? Assurez-vous de partager ce post.

Chaque fois que vous êtes prêts, voici comment je peux vous aider davantage

• Vous souhaitez parrainer ce bulletin? Vérifiez les options de parrainage ici.

• Découvrez mon livre -Le Multiplier Mindset--qui sort plus tard cette année, ici.

• Jetez un coup d'oeil au swag cool dans le magasin de leadership d'ingénierie ici.

• Tu veux travailler avec moi ? Vous pouvez voir toutes les options ici.

Contactez-nous

Vous pouvez me trouver sur LinkedIn, X, YouTube, Bleu ciel, Instagram ou Fils.

Si vous souhaitez faire une demande sur un sujet particulier que vous souhaitez lire, vous pouvez m'envoyer un email à info@gregorojstersek.com.

Ce bulletin est financé par des abonnements payants de lecteurs comme vous.

Si vous n'êtes pas déjà, envisagez de devenir un abonné payant pour recevoir l'expérience complète!

Vérifiez les prestations du régime payé

Vous êtes plus que les bienvenus pour trouver quels sont vos intérêts ici et l'essayer dans votre cas particulier. Faites-moi savoir comment ça s'est passé ! Les sujets portent normalement sur l'ingénierie, le leadership, la gestion, le développement de produits évolutifs, les équipes de construction, etc.