TDD με το Claude Code: η ροή εργασίας που σου δίνει αυτό που πραγματικά ζήτησες

Ζήτα από έναν πράκτορα τεχνητής νοημοσύνης να "χτίσει μια λειτουργία" και σχεδόν πάντα θα σου παραδώσει κάτι. Μεταγλωττίζεται. Τρέχει. Περνάνε δυο τρεις από τους προφανείς ελέγχους. Και θαμμένη μέσα στις αλλαγές υπάρχει μια απόφαση που δεν πήρες ποτέ εσύ, μια υπόθεση που ο πράκτορας συμπλήρωσε αθόρυβα επειδή η οδηγία σου του άφησε λίγο περιθώριο.

Αυτό το κενό, ανάμεσα σε αυτό που ζήτησες και σε αυτό που πραγματικά πήρες, είναι το πράγμα που με απασχολεί περισσότερο αυτόν τον καιρό. Φτιάχνω λογισμικό πολλά χρόνια, από την εποχή που έγραφα ο ίδιος εκατοντάδες μικρές εφαρμογές μέχρι σήμερα, που εργαλεία με πράκτορες όπως το Claude Code και το OpenAI Codex αναλαμβάνουν όλο και μεγαλύτερο μέρος της πληκτρολόγησης. Οπότε η ερώτηση έπαψε να είναι "μπορεί ο πράκτορας να γράψει τον κώδικα;" εδώ και καιρό. Μπορεί. Η ερώτηση τώρα είναι αν ο κώδικας που έγραψε είναι ο κώδικας που εννοούσα.

Αυτό το άρθρο είναι η ροή εργασίας που χρησιμοποιώ με το Claude Code για να κλείσω εκείνο το κενό, με βάση την ανάπτυξη καθοδηγούμενη από δοκιμές (TDD): πρώτα πλάνο, σπάσιμο της δουλειάς σε μικρές ιστορίες, κριτήρια αποδοχής που μετατρέπονται σε δοκιμές, ένας ορισμός ετοιμότητας και ένας ορισμός ολοκλήρωσης για τον πράκτορα, και αποδείξεις επαλήθευσης σε κάθε βήμα. Τη χρησιμοποίησα σε ένα μικρό εργαλείο που έφτιαξα πρόσφατα, και είναι επίσης ο τρόπος που στήνεται η μικρή εφαρμογή εκκρεμοτήτων σε Angular που θα δούμε σε αυτόν τον οδηγό. Τίποτα από όλα αυτά δεν είναι εξωτικό, και όλα μαζί είναι η διαφορά ανάμεσα στο να ελέγχεις τη δουλειά και στο να ελπίζεις για το καλύτερο.

Γιατί γράφει το Claude Code δοκιμές που πάντα περνάνε;

Αφημένος μόνος του, ένας πράκτορας συχνά γράφει πρώτα την υλοποίηση και μετά παράγει δοκιμές που περιγράφουν ό,τι ήδη κάνει ο κώδικας. Οι δοκιμές πρασινίζουν με την πρώτη, η σύνοψη ακούγεται σίγουρη, και στην πραγματικότητα δεν επαληθεύτηκε τίποτα. Η σουίτα δοκιμών είναι ένας καθρέφτης, και ένας καθρέφτης συμφωνεί με ό,τι βλέπει.

Αυτός είναι ένας τρόπος αποτυχίας από τους αρκετούς, και όλοι έχουν την ίδια ρίζα: ο πράκτορας βελτιστοποιεί για το "τελείωσα" αν δεν του ορίσεις εσύ το "σωστό". Αυτοί που συναντώ πιο συχνά:

• Ταυτολογικές δοκιμές. Η δοκιμή επιβεβαιώνει ό,τι τυχαίνει να κάνει η υλοποίηση, οπότε δεν μπορεί ποτέ να αποτύχει. Αντίμετρο: οι δοκιμές βγαίνουν από κριτήρια αποδοχής γραμμένα πριν από τον κώδικα, ποτέ από τον ίδιο τον κώδικα.
• Δοκιμές γραμμένες μετά τον κώδικα. Το ίδιο πρόβλημα με άλλη σειρά. Αντίμετρο: κάνε το "γράψε πρώτα τις δοκιμές, επιβεβαίωσε ότι αποτυγχάνουν" ρητό βήμα για το οποίο ο πράκτορας πρέπει να αναφέρει αποτέλεσμα.
• Χαλαρωμένοι έλεγχοι. Μια δοκιμή κοκκινίζει, και αντί να διορθώσει τον κώδικα ο πράκτορας χαλαρώνει αθόρυβα την προσδοκία μέχρι να περάσει. Αντίμετρο: τα κριτήρια αποδοχής είναι το συμβόλαιο. Μια αλλαγμένη δοκιμή είναι αλλαγμένη απαίτηση και χρειάζεται τη δική σου έγκριση.
• Ξεχείλωμα του εύρους. Ο πράκτορας υλοποιεί την ιστορία και, μια και βρέθηκε εκεί, ξαναστήνει κάτι που δεν του ζήτησες ποτέ. Αντίμετρο: μια λίστα αναμενόμενων αρχείων, που έχει δική της ενότητα πιο κάτω.

