Comment entretenir vos compétences en programmation quand l'IA écrit le code

Pour entretenir vos compétences en programmation, entraînez-vous volontairement, sans assistant, sur les parties du travail que l'IA fait désormais à votre place. Pour la plupart des ingénieurs, cela veut dire déboguer un problème avant de demander de l'aide, lire du code que vous n'avez pas écrit, résoudre un petit problème en partant d'un fichier vide et écrire les tests vous-même. Je commencerais par une ou deux heures par semaine, avec de la régularité. Le reste de la semaine, vous pouvez utiliser l'IA autant que vous voulez.

En bref

• Les compétences de réflexion s'érodent plus que les compétences pratiques. Des pilotes habitués à voler avec le pilote automatique ont conservé leur capacité à piloter à la main, mais ont eu plus de mal avec la navigation et la détection des pannes (Casner et al., Human Factors, 2014). Chez les développeurs, les équivalents les plus proches sont le débogage et la lecture de code.
• La perte de compétences peut apparaître en quelques mois. Dans une étude observationnelle, des médecins qui utilisaient l'IA pour les coloscopies ont détecté moins de lésions précancéreuses une fois l'IA désactivée, 22,4 % contre 28,4 % auparavant (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025).
• Testez-vous régulièrement. Pouvez-vous expliquer le dernier diff que vous avez mergé ? Pouvez-vous déboguer un test en échec pendant 20 minutes sans écrire de prompt ? Sinon, ce sont ces compétences qu'il faut travailler.
• Une routine hebdomadaire suffit. Résolvez un petit problème à la main, déboguez avant de demander à l'IA, relisez les diffs de l'IA comme s'ils venaient d'un junior, lisez le code source de la bibliothèque standard et écrivez les tests vous-même.
• Demandez « pourquoi » à l'IA, pas « corrige ». Prévoyez d'abord la réponse, puis comparez. Les ingénieurs qui apprenaient une nouvelle bibliothèque en posant des questions à l'IA l'ont apprise à peu près aussi bien que ceux qui codaient à la main. Ceux qui lui confiaient le problème ont le moins appris (Anthropic, 2026).

Quelles compétences s'érodent en premier quand l'IA écrit votre code ?

Les compétences qui s'érodent en premier sont celles où il faut raisonner, comme le débogage, la lecture de code et l'arbitrage entre plusieurs options. La maîtrise de la syntaxe s'érode beaucoup plus lentement.

L'aviation offre une comparaison utile. Dans une étude de 2014, 16 pilotes de ligne ont piloté un simulateur de Boeing 747-400 et ont été évalués sur le pilotage manuel. Leurs compétences de pilotage à la main étaient « en grande partie intactes ». Les problèmes sont apparus dans les tâches de réflexion : suivre la position de l'avion sans l'écran de navigation, décider de la suite des opérations et remarquer qu'un instrument était tombé en panne (Casner et al., Human Factors, 2014). Les chercheurs ont suggéré que les pilotes conservent ces compétences en restant activement impliqués dans la supervision de l'automatisation.

La médecine a constaté quelque chose de similaire en 2025. Dans quatre centres d'endoscopie en Pologne, des médecins qui utilisaient un outil de détection par IA ont été évalués sur des coloscopies réalisées sans lui. Leur taux de détection des adénomes est passé de 28,4 % avant l'introduction de l'IA à 22,4 % après (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025). Il s'agissait d'une étude observationnelle, pas d'un essai randomisé, mais la baisse s'est produite en quelques mois.

Dans le logiciel, cela concerne cinq compétences.

Le débogage

C'est le débogage qu'il faut surveiller le plus attentivement. Dans l'essai d'Anthropic de 2026, le groupe qui codait à la main a rencontré plus d'erreurs que le groupe IA, et les chercheurs pensent que c'est en travaillant sur ces erreurs que ces participants ont construit leur compétence de débogage (Anthropic, 2026). Si un assistant corrige chaque erreur à votre place, vous ne vous entraînez jamais.

Lire du code inconnu

Quand un agent vous explique une base de code, vous ne vous en faites pas votre propre carte. Cela ne pose pas de problème jusqu'au jour où l'explication est fausse ou où l'agent n'est pas disponible pendant un incident. L'analyse de GitClear portant sur 623 millions de modifications de code a montré que les appels vers du code existant sont passés de 343 à 223 pour mille lignes modifiées entre 2023 et 2026 (GitClear, 2026). Moins de réutilisation va de pair avec moins de lecture de ce qui existe déjà.

