Codage Vibe vs Codage Spec : même fonctionnalité de remboursement, construite deux fois

DEV - 16/06
J'ai expédié une fonctionnalité de remboursement par vibe coding et j'ai passé deux semaines à la corriger. Ensuite, je l'ai reconstruit d'abord selon les spécifications avec la même IA. Voici la comparaison bug par bug.

Le codage vibratoire est enivrant. Vous décrivez ce que vous voulez dans un langage simple, l'IA écrit le code et dix minutes plus tard, vous disposez d'un point final fonctionnel.

J'ai été vendu - jusqu'à ce que j'expédie une fonctionnalité de remboursement de cette façon et que je passe les deux semaines suivantes à corriger des bugs qu'une spécification de 90 minutes aurait complètement évités.

Il s'agit du côte à côte, utilisant exactement la même exigence, afin que vous puissiez voir où l'écart se creuse.

L'exigence

Une plateforme de commerce électronique a besoin d’une fonction de remboursement de commande. Le brief du Premier ministre :

  • Prise en charge des remboursements complets et partiels
  • Appelez la passerelle de paiement (style Stripe) pour annuler les frais
  • Suivre l'état du remboursement : en attente, en traitement, réussi, échoué
  • Les agents de support déclenchent les remboursements via un outil interne

Assez simple. Les deux chemins commencent ici.

Chemin A : codage d'ambiance

L'invite :

"Créez-moi une API de remboursement de commande dans Node.js. Prend en charge les remboursements complets et partiels. Appelez une passerelle de paiement pour annuler les frais. Suivez l'état du remboursement. Utilisez Express et Postgres."

Soixante secondes plus tard : un cleanContrôleur de remboursementaveccréerRemboursementetgetRefundStatus. Il valide la commande existe, vérifie le montant par rapport au total de la ...
[Courte citation de 8% de l'article original]

Loading...