Οι αριθμοί του κλάδου λένε ότι αυτή είναι η στιγμή να μας νοιάξει. Η έκθεση DORA του 2025 από την Google διαπίστωσε ότι το 90% των επαγγελματιών του λογισμικού χρησιμοποιεί πλέον τεχνητή νοημοσύνη στη δουλειά, και ότι η τεχνητή νοημοσύνη λειτουργεί ως ενισχυτής: μεγεθύνει τα δυνατά σημεία ενός καλού συστήματος παράδοσης και εξίσου πρόθυμα εκθέτει τα αδύναμα.¹ Η έρευνα της GitLab για τη λογοδοσία στην τεχνητή νοημοσύνη το 2026, σε δείγμα 1.528 προγραμματιστών και αγοραστών τεχνολογίας, βρήκε ότι το 85% συμφώνησε πως το σημείο συμφόρησης μετατοπίστηκε από τη συγγραφή κώδικα στην επισκόπηση και την επικύρωσή του, και το 92% ανέφερε προκλήσεις διακυβέρνησης με κώδικα παραγόμενο από τεχνητή νοημοσύνη.²

Αυτός ο τελευταίος αριθμός ταιριάζει απόλυτα με την εμπειρία μου. Για πολλούς από εμάς το δύσκολο κομμάτι έχει μετακινηθεί στο να ξέρεις αν ο παραγόμενος κώδικας είναι σωστός, ασφαλής, συντηρήσιμος και πραγματικά ευθυγραμμισμένος με αυτό που ζητήθηκε. Πριν από χρόνια έφτιαξα μια διασύνδεση ηλεκτρονικής τιμολόγησης με την ελληνική φορολογική αρχή, και τέτοια δουλειά σε μαθαίνει νωρίς ότι το "φαινόταν μια χαρά" δεν είναι πρόταση που δικαιούσαι να πεις. Το να κρίνεις αυτό που σου επιστρέφει ένας πράκτορας αποδεικνύεται δεξιότητα που μπορείς να ονομάσεις και να εξασκήσεις, και επανήλθα σε αυτήν αργότερα στο AI fluency και το 4D framework, όπου λέγεται διάκριση.

Η TDD βοηθά με κάθε τρόπο αποτυχίας αυτής της λίστας, επειδή δίνει στον πράκτορα κάτι πολύ πιο χρήσιμο από μια γενική οδηγία. Του δίνει ένα συμβόλαιο.

Πώς βάζεις το Claude Code να γράψει πρώτα τις δοκιμές;

Το ζητάς πριν υπάρξει οποιαδήποτε υλοποίηση, με απλά λόγια: "όρισε την αναμενόμενη συμπεριφορά με δοκιμές πριν από την υλοποίηση". Και μετά κρατάς τη σειρά, δοκιμές και έπειτα κώδικας, ιστορία την ιστορία. Η διατύπωση μετράει λιγότερο από την αλληλουχία, και η αλληλουχία ξεκινά από το πλάνο.

Ο πιο συνηθισμένος τρόπος να στραβώσει αυτό είναι να ξεκινήσει η υλοποίηση πολύ νωρίς. Ανοίγεις το Claude Code ή το OpenAI Codex και πληκτρολογείς την προτροπή (prompt):

Φτιάξε μια εφαρμογή εκκρεμοτήτων με Angular.

Ο πράκτορας θα παράξει πρόθυμα κάτι. Στήνει τον σκελετό, τις υπηρεσίες, τα πρότυπα και τις δοκιμές, αρπάζει την τοπική αποθήκευση, προσθέτει δρομολόγηση, διαλέγει ένα σχήμα διαχείρισης κατάστασης, και στην πορεία κάνει μια ντουζίνα αθόρυβες υποθέσεις για εξαρτήσεις, δομή και εμφάνιση. Το αποτέλεσμα μπορεί και να είναι αξιοπρεπές. Το πρόβλημα είναι ότι πάρα πολλές αποφάσεις πάρθηκαν πριν καν πάρει σχήμα η δουλειά.

Μια καλύτερη πρώτη οδηγία μοιάζει κάπως έτσι:

Μόνο σχεδιασμός. Μην επεξεργαστείς αρχεία ακόμα.