Connaître les API de mémoire

La mémorisation compte moins que les autres compétences de cette liste, mais il vous en faut quand même un peu. Inutile de retenir toutes les fonctions de strings. Vous devez en revanche savoir que context.WithTimeout renvoie une fonction d'annulation que vous devez appeler, et que http.Error ne fait pas sortir votre handler. Sans ces connaissances, vous ne pouvez pas savoir quand une suggestion est fausse.

Conception de système et arbitrages

L'IA vous proposera une conception si vous le lui demandez. Choisir entre deux conceptions raisonnables demande du jugement, et le jugement se construit en prenant des décisions et en vivant avec leurs conséquences. Si l'agent choisit la file d'attente, le schéma et la politique de retry, vous ne découvrez jamais lesquelles de vos intuitions étaient justes.

Estimer

Si un assistant fait une partie du travail, votre perception du temps que prennent les choses peut dériver. Dans l'essai de METR en 2025, des développeurs expérimentés ont mis 19 % de temps en plus avec l'IA, mais pensaient après coup qu'elle les avait rendus 20 % plus rapides (METR, 2025). Si vous pouvez vous tromper à ce point sur votre propre vitesse, vos estimations aussi.

Comment savoir si vos compétences déclinent ?

Vous le découvrez en vous testant sans l'assistant, car c'est difficile à remarquer pendant que vous travaillez avec lui. Microsoft Research et Carnegie Mellon ont constaté que les travailleurs du savoir qui avaient le plus confiance dans l'IA déclaraient exercer moins leur esprit critique sur ce qu'elle produit (Lee et al., CHI, 2025).

Faites ces vérifications une fois par mois :

1. Expliquez votre dernier diff mergé. Choisissez une pull request récente écrite en grande partie par l'IA. Expliquez à un collègue, ou à voix haute, pourquoi chaque modification est là. Si vous ne pouvez pas expliquer une modification, vous ne la connaissez pas vraiment.
2. Déboguez pendant 20 minutes sans prompt. Prenez le prochain test en échec ou le prochain rapport de bug et travaillez dessus avec seulement les logs, un débogueur et le code source. Notez si vous avez envie d'ouvrir l'assistant dès les deux premières minutes.
3. Écrivez une petite fonction en partant d'un fichier vide. Parsez un fichier de configuration, relancez un appel HTTP avec backoff ou dédoublonnez une slice en conservant l'ordre. Vérifiez si vous vous souvenez des appels de la bibliothèque standard ou si vous devez chercher chacun d'eux.
4. Prévoyez avant d'exécuter. Avant de lancer un test, notez s'il va passer. S'il échoue, notez ce que dira l'erreur. Si vous vous trompez souvent, votre modèle mental du code s'est éloigné du code.
5. Estimez, puis mesurez. Estimez la durée d'une tâche, puis comparez avec le temps qu'elle a réellement pris. Un écart qui se creuse suggère que vous ne savez plus bien où passe le temps.

Aucune de ces vérifications ne prend longtemps. Si elles vous mettent mal à l'aise, cela vous indique quelle compétence travailler.

Quelle est la différence entre déléguer et sous-traiter votre réflexion ?

Déléguer, c'est confier à l'IA un travail que vous comprenez déjà, pour porter votre attention ailleurs. Sous-traiter, c'est lui confier un travail que vous ne comprenez pas, pour ne jamais avoir à le comprendre. Le premier fait normalement partie du métier d'ingénieur. Le second est ce qui fait s'éroder les compétences.

L'essai d'Anthropic a montré que la façon dont les participants utilisaient l'assistant comptait plus que le fait de l'utiliser ou non, et les chercheurs ont conclu que l'effort cognitif, « et même le fait de rester douloureusement bloqué », est probablement important pour la maîtrise (Anthropic, 2026). Faut-il encore écrire du code à la main ? passe en revue les façons d'utiliser l'IA qui ont obtenu de bons scores.

