Comment je programme avec les LLM

Le deuxième problème est que nous pouvons faire mieux. Je suis heureux que nous vivions désormais à une époque où les programmeurs écrivent leurs propres tests, mais nous ne nous appliquons pas aux mêmes normes avec les tests qu’avec le code de production. C’est un compromis raisonnable ; il n’y a qu’un nombre limité d’heures dans la journée. Mais ce qui manque aux LLM en prouesses arithmétiques, ils le compensent en enthousiasme.

Demandons un test encore meilleur.

Dans les tests, implémentez la version la plus simple et la plus lisible du code standard pour les quartiles sur un ensemble fixe de valeurs connues dans une tranche. Passez ensuite les cas de test via le code standard et l’échantillonneur de réservoir et confirmez qu’ils se trouvent à un epsilon les uns des autres. Structurez le code de comparaison de manière à ce qu’il puisse également être utilisé dans un test fuzz.

Cela nous a donné un nouveau code de test :

// referenceQuartiles calculates the exact quartiles for a slice of float64 values  
// using linear interpolation, matching the behavior expected from the sampler.  
func referenceQuartiles(data ()float64) (q1, median, q3 float64) { … }

// compareQuartiles checks if two sets of quartiles are within epsilon of each other.  
// Returns true if they match within the tolerance, false otherwise.  
func compareQuartiles(q1a, meda, q3a, q1b, medb, q3b, epsilon float64) bool { … }

// checkQuartiles is a test helper that compares sampler output against the reference  
// implementation and reports any differences.  
func checkQuartiles(t *testing.T, data ()float64, epsilon float64) {  
   t.Helper()  
    
   // Get reference values  
   wantQ1, wantMed, wantQ3 := referenceQuartiles(data)  
    
   // Get sampler values using a large reservoir for accuracy  
   qs := NewQuartileSampler(1000)  
   for _, v := range data {  
       qs.Add(v)  
   }  
   gotQ1, gotMed, gotQ3 := qs.Quartiles()  
    
   if !compareQuartiles(gotQ1, gotMed, gotQ3, wantQ1, wantMed, wantQ3, epsilon) {  
       t.Errorf("Quartiles mismatch:\ngot  (q1=%v, med=%v, q3=%v)\nwant (q1=%v, med=%v, q3=%v)\nepsilon=%v",  
           gotQ1, gotMed, gotQ3, wantQ1, wantMed, wantQ3, epsilon)  
   }  
}

Le test original ci-dessus a été retravaillé pour utiliser checkQuartiles, et nous avons quelque chose de nouveau :

func FuzzQuartileSampler(f *testing.F) {  
   // Add some seed corpus  
   f.Add(()float64{1, 2, 3, 4, 5})  
    
   f.Fuzz(func(t *testing.T, data ()float64) {  
       // Use a larger epsilon for fuzzing since we might get more extreme values  
       checkQuartiles(t, data, 0.2)  
   })  
}

C’est amusant parce que c’est faux. Ma course gopls l’outil dit immédiatement :

fuzzing arguments can only have the following types:
    string, bool, float32, float64,
    int, int8, int16, int32, int64,
    uint, uint8, uint16, uint32, uint64,
    ()byte

Recoller cette erreur dans le LLM lui permet de régénérer le test fuzz de telle sorte qu’il soit construit autour d’un func(t *testing.T, data ()byte) fonction qui utilise math.Float64frombits pour extraire les flottants de la tranche de données. Des interactions comme celle-ci nous incitent à automatiser les commentaires des outils ; tout ce dont il avait besoin était le message d’erreur évident pour faire de solides progrès vers quelque chose d’utile. Je n’étais pas nécessaire.

Une enquête rapide sur les dernières semaines de mon historique de discussion LLM montre (qui, comme je l’ai mentionné plus tôt, ne constitue en aucun cas une analyse quantitative appropriée) que dans plus de 80 % des cas, il y a une erreur d’outil, le LLM peut faire des progrès utiles sans que j’ajoute aucune idée. Environ la moitié du temps, cela peut résoudre complètement le problème sans que je dise quoi que ce soit de notable. J’agis simplement en tant que messager.