Θέλω να φτιάξω μια εφαρμογή εκκρεμοτήτων με Angular.

Πρώτα, σπάσε το παραδοτέο σε μικρές, συνθέσιμες ιστορίες.

Για κάθε ιστορία, όρισε τον στόχο, τα κριτήρια αποδοχής, τον ορισμό ετοιμότητας, τον ορισμό ολοκλήρωσης, τα αναμενόμενα αρχεία προς δημιουργία ή τροποποίηση, τις εξαρτήσεις, τις απαιτούμενες δοκιμές, τα ρίσκα, τις υποθέσεις και τη σειρά υλοποίησης.

Σταμάτα μετά το πλάνο.

Αυτό αλλάζει όλο το σχήμα της δουλειάς. Ο πράκτορας πλέον σχεδιάζει πρώτα, αντί να μαντεύει τον δρόμο του μέσα στον κώδικα, και παίρνεις κάτι που αξίζει να το επισκοπήσεις πριν υπάρξει έστω και μία γραμμή παραγωγικού κώδικα. Εκεί κάθεται η πραγματική αξία, επειδή είναι πολύ φθηνότερο να διορθώσεις ένα πλάνο παρά να ξεμπλέξεις έναν μεγάλο όγκο αλλαγών εκ των υστέρων.

Για τις ίδιες τις δοκιμές, μια συμβουλή διατύπωσης. Η παραδοσιακή γλώσσα της TDD λέει "γράψε μια δοκιμή που αποτυγχάνει", κάτι που ακούγεται περίεργο σε όποιον δεν έχει βουτηχτεί στην πρακτική, γιατί μοιάζει με αίτημα να γράψεις επίτηδες κάτι χαλασμένο. Πιο καθαρό:

Γράψε πρώτα τις δοκιμές. Τρέξε τες και επιβεβαίωσε ότι αποτυγχάνουν επειδή η συμπεριφορά δεν έχει υλοποιηθεί ακόμα.

Η αποτυχία είναι το ζητούμενο. Αποδεικνύει ότι η δοκιμή ελέγχει κάτι πραγματικό, δηλαδή ακριβώς την απόδειξη που μια ταυτολογική δοκιμή δεν μπορεί ποτέ να σου δώσει. Από εκεί και πέρα ο βρόχος χωράει εύκολα στο μυαλό:

1. Γράψε πρώτα τις δοκιμές.
2. Επιβεβαίωσε ότι αποτυγχάνουν για τον αναμενόμενο λόγο.
3. Υλοποίησε τη μικρότερη δυνατή αλλαγή.
4. Ξανατρέξε τις δοκιμές.
5. Κάνε αναδιάρθρωση μόνο όταν οι δοκιμές είναι πράσινες.
6. Ανάφερε τις αποδείξεις.

Η πρώτη ιστορία είναι ο σκελετός

Πριν ο πράκτορας χτίσει οποιαδήποτε συμπεριφορά της εφαρμογής, η πρώτη ιστορία πρέπει να είναι ο σκελετός. Αν το έργο σε Angular δεν υπάρχει ακόμα, ο πράκτορας πρέπει πρώτα να δημιουργήσει τη δομή της εφαρμογής, να επιβεβαιώσει το στήσιμο των δοκιμών, να καθιερώσει τις συμβάσεις των φακέλων και να αποδείξει ότι η εφαρμογή χτίζεται και δοκιμάζεται με επιτυχία. Αυτή είναι η Ιστορία 0, και η δουλειά της είναι να δημιουργήσει το θεμέλιο πάνω στο οποίο θα ακουμπήσει κάθε επόμενη ιστορία.

Ιστορία 0: Δημιουργία του σκελετού της εφαρμογής Angular. Τα κριτήρια αποδοχής θα μπορούσαν να είναι:

• Δεδομένου ότι το αποθετήριο δεν περιέχει εφαρμογή Angular, όταν τρέξει η εργασία του σκελετού, τότε δημιουργείται μια νέα εφαρμογή Angular.
• Δεδομένου ότι η εφαρμογή δημιουργήθηκε, τότε το έργο μπορεί να εγκατασταθεί, να χτιστεί και να δοκιμαστεί με επιτυχία.
• Δεδομένου ότι το έργο χρησιμοποιεί σύγχρονη έκδοση Angular, τότε χρησιμοποιούνται αυτόνομα στοιχεία (standalone components), εκτός αν η υπάρχουσα σύμβαση λέει αλλιώς.
• Δεδομένου ότι ο σκελετός ολοκληρώθηκε, τότε υπάρχει ή έχει σχεδιαστεί καθαρά ένας ειδικός φάκελος για τη λειτουργία των εκκρεμοτήτων, και δεν έχει υλοποιηθεί ακόμα καμία επιχειρησιακή λογική.