La recherche sur l'apprentissage explique pourquoi. Robert et Elizabeth Bjork appellent ce type d'effort une « difficulté désirable ». Elle donne une impression de lenteur sur le moment, mais mène à un meilleur apprentissage à long terme (Bjork & Bjork, 2011). L'espacement fait partie de leurs exemples. Une pratique répartie sur plusieurs semaines s'ancre mieux que la même quantité concentrée en une seule séance, et c'est pour cela que la routine ci-dessous est hebdomadaire. Se remémorer quelque chose est aussi plus efficace que le relire (APS Observer sur Roediger & Karpicke, 2006), une étude que Faut-il encore écrire du code à la main ? détaille davantage.

Pour savoir ce que vous avez fait, posez-vous la question une semaine plus tard : pourrais-je réécrire ce code sans le regarder ? Si oui, vous avez délégué un travail que vous comprenez. Si non, revenez-y et apprenez-le avant de construire dessus.

Une routine hebdomadaire pour pratiquer sans IA

La routine ci-dessous prend une à deux heures par semaine. Vous pouvez l'étaler ou tout faire d'un bloc. Le plus dur, c'est de la tenir pendant des mois.

Résoudre un petit problème à la main

Une fois par semaine, ouvrez un fichier vide avec l'assistant désactivé et résolvez un petit problème réel. Choisissez quelque chose de proche de votre travail : un rate limiter, un parser CSV qui gère les champs entre guillemets, un worker pool qui s'arrête à la première erreur. Limitez-vous à 30 à 45 minutes. Vous travaillez le passage d'un fichier vide à du code qui fonctionne, donc le problème peut rester petit.

Si vous voulez des problèmes accompagnés de tests, le Training Ground de LevelUpGo propose des exercices Go indépendants conçus exactement pour cela.

Déboguer avant de demander à l'IA

Quand quelque chose casse, accordez-vous un temps fixe, par exemple 20 minutes, avant de solliciter l'assistant. Formulez une hypothèse, reproduisez le bug, mesurez, et seulement ensuite posez la question.

Voici un bon bug pour s'entraîner. Un service récupère des taux de change auprès d'une API en amont lente et abandonne au bout de 10 millisecondes :

example.gogo
package main

import (
	"context"
	"errors"
	"fmt"
	"os"
	"runtime"
	"runtime/pprof"
	"time"
)

type Rate struct {
	Currency string
	Value    float64
}

func fetchRate(currency string) Rate {
	time.Sleep(50 * time.Millisecond) // a slow upstream API
	return Rate{Currency: currency, Value: 1.08}
}

func rateWithTimeout(ctx context.Context, currency string) (Rate, error) {
	ctx, cancel := context.WithTimeout(ctx, 10*time.Millisecond)
	defer cancel()

	result := make(chan Rate)
	go func() {
		result <- fetchRate(currency)
	}()

	select {
	case r := <-result:
		return r, nil
	case <-ctx.Done():
		return Rate{}, errors.New("rate lookup timed out")
	}
}

func main() {
	timeouts := 0
	for range 100 {
		if _, err := rateWithTimeout(context.Background(), "EUR"); err != nil {
			timeouts++
		}
	}
	fmt.Println("timeouts:", timeouts)
	time.Sleep(100 * time.Millisecond)
	runtime.GC()
	fmt.Println("goroutines:", runtime.NumGoroutine())
	pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
}

En production, le symptôme est une croissance lente de la mémoire, pas un crash. La première mesure à prendre est le nombre de goroutines. Go 1.27 a rendu le profil goroutineleak disponible pour tous (notes de version de Go 1.27), si bien que le runtime peut vous indiquer la fuite lui-même. Exécuté avec Go 1.27, le programme affiche :

example.texttext
timeouts: 100
goroutines: 101
goroutineleak profile: total 100
100 @ 0x1048c59a8 0x10485e854 0x10485e468 0x10491c5ac 0x1048cbc74
#	0x10491c5ab	main.rateWithTimeout.func1+0x5b	./main.go:29

Les 100 requêtes ont toutes expiré, et 100 goroutines sont toujours en vie en plus de main. La ligne 29 est result <- fetchRate(currency). Chaque requête qui expire laisse une goroutine derrière elle, bloquée sur un envoi que personne ne recevra jamais, puisque rateWithTimeout a déjà retourné. La correction consiste à ajouter un buffer d'une place, pour que l'envoi réussisse toujours :

example.gogo
result := make(chan Rate, 1)

