La façon dont je travaille en tant qu'ingénieur logiciel a changé - et je n'ai pas exactement planifié cela.
Il y a quelques années, ma journée était principalement une question de mise en œuvre. Écrire un passe-partout, coudre les choses ensemble, obsédé par les points les plus fins de la gestion de l'État ou de la validation des entrées. Mais avec la montée en puissance des outils d'IA - non seulement des assistants de code, mais un écosystème croissant d'aides intelligentes - quelque chose a changé. Je me suis retrouvé à écrire moins de lignes de code et à passer plus de temps à concevoir, à prototyper et à explorer des idées à un niveau supérieur.
Aujourd'hui, la majeure partie de ce que je fais est plus proche de l'architecture rapide et de l'expérimentation. Je bouge vite - tourne les MVP, teste la preuve des concepts, itére, jetez les choses, reconstruisez. C'est libérateur. Mais il a introduit un nouveau type d'étranglement auquel je ne m'attendais pas:
Presque tout ce que je construis a besoin de données simulées. Et pas seulement de faux noms et des e-mails aléatoires - je parle de données réalistes, profondément structurées et spécifiques au schéma. Pensez à des choses comme: un profil client avec des champs conditionnels, des réseaux d'adresses imbriqués, des dates qui suivent des modèles logiques, des propriétés facultatives, etc. Chaque prototype, chaque API, chaque test d'interface utilisateur - ils ont tous besoin de quelque chose avec qui travailler.
Au début, je n'y ai pas beaucoup pensé. Je vais juste jeter un objet JSON rapide à la main. Puis un autre. Puis un troisième, légèrement différent. Et avant longtemps, j'étais à nouveau jusqu'aux genoux dans un travail de grognement répétitif - copier, ajuster, vérifier, re-vérifier. Je générais des données de test à la main plus que je n'écrivais des fonctionnalités réelles.
Cela m'a frappé une nuit tout en construisant un prototype: j'avais passé près d'une heure à masser des donn...
[Courte citation de 8% de l'article original]