Κράτα αυτή την ιστορία σκόπιμα απλή. Αυτή η απλότητα είναι έλεγχος εύρους. Χωρίς την Ιστορία 0, ο πράκτορας τείνει να χτίσει το θεμέλιο και την πρώτη λειτουργία με την ίδια ανάσα, που σημαίνει μεγαλύτερο όγκο αλλαγών, περισσότερες υποθέσεις ψημένες μέσα, και δυσκολότερη επισκόπηση στο τέλος. Με την Ιστορία 0, το θεμέλιο επαληθεύεται πρώτο, και μόνο τότε ο πράκτορας προχωρά στη συμπεριφορά.

Σπάσε την εφαρμογή σε μικρές ιστορίες

Μόλις στηθεί ο σκελετός, σπάσε την ίδια την εφαρμογή σε μικρές ιστορίες. Μια χρήσιμη σειρά για την εφαρμογή εκκρεμοτήτων:

• Ιστορία 0: Δημιουργία του σκελετού της εφαρμογής Angular.
• Ιστορία 1: Δημιουργία του μοντέλου δεδομένων και της υπηρεσίας κατάστασης.
• Ιστορία 2: Φόρμα δημιουργίας εκκρεμότητας.
• Ιστορία 3: Εμφάνιση της λίστας εκκρεμοτήτων.
• Ιστορία 4: Εναλλαγή μιας εκκρεμότητας ανάμεσα σε ενεργή και ολοκληρωμένη.
• Ιστορία 5: Διαγραφή εκκρεμότητας.
• Ιστορία 6: Φιλτράρισμα σε όλες, ενεργές και ολοκληρωμένες.
• Ιστορία 7: Αποθήκευση των εκκρεμοτήτων στην τοπική αποθήκευση.
• Ιστορία 8: Καταστάσεις διεπαφής για κενά, επικύρωση και ασφαλή χειρισμό σφαλμάτων.

Πέρασα χρόνια τρέχοντας κουζίνες εστιατορίων πριν γράψω την πρώτη μου γραμμή λογισμικού, και αυτό που κρατά ζωντανή μια κουζίνα σε ένα γεμάτο βράδυ είναι ότι κανείς δεν προσπαθεί να μαγειρέψει όλη την παραγγελία μονομιάς. Τα δελτία μπαίνουν στη σειρά, και τα δουλεύεις πιάτο πιάτο, με μια σειρά που βγάζει νόημα, ώστε το πάσο να μη γίνει ποτέ χάος. Το σπάσιμο της δουλειάς για έναν πράκτορα είναι το ίδιο ένστικτο. Ο σκελετός δίνει στην εφαρμογή θεμέλιο, το μοντέλο δεδομένων της δίνει σχήμα, η υπηρεσία κατάστασης της δίνει ελεγχόμενη συμπεριφορά, οι ιστορίες της διεπαφής καταναλώνουν αυτή τη συμπεριφορά, και η αποθήκευση έρχεται τελευταία επειδή είναι γνήσια ξεχωριστή ευθύνη.

Αυτή η αποσύνθεση είναι που κάνει τους πράκτορες αξιόπιστους. Ο πράκτορας δεν χρειάζεται ποτέ να λύσει όλη την εφαρμογή μονομιάς. Λύνει μία μικρή, δοκιμάσιμη συμπεριφορά τη φορά, κάτι που κόβει δραματικά την ασάφεια. Κόβει επίσης τον κόπο της επισκόπησης, γιατί το να κοιτάς μία εστιασμένη αλλαγή είναι πολύ ευκολότερο από το να επισκοπείς έναν μεγάλο όγκο παραγόμενου κώδικα που ανακατεύει στήσιμο, κατάσταση, διεπαφή, επικύρωση, αποθήκευση και εμφάνιση σε ένα πέρασμα.

Κριτήρια αποδοχής ως δοκιμές: το συμβόλαιο που ο πράκτορας δεν μπορεί να παρερμηνεύσει

Τα κριτήρια αποδοχής σε μορφή Δεδομένου/Όταν/Τότε είναι το πιο χρήσιμο πράγμα που μπορείς να δώσεις σε έναν πράκτορα που γράφει κώδικα, επειδή κάθε κριτήριο μετατρέπεται απευθείας σε μια δοκιμή που ο πράκτορας οφείλει να ικανοποιήσει. Πάρε την Ιστορία 2, τη φόρμα δημιουργίας εκκρεμότητας. Μια αδύναμη απαίτηση θα ήταν:

Ο χρήστης μπορεί να προσθέτει εκκρεμότητες.