Avec cette modification, le même programme affiche goroutines: 1 et goroutineleak profile: total 0. Un assistant trouverait sans doute ce bug rapidement. L'intérêt de l'exercice est de le trouver vous-même, car la prochaine fuite pourrait se trouver dans une bibliothèque que l'assistant n'a jamais vue, pendant un incident où vous êtes seul. Le mot-clé chan en Go : channels, directions et deadlocks explique plus en détail les règles des channels à l'origine de ce bug.

Relire le diff de l'IA comme s'il venait d'un junior

Quand un agent ouvre une pull request, lisez-la comme celle d'un nouveau membre de l'équipe, intelligent mais qui ne connaît pas votre système. Au-delà de savoir si elle a l'air correcte, demandez-vous ce qu'elle suppose. Vérifiez les chemins d'erreur, la gestion du context, les verrous et ce qui se passe au deuxième appel.

La confiance dans ces outils est déjà faible. Dans l'enquête 2025 de Stack Overflow, 84 % des répondants utilisaient ou prévoyaient d'utiliser des outils d'IA, mais seuls 3,1 % avaient une grande confiance dans leur exactitude (Stack Overflow, 2025). L'équipe DORA de Google a constaté que l'IA ne répare pas une équipe. Elle « amplifie ce qui existe déjà » (DORA 2025, 2025). Pour voir ce qui se passe quand la revue de code ne tient plus, La face cachée des outils de codage IA passe en revue les données de 2026.

Lire le code source de la bibliothèque standard

Une fois par semaine, lisez une fonction de la bibliothèque standard de Go. Elle est écrite avec soin, et les commentaires de documentation expliquent souvent les choix de conception. Il n'y a rien à installer :

example.bashbash
go doc -src net/http.Error

example.gogo
// Error replies to the request with the specified error message and HTTP code.
// It does not otherwise end the request; the caller should ensure no further
// writes are done to w.
// The error message should be plain text.
//
// Error deletes the Content-Length header,
// sets Content-Type to “text/plain; charset=utf-8”,
// and sets X-Content-Type-Options to “nosniff”.
// This configures the header properly for the error message,
// in case the caller had set it up expecting a successful output.
func Error(w ResponseWriter, error string, code int) {
	h := w.Header()
	// ...
	h.Del("Content-Length")
	h.Set("Content-Type", "text/plain; charset=utf-8")
	h.Set("X-Content-Type-Options", "nosniff")
	w.WriteHeader(code)
	fmt.Fprintln(w, error)
}

La deuxième ligne du commentaire explique un bug courant : http.Error écrit une réponse mais n'arrête pas votre handler. Si vous oubliez le return après l'appel, le handler continue de s'exécuter. Voici un handler qui commet exactement cette erreur dans la branche de décodage JSON :

example.gogo
type Order struct {
	ID       string `json:"id"`
	Quantity int    `json:"quantity"`
}

func createOrder(w http.ResponseWriter, r *http.Request) {
	var o Order
	if err := json.NewDecoder(r.Body).Decode(&o); err != nil {
		http.Error(w, "invalid JSON", http.StatusBadRequest)
	}
	if o.Quantity <= 0 {
		http.Error(w, "quantity must be positive", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(o)
}

Ce genre de suggestion passe une relecture rapide, parce que la deuxième branche a l'air correcte. Une fois que vous avez lu le code source, le return manquant saute aux yeux. Pour la suite, lisez sync.Once.Do, errors.Is, context.WithCancel et http.MaxBytesReader.

Écrire les tests vous-même

Laissez l'assistant écrire l'implémentation si vous le souhaitez, mais écrivez les cas de test vous-même. Décider de ce qui est correct est la partie du travail que vous ne devriez pas déléguer. Voici un test table-driven pour le handler ci-dessus :

example.gogo
func TestCreateOrder(t *testing.T) {
	tests := []struct {
		name     string
		body     string
		wantCode int
		wantBody string
	}{
		{"valid order", `{"id":"A1","quantity":2}`, http.StatusCreated, `{"id":"A1","quantity":2}` + "\n"},
		{"zero quantity", `{"id":"A1","quantity":0}`, http.StatusBadRequest, "quantity must be positive\n"},
		{"malformed JSON", `{"id":`, http.StatusBadRequest, "invalid JSON\n"},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			req := httptest.NewRequest(http.MethodPost, "/orders", strings.NewReader(tt.body))
			rec := httptest.NewRecorder()

			createOrder(rec, req)

			res := rec.Result()
			body, _ := io.ReadAll(res.Body)
			if res.StatusCode != tt.wantCode {
				t.Errorf("status = %d, want %d", res.StatusCode, tt.wantCode)
			}
			if string(body) != tt.wantBody {
				t.Errorf("body = %q, want %q", body, tt.wantBody)
			}
		})
	}
}

