Développeur côté serveur — tâches, une par une

Les points d'entrée et la plomberie entre eux

Bien spécifié, très représenté dans les données d'entraînement, et vérifiable en l'exécutant — les trois mêmes propriétés qui font d'une tâche un cas fort pour la génération. C'est aussi une grande part de ce à quoi le travail côté serveur ressemble vu de l'extérieur.

Générer un point d'entrée n'est pas la même chose que décider qu'il doit exister, ce qu'il doit garantir, ou ce qui se passe quand il est appelé deux fois. La frappe a rarement été la partie chère de ce travail.

Rester juste quand les choses arrivent en même temps

Ces bogues n'apparaissent pas dans les tests et souvent pas avant des mois. Raisonner dessus exige de tenir un modèle de ce qui tourne par ailleurs et de ce qu'une défaillance partielle laisse derrière, et la bonne réponse dépend des garanties que l'entreprise a données plutôt que du code sous vos yeux.

Un jugement sur la nature du travail, non un jugement mesuré. Les incidents ne sont presque jamais attribués publiquement à du code de concurrence généré, et ce silence ne prouve pas que cela n'arrive pas : un retour d'incident nommant une cause aussi précise est rare dans n'importe quelle entreprise.

Le modèle de données, et le changer en cours d'usage

Les décisions précoces de schéma deviennent coûteuses des années plus tard d'une façon qu'aucun outil ne peut voir depuis le code actuel, parce que le coût vit dans ce qui a déjà été écrit dans les données. Une migration est aussi irréversible en pratique, ce qui la place dans la catégorie où quelqu'un doit répondre plutôt qu'être assisté.

Cela ne dit rien de la fréquence à laquelle les outils rédigent désormais des migrations, ce qu'ils font couramment. L'affirmation porte sur qui décide et qui en répond, non sur qui tape.

Qui a le droit de voir quoi

La génération optimise pour la requête décrite, et un défaut d'autorisation est précisément le cas que personne n'a décrit. C'est aussi le domaine où une réponse assurée, plausible et fausse est la plus dangereuse, parce qu'elle ressemble exactement à une réponse correcte jusqu'à ce que quelqu'un l'exploite.

Cela repose sur la structure du problème et non sur une mesure ; ce qui trancherait, c'est une étude de défauts séparant le code généré du code écrit à la main dans la même base de code. Les environnements réglementés exigent déjà ici la signature d'une personne, et c'est peut-être cela, plus que la difficulté, qui retient le travail.

Ce que cela coûte et à quelle vitesse cela va

Les outils sont réellement forts pour repérer la requête pathologique et suggérer l'index. Ils sont faibles sur le compromis — dépenser de l'argent pour aller plus vite est une décision d'affaires, et savoir quelle requête compte exige de savoir à quoi sert le produit.

Rien ici ne mesure quelle part est désormais pilotée par les outils en pratique, et la réponse diffère énormément entre une équipe dotée d'un budget d'observabilité et une équipe sans.

Être celui que le bipeur réveille

Le diagnostic est de plus en plus assisté et cela aide réellement. La décision non : choisir d'accepter une perte connue pour rétablir le service est un jugement dont quelqu'un doit porter les conséquences, et il se prend avec une information incomplète par construction.

Cela ne dit rien sur le fait que la charge d'astreinte augmente ou diminue, qui est la question qui préoccupe vraiment la plupart des ingénieurs et celle que personne ne publie.