Η πρόταση μοιάζει απλή, και αυτή είναι η παγίδα, γιατί αφήνει σχεδόν τα πάντα ανοιχτά:

• Τι γίνεται όταν το πεδίο είναι κενό;
• Πρέπει να κόβονται τα κενά;
• Πρέπει το πεδίο να καθαρίζει μετά την υποβολή;
• Μια νέα εκκρεμότητα είναι ενεργή ή ολοκληρωμένη από προεπιλογή;
• Επιτρέπονται διπλότυπα;
• Πρέπει το πλήκτρο Enter να υποβάλλει τη φόρμα;

Ο πράκτορας μπορεί να κάνει λογικές υποθέσεις για όλα αυτά, αλλά οι υποθέσεις δεν είναι απαιτήσεις. Καλύτερα κριτήρια αποδοχής θα ήταν:

• Δεδομένου ότι το πεδίο είναι κενό, όταν ο χρήστης υποβάλει τη φόρμα, τότε δεν δημιουργείται εκκρεμότητα.
• Δεδομένου ότι το πεδίο περιέχει μόνο κενά, όταν ο χρήστης υποβάλει τη φόρμα, τότε δεν δημιουργείται εκκρεμότητα.
• Δεδομένου ότι το πεδίο περιέχει κείμενο, όταν ο χρήστης υποβάλει τη φόρμα, τότε μια νέα εκκρεμότητα προστίθεται στη λίστα.
• Δεδομένου ότι το κείμενο έχει κενά στην αρχή ή στο τέλος, όταν δημιουργείται η εκκρεμότητα, τότε το αποθηκευμένο κείμενο είναι καθαρισμένο.
• Δεδομένου ότι η εκκρεμότητα προστέθηκε με επιτυχία, τότε το πεδίο εισαγωγής καθαρίζει.
• Δεδομένου ότι μια εκκρεμότητα μόλις δημιουργήθηκε, τότε είναι ενεργή από προεπιλογή.

Τώρα η συμπεριφορά είναι συγκεκριμένη, και ο πράκτορας μπορεί να μετατρέψει αυτά τα κριτήρια σε δοκιμές πριν γράψει έστω και μία γραμμή της υλοποίησης. Αυτός, περισσότερο από οτιδήποτε άλλο, είναι ο πυρήνας της TDD με πράκτορα: του ζητάς να αποδείξει μια συμπεριφορά. Πριν υλοποιήσει την addTodo, ο πράκτορας θα μπορούσε να γράψει μια δοκιμή σαν αυτή:

it('does not add a todo when the text is empty', () => {
  const initialCount = store.todos().length

  store.addTodo('')

  expect(store.todos().length).toBe(initialCount)
})

Στην αρχή αποτυγχάνει, είτε επειδή η addTodo δεν υπάρχει ακόμα είτε επειδή η τρέχουσα υλοποίηση προσθέτει πρόθυμα κενές εκκρεμότητες. Μετά ο πράκτορας γράφει τον ελάχιστο κώδικα που την κάνει να περάσει:

addTodo(text: string): void {
  const trimmed = text.trim()

  if (!trimmed) {
    return
  }

  this.todos.update((todos) => [
    ...todos,
    {
      id: crypto.randomUUID(),
      text: trimmed,
      completed: false,
    },
  ])
}

Κάθε συμπεριφορά γίνεται δοκιμάσιμη, κάθε δοκιμή γίνεται ανατροφοδότηση, και κάθε βήμα υλοποίησης βγαίνει μικρότερο από το προηγούμενο. Ο πράκτορας δεν χρειάζεται ποτέ να μαντέψει τι σημαίνει "σωστό", γιατί οι δοκιμές το ορίζουν ήδη.

Ένας ορισμός ετοιμότητας και ένας ορισμός ολοκλήρωσης για πράκτορες που γράφουν κώδικα

Ο ορισμός ετοιμότητας (Definition of Ready) λέει στον πράκτορα πότε επιτρέπεται να ξεκινήσει, και ο ορισμός ολοκλήρωσης (Definition of Done) πότε επιτρέπεται να σταματήσει. Στις ανθρώπινες ομάδες συχνά αντιμετωπίζονται σαν τυπικότητα. Με έναν πράκτορα γίνονται οι δύο πιο πρακτικές πύλες που έχεις, γιατί αλλιώς ο πράκτορας θα ξεκινήσει με ελλιπές πλαίσιο και θα σταματήσει στο "βγήκε κάποιος κώδικας".

Η ετοιμότητα, για την ιστορία της φόρμας, είναι μια λίστα ελέγχου που αξίζει να γραφτεί ολόκληρη:

• Υπάρχουν ο σκελετός, το μοντέλο δεδομένων και η υπηρεσία κατάστασης.
• Η συμπεριφορά της προσθήκης και οι κανόνες επικύρωσής της είναι ορισμένοι.
• Η θέση της φόρμας είναι γνωστή.
• Η προσέγγιση των δοκιμών έχει συμφωνηθεί.
• Η αποθήκευση είναι ρητά εκτός εύρους για αυτή την ιστορία.

Η τελευταία γραμμή μετράει περισσότερο απ' όσο δείχνει. Άφησέ την έξω, και ο πράκτορας μπορεί να αποφασίσει να συνδέσει την τοπική αποθήκευση όσο φτιάχνει τη φόρμα. Ακούγεται εξυπηρετικό, αλλά μπερδεύει αθόρυβα τις ευθύνες, και οι μπερδεμένες ευθύνες σημαίνουν μεγαλύτερες αλλαγές, δυσκολότερες στην επισκόπηση και στη δοκιμή.

Η ολοκλήρωση είναι αυστηρότερη, και είναι κι αυτή λίστα ελέγχου:

• Η φόρμα υλοποιήθηκε, και οι κενές ή μόνο-με-κενά υποβολές δεν δημιουργούν τίποτα.
• Οι έγκυρες υποβολές δημιουργούν ενεργές εκκρεμότητες, και το κείμενο καθαρίζεται πριν αποθηκευτεί.
• Το πεδίο καθαρίζει μετά από επιτυχημένη υποβολή.
• Οι μοναδιαίες δοκιμές καλύπτουν τη λογική, οι δοκιμές στοιχείων την αλληλεπίδραση.
• Οι υπάρχουσες δοκιμές συνεχίζουν να περνούν.
• Δεν άλλαξαν άσχετα αρχεία και δεν προστέθηκαν νέες εξαρτήσεις.
• Ο πράκτορας αναφέρει τα αρχεία που άλλαξαν και τα αποτελέσματα των δοκιμών.

Το τελευταίο σημείο είναι αυτό που αρνούμαι να παραλείψω. Ολοκλήρωση σημαίνει ότι οι αποδείξεις είναι συνημμένες: οι εντολές που έτρεξαν, οι δοκιμές που πέρασαν, τα αρχεία που άλλαξαν, και όποια ρίσκα ή υποθέσεις μένουν ανοιχτά. Μια σίγουρη παράγραφος χωρίς αυτές τις αποδείξεις είναι μια σύνοψη προθέσεων, και τις προθέσεις ακριβώς ήρθε να αντικαταστήσει η TDD. Οι δοκιμές είναι το ένα στρώμα αυτών των αποδείξεων. Ο μεταγλωττιστής, ο στατικός έλεγχος κώδικα και οι έλεγχοι τύπων είναι η σκάλα από κάτω τους, και αυτή την πλευρά των εργαλείων την πέρασα στο Μετράνε ακόμα τα πλαίσια διεπαφής όταν τον κώδικα τον γράφει η τεχνητή νοημοσύνη;.

Αναμενόμενα αρχεία: κρατώντας τον πράκτορα μέσα στο εύρος

Πριν ο πράκτορας υλοποιήσει οτιδήποτε, ζήτα του να ονομάσει τα αρχεία που σκοπεύει να δημιουργήσει ή να αγγίξει, και, εξίσου χρήσιμα, εκείνα που πρέπει να αφήσει ήσυχα. Για την εφαρμογή εκκρεμοτήτων:

• src/app/todos/todo.model.ts
• src/app/todos/todo-store.service.ts (και το .spec.ts του)
• src/app/todos/add-todo-form.component.ts (με το πρότυπο και το .spec.ts)
• src/app/todos/todo-list.component.ts (με το πρότυπο και το .spec.ts)
• src/app/todos/todo-storage.service.ts (και το .spec.ts του)