example.texttext
--- FAIL: TestCreateOrder (0.00s)
    --- FAIL: TestCreateOrder/malformed_JSON (0.00s)
        handler_test.go:35: body = "invalid JSON\nquantity must be positive\n", want "invalid JSON\n"
FAIL

La vérification du statut passe, car le premier appel à WriteHeader l'emporte et la réponse reste un 400. Seule la vérification du corps détecte le bug. Un vrai serveur enregistrerait aussi http: superfluous response.WriteHeader call dans les logs, mais seulement si quelqu'un les lit. Pour écrire cette assertion sur le corps, il faut anticiper ce qui pourrait mal tourner, et c'est la compétence que vous travaillez. Une fois le return ajouté, les trois cas passent.

Comment utiliser l'IA pour qu'elle vous apprenne quelque chose au lieu de vous remplacer ?

Utilisez l'IA pour mettre à l'épreuve et expliquer votre raisonnement, et faites d'abord la réflexion vous-même. Cinq habitudes y aident :

• Prévoyez d'abord, puis comparez. Avant de demander une solution, notez votre propre approche en une ou deux phrases, ou esquissez le code. Posez ensuite la question à l'assistant et comparez. Les différences vous montrent ce que vous ne saviez pas.
• Demandez « pourquoi » plutôt que « corrige ». « Pourquoi cette goroutine ne se termine-t-elle jamais ? » vous apporte une explication que vous pouvez vérifier. « Corrige ça » vous apporte un patch que vous accepterez sans rien apprendre.
• Demandez des indices. Dites à l'assistant que vous vous entraînez et que vous voulez un indice à la fois. La plupart des assistants joueront le jeu.
• Faites-vous interroger. Après une session, demandez trois questions sur le code que vous venez de modifier. Si vous ne savez pas y répondre, relisez le code.
• Réécrivez de mémoire. Quand vous acceptez du code généré que vous n'avez pas entièrement compris, fermez-le et réécrivez-le plus tard dans la journée. Là où vous bloquez, c'est ce que vous n'avez pas appris.

La même idée s'applique quand vous partez de zéro. Apprendre à coder en 2026 (sans perdre votre première année) explique comment les débutants peuvent utiliser l'IA comme tuteur.

Quelles compétences comptent davantage aujourd'hui ?

Les compétences qu'il faut pour diriger l'IA et vérifier son travail valent plus aujourd'hui qu'avant.

La relecture est la plus évidente. Les agents peuvent ouvrir des pull requests plus vite qu'une équipe ne peut les lire, et quelqu'un doit encore relire chacune d'elles et décider lesquelles merger.

Rédiger des spécifications en fait aussi partie. Une description claire du problème, des contraintes et des cas limites vous donne un meilleur résultat de la part d'un agent, et l'écrire vous oblige à réfléchir au problème jusqu'au bout.

Les tests comptent davantage quand ce n'est pas vous qui avez écrit le code. C'est avec eux que vous dites à un agent ce que signifie « correct » et que vous le prenez en défaut quand il se trompe. Les tests table-driven, le fuzzing (tutoriel Go sur le fuzzing) et le race detector servent donc plus souvent.

Reste l'architecture. Les agents travaillent bien à l'intérieur de frontières claires, mais décider où placer ces frontières, quel package est responsable de quoi et quelles interfaces restent stables, c'est toujours votre travail.

Le choix du langage aide sur ces quatre points. Le compilateur strict de Go, son langage compact et son outillage intégré attrapent beaucoup d'erreurs du code généré avant la revue, ce que Pourquoi Go est le meilleur langage pour le code écrit par l'IA détaille. Faut-il apprendre Go en 2026 ? couvre le versant carrière de ce choix.

La place de LevelUpGo

LevelUpGo est un endroit où faire la partie sans IA de la routine. Chaque leçon présente le concept à gauche et un vrai éditeur à droite, sans autocomplétion, et vous n'avancez que lorsque votre code Go compile et passe les tests. Le cours Go Basics, gratuit pour commencer, part des fondamentaux. Professional Go Testing vous fait écrire vous-même des tests table-driven, et Concurrency Fundamentals couvre les goroutines, les channels et l'annulation, le code qu'il est le plus utile de savoir déboguer à la main.

