Ζήτα από έναν agent να "χτίσει ένα feature" και σχεδόν πάντα θα σου παραδώσει κάτι. Κάνει compile. Τρέχει. Περνάνε δυο τρεις από τους προφανείς ελέγχους. Και θαμμένη μέσα στο diff υπάρχει μια απόφαση που δεν πήρες ποτέ εσύ, μια υπόθεση που ο agent συμπλήρωσε αθόρυβα επειδή η οδηγία σου του άφησε λίγο περιθώριο.
Αυτό το κενό, ανάμεσα σε αυτό που ζήτησες και σε αυτό που πραγματικά πήρες, είναι το πράγμα που με απασχολεί περισσότερο αυτόν τον καιρό. Ηγούμαι engineering ομάδων που είναι μοιρασμένες σε Ελλάδα, Ινδία και Μεξικό, και agentic εργαλεία όπως το Claude Code και το OpenAI Codex πέρασαν από περιέργεια σε κομμάτι του πώς δουλεύουμε. Οπότε η ερώτηση έπαψε να είναι "μπορεί ο agent να γράψει τον κώδικα;" εδώ και καιρό. Μπορεί. Η ερώτηση τώρα είναι αν ο κώδικας που έγραψε είναι ο κώδικας που εννοούσα.
Και η αλλαγή δεν αφορούσε ποτέ πραγματικά την παραγωγή κώδικα. Η μεγαλύτερη αλλαγή είναι ότι αυτά τα εργαλεία πλέον δουλεύουν σε ολόκληρο ένα project. Επιθεωρούν αρχεία, χτίζουν μια κατανόηση ενός codebase, κάνουν edit σε πολλά σημεία ταυτόχρονα, τρέχουν εντολές, εκτελούν tests, επαναλαμβάνουν πάνω στα failures και σου γυρίζουν μια σύνοψη του τι άλλαξε. Έπαψαν να είναι ένα autocomplete για την επόμενη γραμμή και έγιναν ενεργοί συμμετέχοντες στο delivery.
Αυτό είναι πραγματικά ισχυρό, και είναι ακριβώς ο λόγος που η engineering πειθαρχία μετράει περισσότερο τώρα, όχι λιγότερο.
Εδώ είναι που το Test-Driven Development ξαναγίνεται σχετικό, και δεν εννοώ ως ένα παλιό τελετουργικό ή ένα κομμάτι φορμαλισμού βιδωμένο πάνω στο delivery. Στην εποχή του agentic AI, το TDD μετατρέπεται σε κάτι πιο χρήσιμο. Γίνεται σύστημα ελέγχου. Μετατρέπει την πρόθεση σε εκτελέσιμη συμπεριφορά και τα acceptance criteria σε tests. Δίνει στον agent έναν ξεκάθαρο στόχο, και δίνει σε εμένα, τον reviewer, έναν πρακτικό τρόπο να ελέγξω το αποτέλεσμα. Ο στόχος δεν ήταν ποτέ μόνο να πάμε πιο γρήγορα. Ο στόχος είναι να φτάσουμε πιο κοντά σε αυτό που πραγματικά ζήτησες.
Το AI κάνει την ταχύτητα πιο εύκολη, όχι το delivery πιο ασφαλές
Το DORA report του 2025 από την Google διαπίστωσε ότι η υιοθέτηση του AI ανάμεσα στους επαγγελματίες του λογισμικού είναι ήδη διαδεδομένη, με το 90% των συμμετεχόντων να λέει ότι χρησιμοποιεί AI στη δουλειά και πάνω από το 80% να λέει ότι αύξησε την παραγωγικότητά τους.1 Αυτό ταιριάζει με ό,τι βλέπω. Για πολλές ομάδες, το AI πέρασε από ένα παράλληλο πείραμα σε κομμάτι της καθημερινής δουλειάς ανάπτυξης.
Η ίδια έρευνα δείχνει το κομμάτι που μετράει περισσότερο για όποιον ηγείται delivery: το AI λειτουργεί ως ενισχυτής. Μεγεθύνει τα δυνατά σημεία ενός καλού συστήματος delivery, και το ίδιο πρόθυμα εκθέτει τα αδύναμα σημεία στο πώς σχεδιάζεται, γίνεται review, δοκιμάζεται και λειτουργεί η δουλειά.
Η έρευνα AI Accountability του 2026 από τη GitLab καταλήγει στην ίδια ένταση. Βασισμένη σε μια έρευνα με 1.528 developers και technology buyers, η GitLab ανέφερε ότι το 80% είπε πως ο οργανισμός τους υιοθέτησε εργαλεία AI ταχύτερα από όσο ανέπτυξε πολιτικές για να τα διέπει. Η ίδια έρευνα διαπίστωσε ότι το 92% ανέφερε προκλήσεις governance με κώδικα παραγόμενο από AI, και το 85% συμφώνησε ότι το AI μετατόπισε το bottleneck από τη συγγραφή κώδικα στο review και το validation.2
Αυτός ο τελευταίος αριθμός είναι η μέρα μου σε μία πρόταση. Για πολλές ομάδες το bottleneck δεν είναι πια η συγγραφή του κώδικα. Είναι το να ξέρεις αν ο παραγόμενος κώδικας είναι σωστός, ασφαλής, συντηρήσιμος και πραγματικά ευθυγραμμισμένος με αυτό που ζητήθηκε, ειδικά όταν λειτουργείς σε ένα ρυθμιζόμενο περιβάλλον όπου το "φαινόταν μια χαρά" δεν είναι υπεράσπιση που θα δεχτεί κανείς.
Το TDD βοηθάει εδώ επειδή δίνει στον agent κάτι πολύ πιο χρήσιμο από μια γενική οδηγία. Του δίνει ένα contract.
Ξεκίνα με planning, όχι με implementation
Ο πιο συνηθισμένος τρόπος να πάει αυτό στραβά είναι να ξεκινήσεις το implementation πολύ νωρίς.
Ανοίγεις το Claude Code ή το OpenAI Codex και πληκτρολογείς:
Create a todo app with Angular.
Ο agent με χαρά θα παράξει κάτι. Στήνει components, services, templates και tests, πιάνει το local storage, προσθέτει routing, διαλέγει ένα state pattern και κάνει μια ντουζίνα σιωπηλές υποθέσεις για dependencies, δομή και styling στην πορεία. Το αποτέλεσμα μπορεί και να είναι αξιοπρεπές. Το πρόβλημα είναι ότι πάρα πολλές αποφάσεις πάρθηκαν πριν καν πάρει σχήμα η δουλειά.
Μια καλύτερη πρώτη οδηγία μοιάζει κάπως έτσι:
Planning mode only. Do not edit files yet.
I want to create a todo app with Angular.
First, break the deliverable into small composable stories.
For each story, define the goal, acceptance criteria, Definition of Ready, Definition of Done, expected files to create or modify, dependencies, required tests, risks, assumptions, and implementation order.
Stop after the plan.
Αυτό αλλάζει όλο το σχήμα του workflow. Ο agent δεν καλείται πια να μαντέψει και να παράξει. Καλείται να σχεδιάσει, και παίρνεις κάτι που αξίζει να το κάνεις review πριν υπάρξει έστω και μία γραμμή production κώδικα. Αυτό το review είναι εκεί που κάθεται η πραγματική αξία, επειδή είναι πολύ φθηνότερο να διορθώσεις ένα plan παρά να ξεμπλέξεις ένα μεγάλο diff εκ των υστέρων. Εδώ είναι το σημείο όπου η agentic ανάπτυξη αρχίζει να μοιάζει ελεγχόμενη αντί για χαοτική.
Η πρώτη story πρέπει να είναι το scaffold
Πριν ο agent χτίσει οποιαδήποτε συμπεριφορά todo, η πρώτη story πρέπει να είναι το scaffold.
Αν το Angular project δεν υπάρχει ακόμα, ο agent δεν πρέπει να ξεκινήσει με τη λογική του todo. Πρέπει πρώτα να δημιουργήσει τη δομή της εφαρμογής, να επιβεβαιώσει το testing setup, να καθιερώσει τις συμβάσεις φακέλων και να αποδείξει ότι η εφαρμογή μπορεί να κάνει build και test με επιτυχία. Αυτή είναι η Story 0, και η δουλειά της δεν είναι να χτίσει λειτουργικότητα todo. Η δουλειά της είναι να δημιουργήσει το θεμέλιο πάνω στο οποίο θα ακουμπήσει κάθε επόμενη story.
Story 0: Create the Angular application scaffold. Τα acceptance criteria θα μπορούσαν να είναι:
- Given the repository does not contain an Angular app, when the scaffold task runs, then a new Angular application is created.
- Given the Angular app is created, then the project can be installed, built, and tested successfully.
- Given the project uses a current Angular version, then standalone components are used unless the existing convention says otherwise.
- Given the scaffold is complete, then a dedicated todo feature folder exists or is clearly planned, and no todo business logic is implemented yet.
Κράτα αυτή τη story σκόπιμα απλή. Αυτή η απλότητα δεν είναι έλλειψη φιλοδοξίας, είναι scope control. Πριν ξεκινήσει, ο agent πρέπει να ξέρει τα βασικά: το όνομα της εφαρμογής, τον package manager, την προσέγγιση για το styling, την έκδοση του Angular, το αν πρόκειται για νέα εφαρμογή ή για υπάρχον repo, και τις εντολές build και test. Και είναι done μόνο όταν το scaffold υπάρχει, η εφαρμογή ξεκινάει τοπικά, οι εντολές build και test περνάνε, ο φάκελος todo είναι στη θέση του, δεν έχει τρυπώσει καμία business logic, δεν προστέθηκε κανένα αδέσποτο dependency, και ο agent αναφέρει πίσω τα αρχεία που παρήγαγε και τις εντολές που έτρεξε.
Χωρίς τη Story 0, ο agent τείνει να χτίσει το θεμέλιο και το πρώτο feature με την ίδια ανάσα. Αυτό σημαίνει μεγαλύτερο diff, περισσότερες υποθέσεις ψημένες μέσα, και ένα δυσκολότερο review στο τέλος. Με τη Story 0, το θεμέλιο επαληθεύεται πρώτα, και μόνο τότε ο agent προχωράει στη συμπεριφορά.
Σπάσε την εφαρμογή σε μικρές, composable stories
Μόλις μπει στη θέση του το scaffold, σπάσε την ίδια την todo app σε μικρές stories. Μια χρήσιμη σειρά θα μπορούσε να είναι:
- Story 0: Create the Angular application scaffold.
- Story 1: Create the todo domain model and state service.
- Story 2: Add a form to create a todo.
- Story 3: Display the todo list.
- Story 4: Toggle a todo between active and completed.
- Story 5: Delete a todo.
- Story 6: Filter todos by all, active, and completed.
- Story 7: Persist todos in local storage.
- Story 8: Add empty, validation, and error-safe UI states.
Πέρασα χρόνια διευθύνοντας κουζίνες εστιατορίων πριν καν γράψω λογισμικό, και το πράγμα που κρατάει μια κουζίνα ζωντανή σε ένα πολυάσχολο βράδυ είναι ότι κανείς δεν προσπαθεί να μαγειρέψει όλη την παραγγελία μονομιάς. Τα δελτία έρχονται, και τα δουλεύεις ένα πιάτο τη φορά, με μια σειρά που βγάζει νόημα, ώστε το pass να μη γίνει ποτέ χάος. Το να σπας τη δουλειά για έναν agent είναι το ίδιο ένστικτο. Το scaffold δίνει στην εφαρμογή ένα θεμέλιο, το domain model της δίνει ένα σχήμα δεδομένων, το state service της δίνει ελεγχόμενη συμπεριφορά, οι UI stories καταναλώνουν αυτή τη συμπεριφορά, και το persistence έρχεται τελευταίο επειδή είναι ένα γνήσια ξεχωριστό ζήτημα.
Αυτό είναι ακριβώς το είδος αποσύνθεσης που κάνει τους agents πιο αξιόπιστους. Ο agent δεν χρειάζεται ποτέ να λύσει όλη την εφαρμογή μονομιάς. Λύνει μία μικρή, testable συμπεριφορά τη φορά, κάτι που μειώνει δραματικά την ασάφεια. Μειώνει επίσης την προσπάθεια του review, επειδή το να κοιτάς μία εστιασμένη αλλαγή είναι πολύ ευκολότερο από το να κάνεις review ένα μεγάλο diff παραγόμενο από AI που ανακατεύει setup, state, UI, validation, persistence και styling όλα σε ένα πέρασμα.
Τα acceptance criteria μετατρέπουν την ασαφή πρόθεση σε testable συμπεριφορά
Πάρε τη Story 2, την προσθήκη μιας φόρμας για τη δημιουργία ενός todo. Μια αδύναμη απαίτηση θα ήταν:
The user can add todos.
Αυτή η πρόταση φαίνεται απλή, και εκεί είναι η παγίδα, επειδή αφήνει σχεδόν τα πάντα ανοιχτά:
- Τι γίνεται όταν το input είναι άδειο;
- Πρέπει τα κενά να κόβονται;
- Πρέπει το input να καθαρίζει μετά το submit;
- Ένα νέο todo είναι active ή completed by default;
- Πρέπει να επιτρέπονται διπλότυπα todos;
- Πρέπει το πάτημα Enter να κάνει submit τη φόρμα;
Ο agent μπορεί να κάνει λογικές υποθέσεις για όλα αυτά, αλλά οι υποθέσεις δεν είναι απαιτήσεις. Καλύτερα acceptance criteria θα ήταν:
- Given the todo input is empty, when the user submits the form, then no todo is created.
- Given the todo input contains only spaces, when the user submits the form, then no todo is created.
- Given the todo input contains text, when the user submits the form, then a new todo is added to the list.
- Given the todo text has leading or trailing spaces, when the todo is created, then the stored text is trimmed.
- Given the todo is added successfully, then the input field is cleared.
- Given a todo is newly created, then it is active by default.
Τώρα η συμπεριφορά είναι συγκεκριμένη, και ο agent μπορεί να μετατρέψει αυτά τα criteria σε tests πριν γράψει έστω και μία γραμμή του implementation. Αυτό, περισσότερο από οτιδήποτε άλλο, είναι ο πυρήνας του TDD στο agentic AI. Δεν ζητάς από τον agent να "φτιάξει μια φόρμα." Του ζητάς να αποδείξει μια συμπεριφορά.
Πες "γράψε πρώτα τα tests"
Στη γλώσσα του παραδοσιακού TDD, ο κόσμος λέει "γράψε ένα failing test." Η φράση είναι ακριβής, αλλά ηχεί παράξενα σε όποιον δεν είναι ήδη ποτισμένος με TDD, επειδή ακούγεται σαν να του ζητάς να γράψει κάτι χαλασμένο επίτηδες.
Μια πιο ξεκάθαρη οδηγία είναι:
Write the tests first.
Ή, ακόμα καλύτερα:
Define the expected behavior with tests before implementation.
Το test θα αποτύχει στην αρχή επειδή το feature δεν υπάρχει ακόμα, και αυτό ακριβώς θέλεις. Η αποτυχία είναι που αποδεικνύει ότι το test ελέγχει κάτι πραγματικό.
Για την Angular todo app, πριν κάνει implement το addTodo, ο agent θα μπορούσε να γράψει ένα test σαν αυτό:
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 δεν υπάρχει ακόμα είτε επειδή το τρέχον implementation προσθέτει με χαρά άδεια todos. Μετά ο agent γράφει τη μικρότερη ποσότητα κώδικα που το κάνει να περάσει:
addTodo(text: string): void {
const trimmed = text.trim()
if (!trimmed) {
return
}
this.todos.update((todos) => [
...todos,
{
id: crypto.randomUUID(),
text: trimmed,
completed: false,
},
])
}Ο βρόχος είναι απλός να τον κρατήσεις στο μυαλό σου:
- Write the tests first.
- Confirm they fail for the expected reason.
- Implement the smallest change.
- Run the tests again.
- Refactor only when the tests are green.
- Report the evidence.
Αυτό δίνει στον agent ένα σφιχτό feedback loop, και δίνει σε εμένα έναν ξεκάθαρο δρόμο να επικυρώσω τη δουλειά αντί να στραβοκοιτάζω ένα diff και να ελπίζω.
Το Ready και το Done λένε στον agent πότε να ξεκινήσει και πότε να σταματήσει
Το Definition of Ready και το Definition of Done συνήθως αντιμετωπίζονται ως τυπικότητες. Στην agentic ανάπτυξη γίνονται γνήσια πρακτικά, επειδή είναι οι δύο πύλες που κρατάνε τον agent μέσα στη story.
Το Definition of Ready είναι η πύλη του "μπορείς να ξεκινήσεις." Για τη φόρμα add-todo, ο agent δεν πρέπει να ξεκινήσει μέχρι να υπάρχουν το scaffold, το todo model και το state service, να είναι ορισμένη η συμπεριφορά add-todo και το validation της, να είναι γνωστή η θέση της φόρμας input, και να έχει συμφωνηθεί η προσέγγιση για το testing. Μία γραμμή μετράει περισσότερο από όσο δείχνει: το persistence είναι εκτός scope για αυτή τη story. Άφησέ το απ' έξω, και ο agent μπορεί να αποφασίσει να καλωδιώσει το local storage ενώ χτίζει τη φόρμα. Ακούγεται βοηθητικό, αλλά αθόρυβα ανακατεύει ευθύνες, και οι ανακατεμένες ευθύνες σημαίνουν μεγαλύτερες αλλαγές που είναι δυσκολότερες να γίνουν review και δυσκολότερες να δοκιμαστούν.
Το Definition of Done είναι η πύλη του "μπορείς να σταματήσεις," και είναι αυστηρότερο από το "βγήκε κάποιος κώδικας." Για αυτή τη story, done σημαίνει ότι η φόρμα είναι υλοποιημένη, τα άδεια και τα μόνο με κενά submissions δεν δημιουργούν τίποτα, τα έγκυρα submissions δημιουργούν active todos, το κείμενο κόβεται πριν την αποθήκευση, το input καθαρίζει μετά από ένα επιτυχημένο submit, τα unit tests καλύπτουν τη λογική και τα component tests καλύπτουν την αλληλεπίδραση, τα υπάρχοντα tests συνεχίζουν να περνάνε, δεν άλλαξε κανένα άσχετο αρχείο, δεν προστέθηκε κανένα περιττό dependency, και ο agent αναφέρει τα αλλαγμένα αρχεία και τα αποτελέσματα των tests.
Αυτό το τελευταίο κομμάτι είναι που αρνούμαι να παραλείψω. Μια σύνοψη από μόνη της δεν αρκεί. Το χρήσιμο κομμάτι είναι η απόδειξη πίσω από αυτή: οι εντολές που έτρεξαν, τα tests που πέρασαν, τα αρχεία που άλλαξαν, και όποια risks ή assumptions μένουν ανοιχτά. Done σημαίνει ότι υπάρχει απόδειξη, όχι μόνο μια σίγουρη παράγραφος.
Τα expected files και τα dependencies προστατεύουν την αρχιτεκτονική
Ένα από τα πιο χρήσιμα πράγματα που παράγει ένας agent κατά το planning είναι η λίστα των expected files. Πριν κάνει implement οτιδήποτε, πρέπει να σου πει ποια αρχεία σκοπεύει να δημιουργήσει ή να αγγίξει, και εξίσου χρήσιμα, ποια πρέπει να αφήσει ήσυχα:
src/app/todos/todo.model.tssrc/app/todos/todo-store.service.ts(and its.spec.ts)src/app/todos/add-todo-form.component.ts(with template and.spec.ts)src/app/todos/todo-list.component.ts(with template and.spec.ts)src/app/todos/todo-storage.service.ts(and its.spec.ts)
Και εκτός ορίων: src/app/payment/*, src/app/auth/*, src/environments/*, και το package.json εκτός αν ένα dependency έχει εγκριθεί ρητά.
Τώρα έχω ένα όριο scope. Αν ο agent υλοποιεί το "delete todo" και ξαφνικά απλώνεται σε app-wide routing, authentication ή package dependencies, μπορώ να αμφισβητήσω την αλλαγή αμέσως. Το file scope είναι μια μορφή αρχιτεκτονικού ελέγχου, και η agentic ανάπτυξη το χρειάζεται ακριβώς επειδή οι agents κινούνται ανάμεσα στα αρχεία τόσο γρήγορα.
Η ίδια πειθαρχία ισχύει για τα dependencies. Ο agent πρέπει να τα ονομάσει πριν γράψει οποιονδήποτε κώδικα, και για μια todo app η ειλικρινής απάντηση είναι σύντομη: Angular standalone components, Angular forms, ένα dedicated state service, και browser local storage μόνο στη story του persistence. Κανένα backend, κανένα NgRx, καμία βάση δεδομένων, καμία βιβλιοθήκη UI components, κανένα νέο runtime dependency. Οι agents πιάνουν εργαλεία πριν αποδείξουν ότι τα χρειάζονται, οπότε το να κάνεις ρητό το dependency plan κρατάει το implementation ειλικρινές και απλό.
Δουλεύοντας μία story τη φορά, σε έναν ελεγχόμενο βρόχο
Μόλις εγκριθεί το plan, ο agent υλοποιεί μία story τη φορά με TDD. Για τη Story 1, το prompt θα μπορούσε να είναι:
Implement Story 1 using TDD.
First create tests based on the approved acceptance criteria.
The todo store should start empty, add a todo, return all todos, trim todo text, reject empty todos, and create todos as active by default.
Run the tests and confirm they fail because the behavior is not implemented yet.
Then implement the smallest code needed to pass.
Do not implement UI, local storage, filtering, or deletion in this story.
Αυτό δίνει στον agent έναν στενό στόχο. Ένα πιθανό σετ tests για το store: ξεκινάει άδειο, προσθέτει ένα todo με έγκυρο κείμενο, κόβει το κείμενο, απορρίπτει άδεια και μόνο με κενά todos, τα δημιουργεί active by default, τα κάνει toggle σε completed και πίσω, τα διαγράφει, και επιστρέφει all, active και completed todos όποτε ζητηθεί. Κάθε συμπεριφορά γίνεται testable, κάθε test γίνεται feedback, και κάθε βήμα implementation γίνεται μικρότερο από το προηγούμενο. Ο agent δεν χρειάζεται ποτέ να μαντέψει τι σημαίνει "σωστό," επειδή τα tests το ορίζουν ήδη.
Το persistence είναι το πιο ξεκάθαρο παράδειγμα του γιατί αυτά τα όρια αξίζουν τον κόπο. Μια todo app πιθανότατα όντως χρειάζεται local storage, αλλά δεν έχει καμία δουλειά να εμφανίζεται στις πρώτες λίγες stories. Κάνε το Story 7 από μόνο του, με τα δικά του criteria: save todos to local storage on change, load them on startup, start empty when storage is empty, και το εύκολο να το παραλείψεις, να επιβιώνει από invalid JSON χωρίς να κρασάρει η εφαρμογή. Κρατημένο απομονωμένο έτσι, το persistence είναι εύκολο να επαληθευτεί, επειδή ο agent υλοποιεί μία ευθύνη με ξεκάθαρα tests πίσω της αντί να μπλέκει state, UI, validation και storage σε μία μεγάλη αλλαγή.
Το Claude Code και το OpenAI Codex ταιριάζουν καλά σε αυτό το pattern
Το Claude Code είναι φτιαγμένο ως ένα agentic coding εργαλείο που κατανοεί ένα codebase, κάνει edit αρχεία, τρέχει εντολές, και δουλεύει μέσα από development tasks από οδηγίες σε φυσική γλώσσα.3 Το OpenAI Codex είναι φτιαγμένο ως ένας software engineering agent που δουλεύει σε απομονωμένα περιβάλλοντα, κάνει edit κώδικα, τρέχει ελέγχους, επικυρώνει τη δουλειά του, και δείχνει τα diffs των αλλαγμένων αρχείων.4 Και τα δύο ταιριάζουν δυνατά σε αυτό το workflow, και η ικανότητά τους είναι ακριβώς ο λόγος που το workflow χρειάζεται δομή γύρω του.
Το pattern δεν πρέπει να είναι "χτίσε την todo app." Πρέπει να είναι μια ακολουθία που μπορείς να επαναλάβεις: plan first, δημιούργησε ή επαλήθευσε το scaffold, σπάσε τη δουλειά σε μικρές stories, όρισε τα acceptance criteria, βάλε το Ready και το Done, ονόμασε τα αρχεία και τα dependencies, γράψε πρώτα τα tests, υλοποίησε τον μικρότερο κώδικα που περνάει, τρέξε την επαλήθευση, ανάφερε την απόδειξη, μετά προχώρα στην επόμενη story. Αυτή είναι η διαφορά ανάμεσα σε ελεγχόμενη πρόοδο και ανεξέλεγκτη παραγωγή.
Ένα επαναχρησιμοποιήσιμο prompt που μπορείς να κλέψεις
Ορίστε το planning prompt που πραγματικά χρησιμοποιώ. Ξεκίνα με το plan:
Planning mode only. Do not edit files.
Inspect this Angular project and create a delivery plan for a todo app.
Break the deliverable into small composable stories. The first story must be Story 0: Create or verify the Angular application scaffold.
For each story, provide: goal, acceptance criteria, Definition of Ready, Definition of Done, expected files to create or modify, files that should not be touched, dependencies, required tests, risks and assumptions, and suggested implementation order.
The todo app should support adding todos, displaying todos, toggling completion, deleting todos, filtering by all, active, and completed, and persisting todos to local storage.
Do not generate production code yet. Stop after the plan.
Μετά, μόλις κάνεις review το plan, τρέξε το scaffold μόνο του:
Implement Story 0 only. Create or verify the Angular scaffold. Confirm the app builds and tests successfully. Create or identify the todo feature folder, but do not implement todo business logic yet. Do not add unnecessary dependencies. Report changed files, commands run, and verification results.
Και μετά κάθε feature story στο ίδιο σχήμα:
Implement Story 1 using TDD. First write tests based on the approved acceptance criteria. Run them and confirm they fail because the behavior is not implemented yet. Then implement the smallest code needed to pass. Do not implement UI, persistence, filtering, or deletion in this story. Run the relevant test suite, linting, and type checks. Provide changed files and verification evidence.
Ο ρυθμός δεν αλλάζει ποτέ. Μία story, μία συμπεριφορά, ένα σετ tests, ένα implementation, μία αναφορά επαλήθευσης. Μετά το επαναλαμβάνεις.
Γιατί αυτό φτάνει πιο κοντά σε αυτό που ζήτησες
Η αξία όλου αυτού είναι η αλυσίδα ελέγχου που το διατρέχει. Το requirement γίνεται stories, και οι stories γίνονται acceptance criteria. Τα acceptance criteria γίνονται tests, και τα tests οδηγούν το implementation. Το Ready ελέγχει πότε μπορεί να ξεκινήσει ο agent, και το Done ελέγχει πότε μπορεί να σταματήσει. Τα expected files ελέγχουν το scope, το dependency plan ελέγχει τη σερνάμενη πολυπλοκότητα, και η απόδειξη επαλήθευσης ελέγχει την ψεύτικη σιγουριά.
Τίποτα από αυτά δεν εγγυάται την τελειότητα, επειδή κανένα workflow δεν το κάνει. Αυτό που κάνει είναι να μειώνει την ασάφεια, να κάνει τη δουλειά εύκολη να επιθεωρηθεί, και να δίνει και στον agent και σε εμένα έναν κοινό, συγκεκριμένο ορισμό της ορθότητας. Λιγότερο μάντεμα, λιγότερο rework, λιγότερη κούραση review, και ένα αποτέλεσμα που μπορώ πραγματικά να μετρήσω.
Το συμπέρασμα
Το agentic AI δεν εξαλείφει την ανάγκη για engineering πειθαρχία. Την κάνει να μετράει περισσότερο.
Μια ταπεινή todo app δείχνει όλο το pattern. Ξεκίνα με το scaffold. Σπάσε τη δουλειά σε μικρές stories. Όρισε τα acceptance criteria. Βάλε το Ready και το Done. Ονόμασε τα αρχεία και τα dependencies. Γράψε πρώτα τα tests, μετά άσε τον agent να υλοποιήσει μόνο ό,τι αποδεικνύουν τα tests. Είναι το ίδιο ένστικτο που κρατάει μια κουζίνα ήρεμη σε ένα πολυάσχολο βράδυ: δούλεψε ένα δελτίο τη φορά, και έλεγξε κάθε πιάτο πριν φύγει από το pass.
Αυτός είναι ο ρόλος του TDD στην εποχή του agentic AI. Δεν ήταν ποτέ μόνο μια τεχνική testing. Είναι ένας τρόπος να μετατρέψεις την ασαφή πρόθεση σε ελεγχόμενο delivery, και να πεις τι σημαίνει "σωστό" πριν υπάρξει ο κώδικας. Σε έναν κόσμο όπου οι agents μπορούν να παράγουν κώδικα πιο γρήγορα από όσο μπορεί ο καθένας μας άνετα να τον κάνει review, αυτή η διαφορά είναι όλο το παιχνίδι.
Footnotes
-
Google Cloud, "Announcing the 2025 DORA Report", 2025, καλύπτει το report "State of AI-assisted Software Development" (dora.dev). Βασισμένο σε απαντήσεις από σχεδόν 5.000 επαγγελματίες της τεχνολογίας παγκοσμίως. ↩
-
GitLab, "GitLab Research Reveals Organizations Are Generating AI Code Faster Than They Can Control It", 2026. Αναφέρει τα ευρήματα του 80%, 92% και 85%, από μια έρευνα με 1.528 developers και technology buyers σε έξι χώρες, που διεξήχθη από την The Harris Poll. ↩
-
Anthropic, "Claude Code overview": "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools." ↩
-
OpenAI, "Introducing Codex", 2025. Περιγράφει το Codex ως έναν cloud-based software engineering agent που τρέχει κάθε task στο δικό του sandbox και προτείνει pull requests για review. ↩