Και εκτός ορίων: src/app/payment/*, src/app/auth/*, src/environments/*, και το package.json εκτός αν μια εξάρτηση εγκριθεί ρητά.

Τώρα υπάρχει ένα όριο εύρους. Αν ο πράκτορας υλοποιεί τη "διαγραφή εκκρεμότητας" και ξαφνικά απλώνει το χέρι στη δρομολόγηση όλης της εφαρμογής, στην αυθεντικοποίηση ή στις εξαρτήσεις, η αλλαγή μπορεί να αμφισβητηθεί αμέσως. Το εύρος των αρχείων είναι μορφή αρχιτεκτονικού ελέγχου, και η ανάπτυξη με πράκτορες το χρειάζεται ακριβώς επειδή οι πράκτορες κινούνται στα αρχεία τόσο γρήγορα.

Η ίδια πειθαρχία ισχύει για τις εξαρτήσεις. Ο πράκτορας πρέπει να τις ονομάσει πριν γράψει κώδικα, και για μια εφαρμογή εκκρεμοτήτων η ειλικρινής απάντηση είναι σύντομη: αυτόνομα στοιχεία Angular, φόρμες Angular, μια αποκλειστική υπηρεσία κατάστασης, και τοπική αποθήκευση του προγράμματος περιήγησης μόνο στην ιστορία της αποθήκευσης. Χωρίς διακομιστή, χωρίς NgRx, χωρίς βάση δεδομένων, χωρίς βιβλιοθήκη έτοιμων στοιχείων, χωρίς καμία νέα εξάρτηση χρόνου εκτέλεσης. Οι πράκτορες αρπάζουν εργαλεία πριν αποδείξουν ότι τα χρειάζονται, οπότε το ρητό πλάνο εξαρτήσεων κρατά την υλοποίηση τίμια και απλή.

Επαναχρησιμοποιήσιμες προτροπές TDD για το Claude Code (αντιγραφή-επικόλληση)

Αυτές είναι οι τρεις προτροπές που πιάνω στην πράξη, με τη σειρά που τις χρησιμοποιώ. Πρώτα το πλάνο:

Μόνο σχεδιασμός. Μην επεξεργαστείς αρχεία.

Εξέτασε αυτό το έργο Angular και φτιάξε ένα πλάνο παράδοσης για μια εφαρμογή εκκρεμοτήτων.

Σπάσε το παραδοτέο σε μικρές, συνθέσιμες ιστορίες. Η πρώτη ιστορία πρέπει να είναι η Ιστορία 0: Δημιουργία ή επαλήθευση του σκελετού της εφαρμογής Angular.

Για κάθε ιστορία, δώσε: στόχο, κριτήρια αποδοχής, ορισμό ετοιμότητας, ορισμό ολοκλήρωσης, αναμενόμενα αρχεία προς δημιουργία ή τροποποίηση, αρχεία που δεν πρέπει να αγγιχτούν, εξαρτήσεις, απαιτούμενες δοκιμές, ρίσκα και υποθέσεις, και προτεινόμενη σειρά υλοποίησης.

Η εφαρμογή πρέπει να υποστηρίζει προσθήκη εκκρεμοτήτων, εμφάνισή τους, εναλλαγή ολοκλήρωσης, διαγραφή, φιλτράρισμα σε όλες, ενεργές και ολοκληρωμένες, και αποθήκευση στην τοπική αποθήκευση.

Μην παράξεις παραγωγικό κώδικα ακόμα. Σταμάτα μετά το πλάνο.

Μετά, αφού επισκοπηθεί το πλάνο, ο σκελετός μόνος του:

Υλοποίησε μόνο την Ιστορία 0. Δημιούργησε ή επαλήθευσε τον σκελετό Angular. Επιβεβαίωσε ότι η εφαρμογή χτίζεται και δοκιμάζεται με επιτυχία. Δημιούργησε ή εντόπισε τον φάκελο της λειτουργίας εκκρεμοτήτων, αλλά μην υλοποιήσεις ακόμα επιχειρησιακή λογική. Μην προσθέσεις περιττές εξαρτήσεις. Ανάφερε τα αρχεία που άλλαξαν, τις εντολές που έτρεξαν και τα αποτελέσματα επαλήθευσης.

Και έπειτα κάθε ιστορία λειτουργίας στο ίδιο σχήμα:

Υλοποίησε την Ιστορία 1 με TDD. Πρώτα γράψε δοκιμές με βάση τα εγκεκριμένα κριτήρια αποδοχής. Τρέξε τες και επιβεβαίωσε ότι αποτυγχάνουν επειδή η συμπεριφορά δεν έχει υλοποιηθεί ακόμα. Μετά υλοποίησε τον ελάχιστο κώδικα που χρειάζεται για να περάσουν. Μην υλοποιήσεις διεπαφή, αποθήκευση, φιλτράρισμα ή διαγραφή σε αυτή την ιστορία. Τρέξε τη σχετική σουίτα δοκιμών, τον στατικό έλεγχο κώδικα και τους ελέγχους τύπων. Δώσε τα αρχεία που άλλαξαν και αποδείξεις επαλήθευσης.

Ο ρυθμός δεν αλλάζει ποτέ. Μία ιστορία, μία συμπεριφορά, ένα σύνολο δοκιμών, μία υλοποίηση, μία αναφορά επαλήθευσης. Και μετά το επαναλαμβάνεις.

Συχνές ερωτήσεις

Δουλεύει αυτή η ροή εργασίας με το OpenAI Codex;

Ναι, απαράλλαχτη. Το Codex είναι χτισμένο ως πράκτορας μηχανικής λογισμικού που δουλεύει σε απομονωμένα περιβάλλοντα, επεξεργάζεται κώδικα, τρέχει ελέγχους, επικυρώνει τη δουλειά του και δείχνει τις διαφορές των αρχείων που άλλαξαν,³ και το Claude Code ως εργαλείο με πράκτορα που κατανοεί ένα αποθετήριο, επεξεργάζεται αρχεία, τρέχει εντολές και δουλεύει εργασίες από οδηγίες σε φυσική γλώσσα.⁴ Η ροή εργασίας ζει στις προτροπές και στις πύλες, όχι σε κάποιο συγκεκριμένο εργαλείο, οπότε όλα τα παραπάνω ισχύουν και για τα δύο, και για όποιον πράκτορα έρθει μετά.

Αξίζει ακόμα η TDD όταν τις δοκιμές τις γράφει η τεχνητή νοημοσύνη;

Περισσότερο από πριν, και ο λόγος είναι για ποιον είναι οι δοκιμές. Όταν έγραφα μόνος μου όλο τον κώδικα, οι δοκιμές με προστάτευαν από τον μελλοντικό εαυτό μου. Με έναν πράκτορα, οι δοκιμές που βγαίνουν από τα δικά σου κριτήρια αποδοχής είναι το μόνο κομμάτι του βρόχου που μεταφέρει την πρόθεσή σου μέσα στον κώδικα χωρίς να περάσει από τις υποθέσεις του πράκτορα. Κάνουν επίσης την επισκόπηση διαχειρίσιμη: αντί να ζουλάς τα μάτια σου πάνω σε έναν όγκο αλλαγών ελπίζοντας, ελέγχεις ότι οι δοκιμές δηλώνουν τη σωστή συμπεριφορά και ότι οι αποδείξεις τις δείχνουν να περνούν.

Και το vibe coding;

Το λεγόμενο vibe coding, το να προχωράς με προτροπές και να δέχεσαι ό,τι επιστρέφει, είναι ειλικρινά υπέροχο για πρόχειρη εξερεύνηση, για πρωτότυπα, και για να ανακαλύψεις τι θέλεις στ' αλήθεια. Τη στιγμή που ο κώδικας πρέπει να επιβιώσει από πραγματικούς χρήστες, συναδέλφους και μελλοντικές αλλαγές, χρειάζεται συμβόλαιο, και αυτή είναι όλη η διαφορά. Σε αυτή τη ροή εργασίας γυρίζω όταν ένα κομμάτι λογισμικού παύει να είναι πείραμα.

Το συμπέρασμα που μένει

Η αξία όλων αυτών είναι η αλυσίδα ελέγχου που τα διατρέχει. Η απαίτηση γίνεται ιστορίες, και οι ιστορίες γίνονται κριτήρια αποδοχής. Τα κριτήρια αποδοχής γίνονται δοκιμές, και οι δοκιμές οδηγούν την υλοποίηση. Η ετοιμότητα ελέγχει πότε μπορεί να ξεκινήσει ο πράκτορας, και η ολοκλήρωση πότε μπορεί να σταματήσει. Τα αναμενόμενα αρχεία ελέγχουν το εύρος, το πλάνο εξαρτήσεων ελέγχει την πολυπλοκότητα που σέρνεται, και οι αποδείξεις επαλήθευσης ελέγχουν την ψεύτικη σιγουριά.

Τίποτα από αυτά δεν εγγυάται τελειότητα, γιατί καμία ροή εργασίας δεν το κάνει. Αυτό που κάνει είναι να μειώνει την ασάφεια, να κάνει τη δουλειά εύκολη στην επιθεώρηση, και να δίνει και στον πράκτορα και σε εμένα έναν κοινό, συγκεκριμένο ορισμό της ορθότητας. Μια ταπεινή εφαρμογή εκκρεμοτήτων δείχνει όλο το σχήμα, και είναι το ίδιο ένστικτο που κρατά μια κουζίνα ήρεμη σε ένα γεμάτο βράδυ: δούλεψε ένα δελτίο τη φορά, και έλεγξε κάθε πιάτο πριν φύγει από το πάσο.

Αυτός είναι ο ρόλος της TDD στην ανάπτυξη με πράκτορες: ένας τρόπος να μετατρέψεις την ασαφή πρόθεση σε ελεγχόμενη παράδοση, και να πεις τι σημαίνει "σωστό" πριν υπάρξει ο κώδικας. Οι πράκτορες παράγουν ήδη κώδικα πιο γρήγορα από όσο μπορεί ο καθένας μας άνετα να τον επισκοπήσει, και αυτή η διαφορά είναι όλο το παιχνίδι.