Questions fréquentes

Combien de temps coder sans IA chaque semaine ?

Je commencerais par une à deux heures par semaine, en tenant le rythme pendant des mois. La recherche sur l'apprentissage privilégie des séances courtes et espacées plutôt que de longues séances occasionnelles (Bjork & Bjork, 2011). Chaque semaine, un petit problème résolu à la main, un bug débogué avant de demander à l'IA et une fonction de la bibliothèque standard lue suffisent à couvrir les compétences les plus exposées.

Comment pratiquer quand votre équipe attend une productivité au rythme de l'IA ?

Pratiquez en dehors du chemin critique. Pour l'habitude de déboguer d'abord, choisissez des bugs et des tickets qui ne bloquent personne, et faites le problème à la main sur votre temps libre ou sur un budget formation si votre entreprise en a un. Relire les diffs et écrire les tests vous-même s'intègrent au travail normal et ne vous ralentissent presque pas. Si votre équipe ne mesure que la production, parlez à votre lead de la qualité des revues et de la capacité à assurer les astreintes. Les deux reposent sur les mêmes compétences.

Les ingénieurs seniors perdent-ils aussi des compétences à cause de l'IA ?

Oui. L'expérience ne vous protège pas. Les pilotes de l'étude en aviation et les médecins de l'étude sur les coloscopies étaient des professionnels expérimentés, et les deux groupes ont montré des compétences affaiblies là où l'automatisation avait pris en charge une partie du travail (Casner et al., 2014, Budzyń et al., 2025). Les seniors ont plus de compétences à perdre au départ, et ce sont les compétences de réflexion qu'il faut surveiller.

Relire du code écrit par l'IA suffit-il à garder ses compétences ?

Pas à lui seul. Relire fait appel à la reconnaissance, qui est plus facile que produire une solution soi-même. Vous pouvez reconnaître une bonne réponse longtemps après avoir perdu la capacité de l'écrire. Associez la relecture à une pratique régulière de l'écriture et du débogage de code à partir de zéro.

Les compétences perdues à cause de l'IA peuvent-elles revenir ?

La recherche est mince sur ce point, donc personne ne peut le promettre. Les études citées plus haut ont mesuré les compétences à un instant donné, pas leur récupération. Elles montrent en revanche que les compétences que les gens continuaient à utiliser sont restées intactes, comme le pilotage manuel des pilotes (Casner et al., 2014). En pratique, commencez par les auto-évaluations ci-dessus, repérez la compétence la plus faible et travaillez-la en premier.

Sources

• Anthropic, "How AI assistance impacts the formation of coding skills" (2026) : https://www.anthropic.com/research/AI-assistance-coding-skills
• Casner, Geven, Recker & Schooler, "The retention of manual flying skills in the automated cockpit," Human Factors (2014) : https://labs.psych.ucsb.edu/schooler/jonathan/sites/labs.psych.ucsb.edu.schooler.jonathan/files/pubs/the_retention_of_manual_flying_skills_in_the_automated_cockpit.pdf
• Budzyń et al., "Endoscopist deskilling after exposure to artificial intelligence in colonoscopy," Lancet Gastroenterology & Hepatology (2025) : https://doi.org/10.1016/S2468-1253(25)00133-5
• GitClear, "The Maintainability Gap: 2026 AI Code Quality Research" (2026) : https://www.gitclear.com/the_ai_code_quality_maintainability_gap
• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025) : https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Lee et al., "The Impact of Generative AI on Critical Thinking," CHI (2025) : https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/
• APS Observer, "Test-enhanced Learning," sur Roediger & Karpicke (2006) : https://www.psychologicalscience.org/observer/test-enhanced-learning
• Bjork & Bjork, "Making Things Hard on Yourself, But in a Good Way: Creating Desirable Difficulties to Enhance Learning" (2011) : https://bjorklab.psych.ucla.edu/wp-content/uploads/sites/13/2016/04/EBjork_RBjork_2011.pdf
• Stack Overflow Developer Survey 2025, section IA : https://survey.stackoverflow.co/2025/ai
• Google Cloud, "Announcing the 2025 DORA Report" (2025) : https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
• Notes de version de Go 1.27 : https://go.dev/doc/go1.27
• Tutoriel Go sur le fuzzing : https://go.dev/doc/tutorial/fuzz