Λεξικό τεχνητής νοημοσύνης

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

Η ετικέτα μετακινείται μέσω ενός γνωστού μηχανισμού, που μερικές φορές αποκαλείται «φαινόμενο AI»: μόλις μια τεχνική λειτουργήσει αξιόπιστα, μετονομάζεται — είναι «απλώς» αναζήτηση, «απλώς» στατιστική — και το «AI» προχωρά στο επόμενο άλυτο πρόβλημα. Η παρατήρηση είναι παλιά. Ο Bertram Raphael το διατύπωσε το 1971 ως εξής: «Το AI είναι συλλογική ονομασία για προβλήματα που ακόμη δεν ξέρουμε πώς να λύσουμε σωστά με υπολογιστή». Η εκδοχή του Larry Tesler, γύρω στο 1979: «Νοημοσύνη είναι ό,τι δεν έχουν κάνει ακόμη οι μηχανές».

Γι’ αυτό οι συζητήσεις για το AI συχνά δεν συναντιούνται. Ένας ισχυρισμός όπως «το AI δεν μπορεί να συλλογιστεί» ή «το AI είναι υπερτιμημένο» κρύβει μια χρονική σήμανση — μπορεί να αφορά τα έμπειρα συστήματα, τους ταξινομητές εικόνων της δεκαετίας του 2010 ή το LLM του περασμένου μήνα, και κάθε αναφορά οδηγεί σε διαφορετικό συμπέρασμα. Όταν μια συζήτηση για το AI κολλάει, η λύση συνήθως είναι να αντικαταστήσετε τη λέξη με τον ακριβή όρο που εννοείτε: το model, το harness, τον agent, το context που του δόθηκε.

Αποφύγετε: τη χρήση του «AI» σε οποιονδήποτε τεχνικό ισχυρισμό — κατονομάστε αντί γι’ αυτό το συγκεκριμένο μέρος. Η φράση «AI coding» ως ονομασία της πρακτικής είναι εντάξει· το «το AI κάνει hallucination» δεν είναι.

Παράδειγμα:

«Ο CTO θέλει να μάθει αν το AI μπορεί να διαχειριστεί την ουρά διαλογής».

«Διευκρινίστε το πριν ορίσετε το εύρος — εννοεί ένα LLM σε harness με πρόσβαση στο σύστημα tickets. Το “AI” από μόνο του δεν αποτελεί προδιαγραφή».

Τα parameters. Stateless — κάνει μόνο next-token prediction. Τα «Claude Opus 4.x» και «GPT-5.x» είναι models. Ένα model από μόνο του δεν μπορεί να εκτελέσει agentic εργασία· πρέπει να αποκτήσει harness.

Τα models δεν μπορούν να διαβάζουν αρχεία, να εκτελούν εντολές, να περιηγούνται στον ιστό ή να θυμούνται τη χθεσινή μέρα — δέχονται tokens και προβλέπουν tokens ως έξοδο, μία φορά ανά model provider request. Ό,τι μοιάζει με εργασία agent — επιλογή tools, ανάγνωση αποτελεσμάτων, επανάληψη μέχρι να ολοκληρωθεί η εργασία — είναι το harness που συντονίζει πολλές τέτοιες προβλέψεις τη μία μετά την άλλη.

Οι Model providers προσφέρουν models σε βαθμίδες: ένα μεγάλο, εξυπνότερο αλλά αργό και ακριβό, και μικρότερα, ταχύτερα και φθηνότερα αλλά λιγότερο ικανά. Η επιλογή βαθμίδας είναι πραγματική απόφαση — ισχυρό model για σχεδιασμό και δύσκολη αποσφαλμάτωση, ελαφρύτερο για μηχανικές αλλαγές — και τα harness επιτρέπουν την αλλαγή στη μέση του session.

Η ακριβής χρήση της λέξης βελτιώνει και τη διάγνωση. Το «το model δεν είναι καλό σε αυτό» είναι συγκεκριμένος ισχυρισμός — το ίδιο model σε διαφορετικό harness ή με διαφορετικό context συχνά συμπεριφέρεται εντελώς διαφορετικά. Πριν κατηγορήσετε το model, ελέγξτε τι του δόθηκε: οι περισσότερες απογοητευτικές έξοδοι οφείλονται στο context ή στο harness, όχι στα parameters.

Παράδειγμα:

«Να αλλάξουμε το model από Sonnet σε Opus για το βήμα σχεδιασμού;»

«Δοκιμάστε το — αλλά το harness κάνει το μεγαλύτερο μέρος της δουλειάς σε αυτή την εργασία. Η αλλαγή model δεν θα βοηθήσει αν το system prompt και τα εργαλεία είναι λανθασμένα».

Οι αριθμοί μέσα σε ένα model — συχνά δισεκατομμύρια — που ρυθμίζονται κατά το training. Ό,τι «γνωρίζει» το model βρίσκεται σε αυτούς. Το training τους ορίζει· το inference τους χρησιμοποιεί χωρίς αλλαγή. Ονομάζονται επίσης weights.

Στην πράξη, τα parameters είναι αυτά που μετατρέπουν την είσοδο σε έξοδο. Το Next-token prediction είναι ένας τεράστιος υπολογισμός: τα tokens στο context window εισέρχονται, πολλαπλασιάζονται μέσω των parameters και προκύπτει πρόβλεψη για το επόμενο token. Δεν υπάρχει βάση δεδομένων γεγονότων μέσα στο model ούτε πίνακας αναζήτησης κώδικα — μόνο αυτοί οι αριθμοί, οργανωμένοι έτσι ώστε ο υπολογισμός να τείνει να παράγει χρήσιμη έξοδο. Γεγονότα που μπορεί να ανακαλέσει το model από την εκπαίδευση, όπως ένα API τυπικής βιβλιοθήκης, αποτελούν parametric knowledge: είναι αποθηκευμένα στα parameters, δεν ανακτώνται από κάπου.

Η λεπτομέρεια που αξίζει να εμπεδώσετε είναι ότι τα parameters παγώνουν μετά το training. Τίποτα από όσα κάνετε σε ένα session δεν τα αλλάζει — καμία διόρθωση, κανένα codebase που του δείχνετε, κανένα λάθος από το οποίο μαθαίνει. Κάθε session εκτελείται με τους ίδιους αριθμούς. Γι’ αυτό το model είναι stateless, η ενσωματωμένη γνώση του σταματά στο knowledge cutoff και οτιδήποτε αφορά συγκεκριμένο έργο πρέπει να παρέχεται μέσω context. Τα parameters αλλάζουν μόνο με περισσότερο training — που δημιουργεί, στην πράξη, διαφορετικό model.

Παράδειγμα:

«Μπορούμε να κάνουμε fine-tune στο codebase μας;»

«Αυτό θα ενημέρωνε τα parameters — και μετά θα είχατε διαφορετικό model. Για ένα έργο, σχεδόν πάντα είναι φθηνότερο να φορτώσετε το codebase ως context παρά να το εκπαιδεύσετε ξανά».

Η διαδικασία που ορίζει τα parameters ενός model, εκθέτοντάς το σε τεράστιες ποσότητες κειμένου και προσαρμόζοντας τα parameters για να βελτιώσει το next-token prediction. Είναι εφάπαξ, δαπανηρή διαδικασία που εκτελεί ο model provider. Περιλαμβάνει τόσο το pre-training (τη βασική, μαζική εκπαίδευση) όσο και το post-training (μεταγενέστερες βελτιώσεις, όπως η τήρηση οδηγιών και η ασφάλεια)· σε αυτό το επίπεδο του γλωσσαρίου η διάκριση δεν έχει σημασία.

Ο μηχανισμός είναι η επανάληψη σε μεγάλη κλίμακα: δείξτε στο model ένα τμήμα κειμένου, ζητήστε του να προβλέψει το επόμενο token, ωθήστε τα parameters προς το πραγματικό επόμενο token και επαναλάβετε τη διαδικασία σε τρισεκατομμύρια tokens. Τίποτα δεν αποθηκεύεται ως γεγονότα ή κανόνες — ό,τι «γνωρίζει» το model είναι παρενέργεια της βελτίωσης στην πρόβλεψη, συμπιεσμένη στα parameters ως parametric knowledge.

Δύο συνέπειες έχουν σημασία στην καθημερινή χρήση. Το training τελειώνει σε συγκεκριμένη χρονική στιγμή, άρα το model έχει knowledge cutoff — δεν έχει δει την έκδοση βιβλιοθήκης στην οποία αναβαθμίσατε τον περασμένο μήνα. Και το training δεν είναι κάτι που μπορείτε να κάνετε εσείς: όταν το model δεν γνωρίζει το codebase, τις συμβάσεις ή τα εσωτερικά API σας, η λύση δεν είναι ποτέ «εκπαίδευσε το model»· είναι να βάλετε αυτό το υλικό στο context, τη μία είσοδο που ελέγχετε.

Παράδειγμα:

«Μπορούμε να το κάνουμε να γνωρίζει το εσωτερικό μας API;»

«Όχι μέσω training — αυτή είναι διαδικασία μηνών που κάνει ο model provider. Φορτώστε τα docs του API στο context· αυτός είναι ο μοχλός που πράγματι ελέγχετε».

Εκτέλεση ενός εκπαιδευμένου model για την παραγωγή εξόδου — αυτό συμβαίνει σε κάθε model provider request. Τα Parameters παραμένουν σταθερά· το model απλώς κάνει next-token prediction πάνω στο context που του δίνεται. Είναι φθηνό σε σχέση με το training, αλλά χρεώνεται ανά token και αποτελεί το κύριο κόστος χρήσης ενός model.

Η ζωή ενός model χωρίζεται σε δύο φάσεις:

Τίποτα από όσα κάνετε κατά το inference δεν γράφεται πίσω στα parameters — γι’ αυτό μια διόρθωση που κάνετε σήμερα δεν διατηρείται αύριο. Το model που κάνει το ίδιο λάθος στο επόμενο session, αφού εξηγήσατε προσεκτικά τη διόρθωση, δεν σας αγνόησε· δεν μπορεί να μάθει από την ανταλλαγή. Το model είναι stateless — η συνέχεια πρέπει να προέρχεται από έξω του, από το context window ή ένα memory system.

Αυτός ο μηχανισμός εξηγεί επίσης τη χρέωση. Κάθε αίτημα εκτελεί το model πάνω σε ολόκληρο το context, άρα το κόστος κλιμακώνεται ανάλογα με τα input tokens και τα output tokens, ενώ ένας agent που κάνει δεκάδες tool calls πληρώνει inference σε κάθε διαδρομή μετ’ επιστροφής. Γι’ αυτό το μέγεθος του context είναι ζήτημα κόστους, όπως και ποιότητας.

Παράδειγμα:

«Γιατί ο λογαριασμός αυξάνεται ανάλογα με τη χρήση αντί να είναι σταθερή άδεια;»

«Πληρώνετε για inference — κάθε model provider request εκτελεί το model στο υλικό του provider. Το training έχει ήδη γίνει, αλλά το inference χρεώνεται ανά αίτημα, και ένα μόνο turn μπορεί να επεκταθεί σε πολλά αιτήματα όταν καλούνται εργαλεία».

Το effort είναι ρυθμιστικό για το πόσο συλλογίζεται ένα model πριν απαντήσει. Ορίζεται ανά model provider request και ελέγχει τη διάρκεια της σκέψης που επεξεργάζεται το model πριν αρχίσει να γράφει την απάντηση που βλέπετε. Αυτή η σκέψη παράγεται κατά το inference, όπως καθετί άλλο· το harness συχνά την κρύβει, αλλά αποτελεί πραγματική εργασία του model.

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

Τα περισσότερα harness παρουσιάζουν το effort ως μικρή κλίμακα:

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

Ταιριάξτε το effort στην εργασία, όχι στο session. Αυξήστε το για το κομμάτι που είναι πραγματικά δύσκολο να συλλογιστείτε και μειώστε το για τη μηχανική εργασία γύρω του.

Παράδειγμα:

«Συνεχίζει να κάνει λάθος σε αυτή τη διόρθωση ταυτόχρονης εκτέλεσης — την έχω εξηγήσει τρεις φορές».

«Αυξήστε το effort. Πρόκειται για σφάλμα που απαιτεί συλλογισμό και στην προεπιλεγμένη ρύθμιση δεν σκέφτεται αρκετά πριν δεσμευτεί σε μια προσέγγιση».

Η ατομική μονάδα που διαβάζει και γράφει ένα model. Είναι περίπου στο μέγεθος λέξης, αλλά όχι ακριβώς — οι κοινές λέξεις αποτελούν ένα token, ενώ οι σπάνιες ή μεγάλες λέξεις χωρίζονται σε πολλά. Το μέγεθος του context window, το κόστος και η καθυστέρηση μετρώνται όλα σε tokens.

Το κείμενο γίνεται tokens μέσω tokenizer: σταθερό λεξιλόγιο δεκάδων χιλιάδων τμημάτων που μαθαίνεται πριν από το training και χωρίζει οποιαδήποτε είσοδο σε ακολουθία καταχωρίσεων αυτού του λεξιλογίου. Το model δεν βλέπει ποτέ χαρακτήρες ή λέξεις — κάθε τμήμα κειμένου μετατρέπεται σε tokens στην είσοδο και το next-token prediction παράγει έξοδο ένα token τη φορά.

Ως πρακτικός κανόνας, ένα token είναι περίπου τα τρία τέταρτα μιας αγγλικής λέξης, άρα χίλια tokens αντιστοιχούν περίπου σε 750 λέξεις. Ο κώδικας είναι λιγότερο προβλέψιμος: κοινές λέξεις-κλειδιά και ιδιωματισμοί κωδικοποιούνται συμπαγώς, ενώ παραγόμενα αναγνωριστικά, hashes, blobs base64 και minified έξοδος χωρίζονται σε πολλά tokens ανά «λέξη». Το μοτίβο είναι το εξής: κείμενο που εμφανίστηκε συχνά στο υλικό πηγής του tokenizer παίρνει σύντομες, αποδοτικές κωδικοποιήσεις· κείμενο που δεν εμφανίστηκε χωρίζεται σε πολλά μικρά κομμάτια. Ένα hash όπως το `a3f9c2e1` δεν εμφανίστηκε πουθενά, επομένως χωρίζεται σε πολλά tokens, ενώ το `function` είναι ένα. Γι’ αυτό ένα αρχείο που φαίνεται μικρό αλλά είναι γεμάτο ασυνήθιστες συμβολοσειρές μπορεί να καταλαμβάνει απροσδόκητα μεγάλο μέρος του context window.

Τα tokens είναι η μονάδα μέτρησης για όλα τα υπόλοιπα. Το κόστος χρεώνεται ανά token — οι providers χρεώνουν χωριστά τα input tokens και τα output tokens. Η ταχύτητα μετριέται σε tokens ανά δευτερόλεπτο, αφού η έξοδος δημιουργείται ένα token τη φορά. Και το context window έχει σταθερό αριθμό tokens, επομένως το πλήθος tokens των αρχείων σας καθορίζει πόσα χωρούν.

Αποφύγετε: «λέξη» — τα όρια των tokens δεν ταιριάζουν με τα όρια των λέξεων, ενώ τα tokens ανά δευτερόλεπτο / ανά δολάριο είναι οι μονάδες που έχουν πραγματικά σημασία.

Παράδειγμα:

«Πόσο μεγάλο θα είναι αυτό το prompt;»

«Περάστε το από τον tokenizer — το schema είναι συμπαγές, αλλά τα κλειδιά JSON είναι ασυνήθιστα και θα χωριστούν σε περισσότερα tokens απ’ όσα νομίζετε».

Τι κάνει πραγματικά το model. Με δεδομένο ένα context, δειγματοληπτεί ένα επόμενο token, το προσθέτει και εκτελεί ξανά τον ίδιο βρόχο. Κάθε έξοδος — πρόταση, tool call, αρχείο χιλίων γραμμών — χτίζεται ένα token τη φορά. Το model δεν έχει άλλον τρόπο λειτουργίας.

Κάθε βήμα λειτουργεί με τον ίδιο τρόπο: τα tokens στο context window περνούν από τα parameters, που παράγουν πιθανότητα για κάθε token του λεξιλογίου — αυτό είναι πολύ πιθανό να ακολουθήσει, εκείνο λιγότερο. Ένα token επιλέγεται δειγματοληπτικά από αυτές τις πιθανότητες, προστίθεται και ο βρόχος εκτελείται ξανά με ελαφρώς μεγαλύτερο context. Αυτή η δειγματοληψία εξηγεί γιατί το ίδιο prompt παράγει διαφορετική έξοδο σε διαφορετικές εκτελέσεις: ο non-determinism είναι ενσωματωμένος στον μηχανισμό, όχι σφάλμα που προστέθηκε από πάνω.

Η κατανόηση αυτού του μηχανισμού εξηγεί συμπεριφορά που αλλιώς φαίνεται παράξενη. Το model δεν ελέγχει ποτέ αν ένα token είναι αληθές πριν το εκπέμψει — μόνο αν είναι πιθανό — κι αυτό είναι η ρίζα του hallucination. Δεσμεύεται σε κάθε token καθώς προχωρά, άρα μια εισαγωγική πρόταση που ακούγεται σίγουρη μπορεί να στρέψει λανθασμένα την υπόλοιπη απάντηση. Και επειδή τα output tokens παράγονται αυστηρά ένα κάθε φορά, η ταχύτητα παραγωγής θέτει το κατώτατο όριο της ταχύτητας εργασίας κάθε agent.

Παράδειγμα:

«Πώς “αποφασίζει” ο agent να καλέσει εργαλείο;»

«Δεν αποφασίζει — είναι εξ ολοκλήρου πρόβλεψη επόμενου token. Το tool call είναι απλώς μια δομημένη συμβολοσειρά που το harness αναλύει από τη ροή εξόδου».

Η ίδια είσοδος μπορεί να παράγει διαφορετική έξοδο. Εκτελέστε ένα model δύο φορές με πανομοιότυπο context και μπορεί να πάρετε δύο διαφορετικές απαντήσεις — κάποιες φορές διαφέρει μία λέξη, άλλες μια εντελώς διαφορετική προσέγγιση. Δεν χρειάζεται να αλλάξει τίποτα στον κώδικά σας για να συμβεί αυτό.

Είναι ιδιότητα του τρόπου με τον οποίο τα models παράγουν κείμενο και οι model providers εξυπηρετούν requests. Κατά το inference, το model παράγει κατανομή πιθανοτήτων για τα πιθανά επόμενα tokens και επιλέγεται ένα από αυτά — συνήθως με κάποια σκόπιμη τυχαιότητα, επειδή η επιλογή του πιο πιθανού token κάθε φορά παράγει επαναλαμβανόμενο κείμενο χαμηλότερης ποιότητας. Ένα διαφορετικό token που επιλέγεται νωρίς σε μια απάντηση αλλάζει κάθε επόμενο token, κι έτσι μία διαφορετική λέξη μπορεί να οδηγήσει σε εντελώς διαφορετική προσέγγιση. Η εξυπηρέτηση στην πλευρά του provider προσθέτει κι άλλη διακύμανση: τα requests ομαδοποιούνται σε κοινό υλικό και μικροσκοπικές διαφορές κινητής υποδιαστολής ανάμεσα στις ομάδες μπορούν να κρίνουν μια οριακή επιλογή ανάμεσα σε δύο tokens. Δεν υπάρχει ρύθμιση που μπορείτε να αλλάξετε για να εξαφανιστεί όλο αυτό.

Περιμένετε διακύμανση στα αποτελέσματα ενός agent για την ίδια εργασία. Οι περισσότερες απαντήσεις βρίσκονται μέσα σε μια εύλογη καμπύλη ποιότητας — γι’ αυτό είναι ανεκτός ο μη ντετερμινισμός — αλλά υπάρχουν και τα άκρα: κάποιες μέρες το model φαίνεται οξύ, άλλες σαν να έχει χάσει τον ειρμό. Ίδια εργασία, διαφορετικές ζαριές. Αυτό έχει δύο πρακτικές συνέπειες. Η επανάληψη είναι θεμιτή στρατηγική: μια αποτυχημένη προσπάθεια είναι μία δειγματοληψία από την κατανομή και μια νέα προσπάθεια για την ίδια εργασία μπορεί απλώς να πετύχει καλύτερα. Και η επαλήθευση έχει μεγαλύτερη σημασία απ’ ό,τι με ντετερμινιστικά εργαλεία — δεν μπορείτε να ελέγξετε μία φορά τη συμπεριφορά του agent και να βασιστείτε ότι θα επαναληφθεί, άρα τα automated checks πρέπει να εντοπίζουν τις κακές δειγματοληψίες.

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

Παράδειγμα:

«Το Claude ήταν απαίσιο σήμερα. Έβγαλαν χειρότερη έκδοση;»

«Μάλλον όχι — η έξοδος του model είναι μη ντετερμινιστική. Θα έχετε καλές και κακές μέρες στην ίδια εργασία. Δοκιμάστε ξανά αύριο πριν αρχίσετε να ψάχνετε αιτία».

Οτιδήποτε εξυπηρετεί ένα model κατά το inference. Συνήθως είναι απομακρυσμένη υπηρεσία (Anthropic, OpenAI, Google), αλλά μπορεί να είναι και τοπική — Ollama, LM Studio, llama.cpp που εκτελείται στον υπολογιστή σας. Το harness δεν εκτελεί το ίδιο το model· ζητά από έναν provider να το κάνει.

Ο provider έχει στην κατοχή του την υποδομή: τα parameters βρίσκονται στο δικό του υλικό και κάθε model provider request είναι το harness που στέλνει tokens μέσω δικτύου και λαμβάνει προβλέψεις. Έτσι ο provider είναι πηγή ολόκληρης κατηγορίας προβλημάτων που αποδίδονται λανθασμένα στο model ή στο harness — τα όρια ρυθμού, η μειωμένη χωρητικότητα και οι διακοπές λειτουργίας ανήκουν εδώ. Όταν ο agent κολλά στη μέση ενός session ή εμφανίζει σφάλμα σε κάθε turn, αξίζει να ελέγξετε πρώτα τη σελίδα κατάστασης του provider.

Ο provider ορίζει επίσης τους εμπορικούς όρους: τιμές ανά token για input και output tokens, εκπτώσεις prefix cache και ποια models είναι διαθέσιμα. Σημειώστε ότι ο provider και ο δημιουργός του model μπορεί να είναι διαφορετικές εταιρείες — τα Bedrock, Vertex και OpenRouter παρέχουν models άλλων.

Οι τοπικοί providers ανταλλάσσουν δυνατότητες με έλεγχο: τα models που χωρούν στο δικό σας υλικό είναι πολύ μικρότερα από τα κορυφαία, αλλά τίποτα δεν φεύγει από το μηχάνημα και δεν χρεώνεστε ανά token.

Παράδειγμα:

«Μπορούμε να το εκτελέσουμε offline για τον πελάτη με το απομονωμένο δίκτυο;»

«Αλλάξτε τον model provider σε τοπικό — Ollama ή llama.cpp στο μηχάνημά του. Το harness δεν ενδιαφέρεται, απλώς καλεί διαφορετικό endpoint».

Ό,τι περιβάλλει το model και το μετατρέπει σε agent: tools, system prompt, διαχείριση context-window, δικαιώματα, hooks. Τα Claude.ai και Claude Code λειτουργούν με το ίδιο model, αλλά συμπεριφέρονται διαφορετικά επειδή διαφέρουν τα harness τους.

Το ίδιο το model κάνει μόνο ένα πράγμα: δέχεται κείμενο και παράγει κείμενο. Δεν μπορεί να διαβάσει αρχείο, να εκτελέσει εντολή ή να θυμηθεί το προηγούμενο turn. Το harness παρέχει όλα αυτά. Συνθέτει το context για κάθε model provider request, εκτελεί τις tool calls που ζητά το model, επιστρέφει σε αυτό τα tool results, αποθηκεύει το ιστορικό του session, ζητά την άδειά σας πριν από επικίνδυνες ενέργειες και αποφασίζει πότε θα γίνει compact. Ο βρόχος του agent — το model προτείνει, το harness εκτελεί, η διαδικασία επαναλαμβάνεται — εκτελείται από το harness.

Αυτό έχει σημασία για τη διάγνωση. Όταν διαφέρει η συμπεριφορά ανάμεσα σε δύο προϊόντα ή από χθες ως σήμερα, συχνά η μεταβλητή δεν είναι το model αλλά το harness. Διαφορετικό system prompt, διαφορετικό σύνολο εργαλείων, αλλαγή στην προεπιλογή δικαιωμάτων ή νέα στρατηγική διαχείρισης context αλλάζουν τη συμπεριφορά χωρίς να αλλάξει το model. Σημαίνει επίσης ότι το harness περιέχει το μεγαλύτερο μέρος της διαμόρφωσής σας: τα αρχεία AGENTS.md, οι ρυθμίσεις δικαιωμάτων και τα hooks είναι όλα οδηγίες προς το harness, όχι προς το model.

Παραδείγματα: Claude Code, Cursor, Codex CLI — και το Claude.ai, που είναι harness συνομιλίας και όχι προγραμματισμού.

Παράδειγμα:

«Ίδιο model, γιατί το Claude Code επεξεργάζεται αρχεία ενώ το Claude.ai απλώς απαντά σε ερωτήσεις;»

«Διαφορετικά harness — το Claude Code έχει εργαλεία filesystem, διαφορετικό system prompt και επίπεδο δικαιωμάτων. Το model δεν είναι η μεταβλητή εδώ».

Μία διαδρομή μετ’ επιστροφής από το harness στον model provider. Το harness στέλνει το τρέχον context· ο provider επιστρέφει μία απάντηση (tool call ή τελική απάντηση). Ένα μόνο μήνυμα χρήστη μπορεί να προκαλέσει πολλά model provider requests αν ο agent καλέσει tools — κάθε tool result προκαλεί νέο αίτημα.

Κάθε αίτημα μεταφέρει τα πάντα: το system prompt, όλη τη συνομιλία μέχρι εκείνη τη στιγμή, κάθε αποτέλεσμα εργαλείου. Το model είναι stateless, άρα ο provider δεν διατηρεί τίποτα ανάμεσα στα αιτήματα — το αίτημα σαράντα ξαναστέλνει όσα έστειλε το τριάντα εννέα, συν ένα ακόμη αποτέλεσμα εργαλείου. Το prefix cache υπάρχει για να κάνει αυτή την επανάληψη οικονομικά προσιτή.

Το αίτημα είναι επίσης η μονάδα χρέωσης. Τα Input tokens, τα output tokens και οι εκπτώσεις cache υπολογίζονται ανά αίτημα, γι’ αυτό μια φαινομενικά αθώα ερώτηση μπορεί να κοστίσει απροσδόκητα πολύ: το κόστος δεν είναι ανάλογο με το μήνυμά σας, αλλά με τον αριθμό των αιτημάτων επί το μέγεθος του context που μεταφέρει το καθένα.

Αξίζει να διακρίνετε το αίτημα από το turn. Ένα turn είναι μία ανταλλαγή μαζί σας και ένα μόνο turn — «διόρθωσε το αποτυχημένο test» — εκτυλίσσεται ως αλυσίδα αιτημάτων:

Έξι αιτήματα για ένα turn — καθένα ξαναστέλνει ολόκληρο το context. Όταν αναρωτιέστε πού πήγαν τα tokens, μετρήστε τα αιτήματα, όχι τα turns.

Παράδειγμα:

«Μία ερώτηση κατανάλωσε σαράντα χιλιάδες tokens;»

«Κοιτάξτε τα tool calls — δώδεκα grep, οκτώ read, τέσσερις επεξεργασίες. Κάθε αποτέλεσμα εργαλείου ξεκινά νέο model provider request και το πρόθεμα ολόκληρου του session ξαναστέλνεται κάθε φορά».

Tokens που στέλνει το harness σε κάθε model provider request — το system prompt, το ιστορικό συνομιλίας, τα tool results, ό,τι διαβάζει το model πριν γράψει. Χρεώνονται σε χαμηλότερη τιμή από τα output tokens, επειδή είναι φθηνότερα στην επεξεργασία από τα output tokens.

Στον προγραμματισμό με AI, τα input tokens αποτελούν το μεγαλύτερο μέρος του λογαριασμού σας. Το model είναι stateless, άρα κάθε turn ξαναστέλνει ως είσοδο ολόκληρο το session: το πρώτο μήνυμά σας, κάθε απάντηση, κάθε tool result που προέκυψε από τότε. Η είσοδος του πεντηκοστού turn περιέχει τα προηγούμενα σαράντα εννέα. Ένα μόνο model provider request μπορεί να παράγει μερικές εκατοντάδες output tokens αλλά να ξαναστείλει εκατό χιλιάδες input tokens συσσωρευμένου ιστορικού.

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

Παράδειγμα:

«Ο λογαριασμός είναι υψηλός, αλλά ο agent μόλις που γράφει».

«Είναι τα input tokens — κάθε turn ξαναστέλνει ολόκληρο το session. Χωρίς prefix cache πληρώνετε ξανά το ιστορικό σε κάθε αίτημα».

Tokens που παράγει το model. Χρεώνονται ακριβότερα από τα input tokens — συνήθως περίπου πέντε φορές περισσότερο — επειδή απαιτούν περισσότερους υπολογισμούς για να παραχθούν.

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

Τα output tokens καθορίζουν επίσης τον ρυθμό ενός session. Το model διαβάζει γρήγορα την είσοδο, αλλά παράγει την έξοδο ένα token τη φορά· όταν ένα turn φαίνεται αργό, σχεδόν πάντα καθυστερεί η σύνταξη της εξόδου, όχι η ανάγνωση της εισόδου. Μεγάλη αναμονή συνήθως σημαίνει ότι έρχεται μεγάλη απάντηση.

Παράδειγμα:

«Το session refactor καταναλώνει πίστωση παρότι οι είσοδοι είναι μικρές».

«Ο agent ξαναγράφει ολόκληρα αρχεία αντί να εφαρμόζει patch. Τα output tokens κοστίζουν περίπου πέντε φορές την τιμή των input — βάλτε τον να παράγει επεξεργασίες και ο λογαριασμός θα μειωθεί».

Το αποθηκευτήριο στην πλευρά του provider που επιτρέπει σε διαδοχικά model provider requests να παραλείπουν την επανεπεξεργασία ενός κοινού προθέματος. Όταν η αρχή ενός αιτήματος ταιριάζει με την αρχή ενός πρόσφατου — ίδιο system prompt, ίδιο ιστορικό έως κάποιο σημείο — ο provider επαναχρησιμοποιεί την προηγούμενη εργασία και χρεώνει αυτά τα tokens ως φθηνότερα cache tokens.

Το cache αποδίδει επειδή τα sessions μεγαλώνουν μόνο με προσθήκες. Κάθε αίτημα ξαναστέλνει ολόκληρο το ιστορικό ως input tokens (δείτε εκείνη την καταχώριση για τον λόγο) και σε ένα συνηθισμένο session το ιστορικό αλλάζει μόνο στο τέλος — κάθε αίτημα είναι το προηγούμενο συν λίγα νέα μηνύματα. Ο provider επεξεργάζεται μία φορά το μακρύ κοινό αρχικό τμήμα, αποθηκεύει το αποτέλεσμα και συνεχίζει από εκεί που τελειώνει το πρόθεμα. Χωρίς το cache, ένα session 50 turn θα πλήρωνε την επανεπεξεργασία του πρώτου turn πενήντα φορές.

Τα caches επίσης λήγουν. Το διάστημα που μια εγγραφή παραμένει ενεργή διαφέρει ανά model provider — συνήθως λεπτά, όχι ώρες. Αν αφήσετε ένα session ανενεργό πέρα από αυτό το διάστημα, το επόμενο αίτημα ξαναδημιουργεί το πρόθεμα στην πλήρη τιμή μία φορά, πριν ξαναρχίσει το caching. Αυτό αφορά κυρίως όσους αναπτύσσουν harness· ως χρήστης, βλέπετε ότι τα αιτήματα μετά από μεγάλη παύση κοστίζουν περισσότερο από τα προηγούμενα.

Παράδειγμα:

«Γιατί εκτοξεύτηκε ο λογαριασμός στη μέση του session;»

«Το harness άρχισε να εισάγει την τρέχουσα ώρα στο system prompt σε κάθε turn. Το prefix cache σπάει στο πρώτο token που άλλαξε, οπότε κάθε επόμενο αίτημα χρεώθηκε στην πλήρη τιμή».

Input tokens που έχει αποθηκεύσει στην cache ο provider από προηγούμενο model provider request, ώστε να μην χρειαστεί να τα επεξεργαστεί ξανά. Όταν διαδοχικά requests μοιράζονται πρόθεμα, ο provider επαναχρησιμοποιεί την εργασία μέσω του prefix cache και χρεώνει το τμήμα της cache με πολύ χαμηλότερη τιμή. Είναι ο μοχλός που κάνει προσιτά τα μεγάλα sessions — χωρίς αυτόν, κάθε turn θα χρέωνε ξανά ολόκληρο το ιστορικό.

Αυτό έχει σημασία λόγω του τρόπου χρέωσης των sessions. Το model είναι stateless, άρα κάθε αίτημα ξαναστέλνει όλη τη συνομιλία — το system prompt, κάθε μήνυμα, κάθε tool result — ως input tokens. Στο πεντηκοστό turn, κάθε αίτημα μεταφέρει ιστορικό πενήντα turns και θα πληρώνατε πλήρη τιμή για όλο του το περιεχόμενο, κάθε φορά. Η cache αλλάζει τα μαθηματικά: για tokens που έχει ήδη επεξεργαστεί ο provider σε πανομοιότυπο πρόθεμα πληρώνετε ως cache tokens, συχνά το ένα δέκατο της τιμής εισόδου ή και λιγότερο. Σε ένα μεγάλο session, τα περισσότερα από όσα στέλνετε είναι cache tokens και ο λογαριασμός παραμένει λογικός.

Το παράδειγμα δείχνει πότε αποθηκεύονται tokens στην cache και πότε όχι. Κάθε γράμμα παριστάνει ένα τμήμα του περιεχομένου της συνομιλίας· κάθε αίτημα στέλνει τη συνομιλία μέχρι εκείνη τη στιγμή:

Η cache είναι εύθραυστη με συγκεκριμένο τρόπο: αντιστοιχίζει ακριβή προθέματα. Αν αλλάξει οτιδήποτε νωρίτερα στη συνομιλία — το harness αναδιατάξει περιεχόμενο, ενημερωθεί μια χρονοσήμανση, αλλάξει η αναπαράσταση ενός αρχείου — η cache δεν ταιριάζει από εκείνο το σημείο και μετά και όλα τα επόμενα χρεώνονται στην πλήρη τιμή input. Οι caches επίσης λήγουν ύστερα από λίγα λεπτά αδράνειας, οπότε ένα session που συνεχίζεται μετά από μεγάλο διάλειμμα πληρώνει μία φορά ξανά όλο το ιστορικό του. Όταν το κόστος ενός session αυξηθεί χωρίς προφανή αιτία, συγκρίνετε τα cache tokens με τα input tokens στην αναφορά χρήσης — εκεί εμφανίζεται πρώτα η αστοχία της cache.

Παράδειγμα:

«Το κόστος των μεγάλων sessions είναι αβάσταχτο — οκτώ δολάρια για ένα refactor».

«Ελέγξτε τα cache tokens. Αν το harness αναδιατάσσει το system prompt ή τα αρχεία μεταξύ των turns, σπάει το πρόθεμα και πληρώνετε ξανά την πλήρη τιμή εισόδου σε κάθε αίτημα».

Δεν μεταφέρει καμία πληροφορία στο μέλλον. Το model είναι stateless μεταξύ model provider requests — κάθε αίτημα ξαναστέλνει ολόκληρο το context window, επειδή το model δεν μπορεί να δει τίποτε άλλο. Από προεπιλογή, ένας agent είναι stateless μεταξύ sessions: ένα νέο session ξεκινά άδειο, χωρίς ίχνος προηγούμενων sessions. Αντίθετο του stateful.

Το ίδιο το model είναι μόνιμα stateless: τα parameters του παραμένουν παγωμένα μετά το training και τίποτα από όσα κάνετε κατά το inference δεν τα αλλάζει. Το model δεν μαθαίνει από τις διορθώσεις σας, δεν θυμάται ότι του είπατε το ίδιο πράγμα χθες και δεν σας γνωρίζει καλύτερα — όσο κι αν δίνει αυτή την εντύπωση η συνομιλία. Η αίσθηση συνέχειας μέσα σε ένα session κατασκευάζεται από το harness, που διατηρεί το transcript και το ξαναστέλνει σε κάθε αίτημα. Το model δεν θυμάται τη συνομιλία· τη διαβάζει ξανά.

Η πρακτική συνέπεια: αν θέλετε κάτι να διατηρηθεί μεταξύ sessions, πρέπει να το γράψετε κάπου από όπου θα το ξαναδιαβάσει ο agent. Αυτός είναι ο ρόλος των αρχείων AGENTS.md, των memory systems και των handoff artifacts — αρχεία που φορτώνονται στο context μελλοντικών sessions και υποκαθιστούν τη μνήμη που δεν έχει το model. Όταν ο agent επαναλαμβάνει ένα λάθος που έχετε ήδη διορθώσει, το ερώτημα δεν είναι γιατί δεν έμαθε — δεν μπορεί — αλλά πού πρέπει να καταγραφεί η διόρθωση, ώστε να τη διαβάζει κάθε μελλοντικό session.

Παράδειγμα:

«Γιατί ξεχνά τη σύμβαση κάθε φορά που κάνω clear;»

«Το model είναι stateless — το νέο session ξεκινά άδειο. Αν θέλετε να μεταφερθεί, γράψτε τη στο AGENTS.md ή σε αρχείο μνήμης που φορτώνει το harness στην αρχή του session».

Οι σχετικές πληροφορίες στις οποίες έχει πρόσβαση ο agent αυτή τη στιγμή. Το αφηρημένο ουσιαστικό — όχι η ακατέργαστη είσοδος που βλέπει το model (αυτό είναι το context window), ούτε το ιστορικό που εκτυλίσσεται (αυτό είναι το session), αλλά όσα γνωρίζει ο agent και έχουν σχέση με την εργασία. «Φορτώνω κάτι στο context» σημαίνει ότι το κάνω μέρος αυτού του συνόλου· «μηχανική context» είναι η πρακτική επιμέλειάς του.

Οι τρεις όροι διακρίνονται καθαρά:

Η διάκριση έχει σημασία επειδή το context μετρά ποιότητα, όχι ποσότητα. Ένα context window μπορεί να είναι σχεδόν γεμάτο, ενώ το context παραμένει φτωχό — χιλιάδες tokens παλιών αποτελεσμάτων εργαλείων, κανένα σχετικό με την εργασία. Μπορεί επίσης να είναι σχεδόν άδειο, αλλά το context εξαιρετικό: ο ένας ορισμός τύπου από τον οποίο εξαρτάται η εργασία.

Οι περισσότερες καθημερινές αποτυχίες ανάγονται στο context. Όταν ο agent επινοεί API, αντιφάσκει με απόφαση ή μαντεύει ένα schema, το πρώτο ερώτημα είναι τι υπήρχε στο context εκείνη τη στιγμή — συνήθως η σχετική πληροφορία δεν είχε φορτωθεί ή είχε θαφτεί κάτω από την attention degradation. Η λύση είναι η επιμέλεια: φορτώστε όσα χρειάζεται η εργασία, αποκλείστε όσα δεν χρειάζεται.

Παράδειγμα:

«Συνεχίζει να επινοεί πεδία που δεν υπάρχουν στον τύπο».

«Το αρχείο τύπου δεν βρίσκεται στο context — διαβάζει τα call sites και μαντεύει. Διαβάστε πρώτα τον ορισμό».

Ό,τι βλέπει το model σε κάθε model provider request. Είναι πεπερασμένο, εξαρτάται από το model και αποτελεί τη μοναδική επιφάνεια μέσω της οποίας αντιλαμβάνεται οτιδήποτε το model.

Είναι μία ακολουθία tokens: το system prompt, η συνομιλία μέχρι τώρα, κάθε tool result που έχει επιστρέψει το harness. Αν κάτι υπάρχει σε αυτή την ακολουθία, το model μπορεί να το χρησιμοποιήσει· αν δεν υπάρχει, το model δεν γνωρίζει ότι υπάρχει — ούτε το codebase σας, ούτε το αρχείο που επεξεργαστήκατε χθες, ούτε η οδηγία που δώσατε πριν από τρία sessions. Οτιδήποτε βρίσκεται έξω από το παράθυρο πρέπει να εισαχθεί, συνήθως μέσω tool call, προτού επηρεάσει κάτι.

Η πεπερασμένη χωρητικότητα σημαίνει ότι γεμίζει. Κάθε turn προσθέτει περισσότερα — τα μηνύματά σας, τις απαντήσεις του model, τα tool results — και ένα μεγάλο session τελικά φτάνει στο όριο, αναγκάζοντας σε compaction ή clearing. Σημαίνει επίσης ότι όλα μέσα στο παράθυρο ανταγωνίζονται: κάθε token που φορτώνετε αφήνει ένα λιγότερο διαθέσιμο για τα υπόλοιπα, ενώ περιεχόμενο που δεν χρειαζόταν και πάλι καταλαμβάνει το attention του model. Η πρακτική στάση είναι να αντιμετωπίζετε το παράθυρο ως προϋπολογισμό — φορτώστε όσα χρειάζεται η εργασία και αφήστε τα υπόλοιπα έξω.

Αποφύγετε: «memory» — το context window είναι ενεργή κατάσταση εργασίας και δεν διατηρείται μεταξύ sessions. Η Memory είναι ξεχωριστή έννοια που προστίθεται πάνω από αυτό.

Παράδειγμα:

«Μπορώ να επικολλήσω όλο το monorepo στο prompt;»

«Το context window έχει 200k tokens — ίσως το ένα πέμπτο του repo. Επιλέξτε τα αρχεία που αγγίζει η εργασία και αφήστε τα υπόλοιπα έξω· φορτώστε τα μέσω tool call μόνο αν χρειαστεί».

Μεταφέρει πληροφορίες στο μέλλον. Ένα session διατηρεί state ανάμεσα στα turns — το context συσσωρεύεται όσο εκτελείται το session, γι’ αυτό τα μεγάλα sessions παρασύρονται στη dumb zone. Ένας agent μπορεί να διατηρεί state σε πολλά sessions αν προστεθεί ένα memory system που αποθηκεύει πληροφορίες στο environment και τις επαναφορτώνει στην αρχή μελλοντικών sessions. Το model δεν διατηρεί ποτέ state· κάθε φαινομενική συνέχεια οφείλεται στο harness που τροφοδοτεί ξανά context. Αντίθετο του stateless.

Πού βρίσκεται το state σε κάθε επίπεδο:

Το state κάθε επιπέδου δημιουργείται με νέα ανάγνωση κάποιου στοιχείου που αποθηκεύτηκε ένα επίπεδο χαμηλότερα: το session φαίνεται συνεχές επειδή το harness στέλνει ξανά το ιστορικό μηνυμάτων στο stateless model, και ο agent θυμάται μεταξύ sessions επειδή το harness επαναφορτώνει αρχεία από το environment. Δεν αποθηκεύεται ποτέ state μέσα στο ίδιο το model.

Το state δεν είναι πάντα επιθυμητό. Ό,τι μεταφέρεται επηρεάζει όσα ακολουθούν, άρα και μια λανθασμένη παραδοχή στην αρχή ενός session μεταφέρεται επίσης. Το Clearing είναι η σκόπιμη απόρριψη του state του session και η επανεκκίνηση με βάση όσα έχουν καταγραφεί.

Παράδειγμα:

«Θυμήθηκε τις προτιμήσεις μου από χθες — σημαίνει ότι τις έμαθε το model;»

«Όχι, ο agent διατηρεί state επειδή το harness τις έγραψε σε αρχείο μνήμης και το επαναφόρτωσε στην αρχή του session. Το ίδιο το model δεν είδε τίποτα από χθες».

Ένα model με harness, tools, system prompt και context window, που ανταλλάσσει turns με έναν χρήστη. Το Claude Code είναι agent. Το Cursor είναι agent. Το Claude.ai είναι agent. Ο agent είναι αυτό με το οποίο πράγματι μιλάτε — το model εν δράσει, ρυθμισμένο για έναν σκοπό.

Σε αντίθεση με τους περισσότερους όρους αυτού του λεξικού, το «agent» δεν ονομάζει κάποιο μηχανικό εξάρτημα. Το model είναι ένα αρχείο parameters· το harness είναι λογισμικό που μπορείτε να δείτε. Ο agent δεν είναι ούτε το ένα ούτε το άλλο — είναι η μονάδα με την οποία συνομιλείτε. Οι άνθρωποι ανθρωπομορφοποιούν συνεχώς το AI, και ο agent είναι η ανθρωπομορφοποιημένη μονάδα: αυτό στο οποίο αναθέτετε κάτι, αυτό που διαβάζει το μήνυμά σας και απαντά, το «αυτό» στη φράση «αυτό χάλασε ξανά το build». Όταν λέτε ότι ο agent έκανε κάτι, εννοείτε το σύνολο model και harness, αλλά απευθύνεστε στον συνδυασμό σαν να ήταν ένας ενιαίος δρων.

Η ιδέα είναι παλιότερη από το σημερινό κύμα AI. Οι software agents — προγράμματα στα οποία αναθέτετε έναν στόχο και ενεργούν για λογαριασμό σας — αποτελούν έννοια από τότε που υπάρχει η AI.

Αποφύγετε: «the AI», «the bot» (είναι υπερβολικά αόριστα — κρύβουν αν εννοείτε τα parameters ή το πράγμα που έχει εξοπλιστεί με harness).

Παράδειγμα:

«Ποιον agent χρησιμοποιείς για τη μετεγκατάσταση;»

«Τοπικά Claude Code, Cursor για τη δουλειά στο UI — ίδιο model από κάτω, διαφορετικά harness».

Οι οδηγίες που το harness προσθέτει στην αρχή κάθε model provider request — η πάγια ενημέρωση του agent: ποιος είναι, πώς να συμπεριφέρεται, ποια tools μπορεί να καλεί, ποιες συμβάσεις να ακολουθεί. Συνήθως παραμένει σταθερό σε όλη τη διάρκεια ενός session.

Το system prompt γράφεται από τον κατασκευαστή του harness, όχι από εσάς, και στα harness προγραμματισμού είναι μεγάλο — συχνά δεκάδες χιλιάδες tokens με κανόνες συμπεριφοράς, περιγραφές εργαλείων και χειρισμό οριακών περιπτώσεων, όλα χρεώνονται ως input tokens σε κάθε turn. Μαζί του μεταφέρονται και οι δικές σας πάγιες οδηγίες: αρχεία όπως το AGENTS.md φορτώνονται δίπλα στο system prompt στην αρχή του session, ώστε το model να διαβάζει μαζί τις οδηγίες του προμηθευτή και τις δικές σας προτού δει το μήνυμά σας.

Επειδή είναι πανομοιότυπο σε κάθε αίτημα, αποτελεί την αρχή του prefix cache — κι αυτός είναι ένας από τους λόγους που τα harness το κρατούν σταθερό για ολόκληρο το session αντί να το αλλάζουν κατά τη διάρκειά του.

Τα models εκπαιδεύονται να δίνουν προτεραιότητα στο system prompt έναντι των μηνυμάτων του χρήστη. Άρα όταν ένας agent επιμένει σε σύμβαση που δεν ζητήσατε ποτέ ή μορφοποιεί την έξοδο με τρόπο από τον οποίο δεν μπορείτε να τον μετακινήσετε, συνήθως ακολουθεί το system prompt — και το μήνυμά σας χάνει τη διαφωνία. Ορισμένα harness επιδέχονται προσαρμογές: σας δίνουν πλήρη πρόσβαση στο system prompt, ώστε να διαβάσετε τι ακριβώς λένε στον agent και να το αλλάξετε.

Παράδειγμα:

«Δύο harness, ίδιο model, εντελώς διαφορετική συμπεριφορά στο ίδιο prompt».

«Διαφορετικά system prompts. Το ένα είναι ρυθμισμένο για σύντομες επεξεργασίες κώδικα, το άλλο για επεξηγήσεις — εκεί βρίσκεται η απόκλιση, πριν φτάσει καν το μήνυμά σας».

Ένας οριοθετημένος κύκλος αλληλεπίδρασης με έναν agent. Ξεκινά κενός, συσσωρεύει μηνύματα, tool results και αρχεία που διαβάστηκαν και τελειώνει όταν γίνει cleared, κλείσει ή compacted σε νέο session. Το session είναι αυτό που γεμίζει το context window: αν το context window είναι το κουτί, το session είναι τα πράγματα που το γεμίζουν σταδιακά. Εργασία πολύ μεγάλη για ένα context window πρέπει να χωριστεί σε πολλά sessions.

Το ιστορικό μηνυμάτων του session είναι η λειτουργική μνήμη του agent. Το model είναι stateless, άρα όλα όσα φαίνεται να θυμάται — τι ζητήσατε, τι έδειξαν τα tests, τι αποφάσισε πριν από τρία turns — βρίσκονται στο ιστορικό μηνυμάτων και ξαναστέλνονται με κάθε model provider request. Ό,τι δεν περιλαμβάνεται στο session δεν υπάρχει για τον agent.

Αυτή η μνήμη τελειώνει μαζί με το session. Ένα νέο session ξεκινά από το μηδέν: ο agent που ήξερε καλά το codebase σας στο τέλος του χθεσινού session δεν γνωρίζει τίποτα γι’ αυτό σήμερα το πρωί. Αυτό που επιβιώνει είναι το filesystem — αρχεία που γράφτηκαν σε ένα session μπορούν να διαβαστούν από το επόμενο και σε αυτό βασίζονται τα handoffs, τα memory systems και το AGENTS.md.

Εσείς επιλέγετε πού τελειώνει ένα session. Ό,τι συμβαίνει μέσα του επηρεάζει κάθε επόμενο turn, οπότε άσχετες εργασίες στο ίδιο session αφήνουν κατάλοιπα που επηρεάζουν την επόμενη απάντηση. Μία εργασία ανά session διατηρεί σχετικό το context· η ολοκλήρωση μιας εργασίας είναι φυσικό σημείο για εκκαθάριση.

Παράδειγμα:

«Πόσο μπορεί να διαρκέσει ένα session πριν αρχίσει να καταρρέει;»

«Εξαρτάται από τη δουλειά — ένα εστιασμένο refactor παραμένει οξύ περισσότερο από μια ανοικτή έρευνα. Όταν διογκωθεί το session, κάνε hand off ή compact· μην επιμένεις».

Ένα μήνυμα χρήστη μαζί με όλα όσα κάνει ο agent ως απάντηση, μέχρι να επιστρέψει τον λόγο στον χρήστη. Περιλαμβάνει ένα ή περισσότερα model provider requests — πολλά, αν ο agent καλέσει tools. Μια διευκρινιστική ερώτηση κλείνει το turn· η απάντησή σας ανοίγει το επόμενο. Η ιεραρχία είναι session > Turn > Model provider request.

Αυτό που κάνει το turn άξιο ξεχωριστής ονομασίας είναι ότι τη διάρκειά του την αποφασίζει ο agent, όχι εσείς. Παραδίδετε ένα μήνυμα· ο agent αποφασίζει πόσα tool calls θα αλυσιδώσει πριν επιστρέψει. Ένα turn μπορεί να είναι απάντηση μίας πρότασης ή είκοσι λεπτά ανάγνωσης, επεξεργασίας και εκτέλεσης tests. Πρόκειται για το ίδιο χαρακτηριστικό από δύο πλευρές: τα μεγάλα turns επιτρέπουν την εργασία AFK, αλλά είναι και τα σημεία όπου τα πράγματα μπορεί να πάνε στραβά χωρίς επίβλεψη — όταν επιστρέψει ο λόγος σε εσάς, ο agent μπορεί να έχει απομακρυνθεί πολύ από αυτό που εννοούσατε.

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

Παράδειγμα:

«Ένα turn πήρε δύο λεπτά;»

«Έκανε δεκατέσσερα tool calls μέσα σε εκείνο το turn — καθένα είναι ξεχωριστό model provider request. Η καθυστέρηση συσσωρεύεται πριν επιστρέψει τελικά ο agent τον λόγο».

Ο κόσμος πάνω στον οποίο ενεργεί ο agent — οτιδήποτε βρίσκεται έξω από το harness, το οποίο ο agent αντιλαμβάνεται μέσω tool results και αλλάζει μέσω tool calls. Το harness εκτελεί τον agent· το environment είναι μέσα στο οποίο εργάζεται. Ένα αρχείο όπως το `AGENTS.md` βρίσκεται στο environment· το harness το φορτώνει στο context window. Το filesystem είναι ο συνηθέστερος τύπος environment, όχι όμως ο μοναδικός (βάση δεδομένων, απομακρυσμένο API και συνεδρία browser μπορούν επίσης να είναι environments).

Ο agent βλέπει το environment μόνο όταν κοιτάζει. Ό,τι γνωρίζει γι’ αυτό έφτασε μέσω tool result, επομένως η εικόνα του είναι συλλογή στιγμιοτύπων, καθένα ακριβές τη στιγμή της λήψης του. Αν αλλάξει ένα αρχείο αφού το διαβάσει ο agent — το επεξεργαστείτε χειροκίνητα ή το αναδημιουργήσει ένα βήμα build — συνεχίζει να συλλογίζεται βάσει του παλιού αντιγράφου μέχρι κάτι να τον παρακινήσει να το ξαναδιαβάσει. Όταν ο agent περιγράφει με σιγουριά ένα αρχείο που δεν μοιάζει πλέον έτσι, συνήθως αυτό συμβαίνει: το environment μετακινήθηκε, το στιγμιότυπο όχι.

Το environment είναι επίσης το επίπεδο που διατηρείται — το μόνο που είναι πάντα stateful. Το context ενός session χάνεται όταν τελειώσει το session, αλλά αρχεία που γράφτηκαν στο environment παραμένουν για να τα διαβάσει το επόμενο session — σε αυτό βασίζονται τα memory systems, τα handoff artifacts και το `AGENTS.md`. Οτιδήποτε πρέπει να γνωρίζει ακόμη ο agent αύριο πρέπει να καταλήξει στο environment.

Εσείς αποφασίζετε πόσο μεγάλο είναι το environment. Ένα sandbox το περιορίζει, μειώνοντας όσα μπορεί να προσεγγίσει ο agent· η προσθήκη ενός tool το επεκτείνει, δίνοντάς του πρόσβαση σε βάση δεδομένων ή API. Ό,τι βρίσκεται μέσα στα όρια είναι αυτό που μπορεί να αντιληφθεί και να αλλάξει ο agent· ό,τι είναι έξω δεν υπάρχει για εκείνον. Το πόσο καλά έχει ρυθμιστεί το environment ώστε να υποστηρίζει την εργασία του agent είναι το AX του codebase.

Αποφύγετε: να χρησιμοποιείτε «environment» για το runtime ή το ίδιο το harness — το harness είναι το περίβλημα, το environment είναι ο χώρος εργασίας.

Παράδειγμα:

«Ο agent δεν βλέπει το schema της βάσης staging».

«Συνδέστε το στο environment — δώστε του ένα εργαλείο `psql` με πρόσβαση μόνο για ανάγνωση στο staging. Το harness λειτουργεί σωστά, απλώς δεν έχει τίποτα πάνω στο οποίο να δράσει».

Ένα δέντρο αρχείων και καταλόγων από το οποίο ο agent διαβάζει, γράφει και μέσα στο οποίο εκτελεί εντολές — ο προεπιλεγμένος τύπος environment για έναν agent προγραμματισμού. Τα AGENTS.md, skills, ο πηγαίος κώδικας, τα scripts build και οι ρυθμίσεις tool βρίσκονται όλα σε ένα filesystem. Όταν ένα harness «ξεκινά στο έργο σας», κατευθύνει τον agent σε ένα filesystem.

Ο agent το αγγίζει μόνο μέσω tool calls — διαβάζοντας ένα αρχείο, γράφοντας ένα, εκτελώντας μια εντολή κελύφους. Τίποτα στον δίσκο δεν βρίσκεται στο context window μέχρι να το φορτώσει ένα tool call, κι αυτό επιτρέπει στον agent να εργάζεται σε repo πολύ μεγαλύτερο από το παράθυρο: το filesystem περιέχει τα πάντα, ενώ το context μόνο όσα έχει διαβάσει η τρέχουσα εργασία. Ορισμένα harness φορτώνουν από προεπιλογή στο context window τα ονόματα αρχείων του τρέχοντος καταλόγου — όχι το περιεχόμενο, μόνο το δέντρο — που λειτουργεί ως context pointers: ο agent βλέπει τι υπάρχει και διαβάζει τα αρχεία που χρειάζεται.

Και είναι κοινόχρηστο με εσάς. Τα αρχεία που επεξεργάζεται ο agent είναι τα ίδια που ανοίγετε στον editor σας και συγκρίνετε με diff στο git — το filesystem είναι ο κοινός χώρος εργασίας όπου εξετάζετε όσα έκανε ο agent.

Παράδειγμα:

«Γιατί δεν εντοπίζει το AGENTS.md μου;»

«Εκτελείται σε διαφορετικό filesystem — το sandbox προσάρτησε τον γονικό κατάλογο, όχι τη ρίζα του έργου. Αλλάξτε τη διαδρομή του harness».

Μια λειτουργία που το harness διαθέτει στον agent για να την καλέσει — Read, Write, Bash, Search. Τα εργαλεία είναι ο τρόπος με τον οποίο ένας agent αντιλαμβάνεται και επηρεάζει το environment: δεν μπορεί να δει το environment παρά μόνο μέσω tool results και δεν μπορεί να το αλλάξει παρά μόνο μέσω tool calls. Κάθε κλήση εργαλείου κοστίζει ένα επιπλέον model provider request, αφού το αποτέλεσμα πρέπει να επιστρέψει στο model προτού αποφασίσει τι θα κάνει στη συνέχεια.

Εργαλεία που περιλαμβάνουν συνήθως οι agents προγραμματισμού:

Ένα εργαλείο ορίζεται από τρία στοιχεία: όνομα, περιγραφή της λειτουργίας του και σχήμα παραμέτρων. Το harness στέλνει αυτούς τους ορισμούς στο model σε κάθε αίτημα, και το model επιλέγει εργαλείο όπως παράγει οτιδήποτε άλλο — γράφοντας tokens, εδώ ως δομημένη κλήση με ορίσματα. Το ίδιο το model δεν εκτελεί τίποτα· το harness διαβάζει την κλήση, εκτελεί τη συνάρτηση και στέλνει πίσω το αποτέλεσμα.

Η λίστα εργαλείων καθορίζει τι μπορεί να κάνει ο agent. Ένα ικανό model με περιορισμένο σύνολο εργαλείων είναι περιορισμένος agent: θα περνά τα πάντα μέσα από όσα διαθέτει, γι’ αυτό οι agents βασίζονται τόσο πολύ στο Bash — ένα εργαλείο κελύφους φτάνει στο μεγαλύτερο μέρος του συστήματος. Για να δώσετε καθαρά μια δυνατότητα στον agent, προσθέστε ένα εργαλείο γι’ αυτήν· το MCP είναι το πρότυπο σύνδεσης εργαλείων έξω από το harness.

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

Παράδειγμα:

«Μπορεί ο agent να κάνει απευθείας ερωτήματα στο staging;»

«Προσθέστε στο harness ένα εργαλείο `psql`, με πρόσβαση μόνο για ανάγνωση στο staging. Χωρίς εργαλείο γι’ αυτό, ο agent δεν βλέπει τίποτα έξω από το filesystem».

Η έξοδος του model που κατονομάζει ένα tool και τα ορίσματά του — απλώς δομημένο κείμενο. Δεν κάνει τίποτα από μόνο του· το harness πρέπει να τη διαβάσει και να την εκτελέσει. Παράγεται από το model σε ένα model provider request.

Ο κύκλος ζωής ενός tool call:

Ένα turn εργασίας από agent συνήθως αποτελείται από πολλές τέτοιες διαδρομές μετ’ επιστροφής, αλυσιδωμένες μεταξύ τους.

Επειδή η κλήση παράγεται με next-token prediction, όπως καθετί άλλο, μπορεί να είναι λανθασμένη όπως κάθε έξοδος model: διαδρομή που δεν υπάρχει, flag που δεν υποστηρίζει η εντολή, ορίσματα εύλογα αντί για σωστά. Το harness εκτελεί ό,τι γράφτηκε, όχι ό,τι εννοούνταν — μια λανθασμένα πληκτρολογημένη διαδρομή δεν αποτυγχάνει με ομαλό τρόπο· επεξεργάζεται λάθος αρχείο.

Παράδειγμα:

«Είπε ότι έτρεξε τα tests, αλλά οι χρονοσημάνσεις των αρχείων δεν άλλαξαν».

«Κοιτάξτε το transcript — εξέπεμψε πράγματι tool call ή απλώς περιέγραψε ότι τα έτρεξε; Το model παράγει την κλήση, αλλά αν δεν την εκτέλεσε το harness, δεν συνέβη τίποτα».

Ό,τι επιστρέφει το harness αφού εκτελέσει ένα tool call — τα περιεχόμενα του αρχείου, η έξοδος της εντολής, το σφάλμα. Η μόνη εικόνα που έχει ο agent για το environment. Επιστρέφει στο model στο επόμενο model provider request, όπου το model αποφασίζει τι θα κάνει στη συνέχεια. Το tool call και το tool result είναι τα δύο άκρα της ίδιας ανταλλαγής, και τα δύο μέσα σε ένα turn.

Ο κύκλος ζωής ενός tool result:

Το αποτέλεσμα παραμένει στο context για το υπόλοιπο session. Τα tool results αποτελούν συνήθως το μεγαλύτερο μέρος του context ενός session προγραμματισμού: κάθε αρχείο που διαβάζεται, κάθε test που εκτελείται, κάθε αναζήτηση καταλήγει ολόκληρη εκεί και συνεχίζει να καταλαμβάνει tokens πολύ αφότου πάψει να είναι χρήσιμη. Μερικά μεγάλα αποτελέσματα — ένα εκτενές log tests, ένα αρχείο που διαβάστηκε ολόκληρο — μπορούν να ωθήσουν ένα session στο όριο του context window ταχύτερα από την ίδια τη συνομιλία.

Επειδή το αποτέλεσμα είναι ό,τι βλέπει το model, δεν έχει τρόπο να ελέγξει το environment πίσω από αυτό. Αν η έξοδος περικόπηκε, η εντολή απέτυχε σιωπηρά ή το harness επέστρεψε σφάλμα αντί για το περιεχόμενο, το model συλλογίζεται βάσει όσων του δόθηκαν. Όταν η εικόνα του agent για το σύστημά σας φαίνεται λανθασμένη, τα tool results είναι το σημείο που πρέπει να ελέγξετε: κάπου στο transcript υπάρχει αποτέλεσμα που λέει κάτι διαφορετικό από αυτό που γνωρίζετε.

Παράδειγμα:

«Συλλογίζεται για το αρχείο σαν να είναι άδειο».

«Το tool result επέστρεψε άρνηση άδειας, όχι τα περιεχόμενα. Το model είδε μόνο τη συμβολοσειρά του σφάλματος — δεν έχει άλλον τρόπο να δει το αρχείο».

Model Context Protocol. Ένα πρωτόκολλο για τη σύνδεση εξωτερικών διακομιστών εργαλείων σε ένα harness — ο τρόπος με τον οποίο ένας agent αποκτά tools πέρα από όσα περιλαμβάνει το harness. Ο agent δεν «καλεί MCP» ποτέ· καλεί ένα εργαλείο και απλώς συμβαίνει το harness να έχει πάρει αυτό το εργαλείο από έναν MCP server. Παρέχει επίσης resources (δεδομένα μόνο για ανάγνωση) και prompts (επαναχρησιμοποιήσιμα πρότυπα), αλλά κύρια χρήση του είναι η παροχή εργαλείων.

Το πρωτόκολλο λύνει ένα πρόβλημα ενσωμάτωσης. Χωρίς πρότυπο, κάθε harness θα χρειαζόταν τη δική του ενσωμάτωση Linear, τη δική του ενσωμάτωση Slack, τη δική του ενσωμάτωση βάσης δεδομένων — καθεμία γραμμένη και συντηρούμενη ξεχωριστά. Με το MCP, η ενσωμάτωση γράφεται μία φορά ως server και μπορεί να χρησιμοποιηθεί από κάθε harness συμβατό με MCP. Το harness συνδέεται στον server, εκείνος ανακοινώνει ποια εργαλεία προσφέρει και αυτά γίνονται διαθέσιμα στον agent μαζί με τα ενσωματωμένα εργαλεία.

Το κόστος καταβάλλεται σε context. Κάθε εργαλείο που ανακοινώνει ένας server εισάγεται ως ορισμός — όνομα, περιγραφή, σχήμα παραμέτρων — και το model μπορεί να καλεί μόνο εργαλεία για τα οποία γνωρίζει. Η απλοϊκή προσέγγιση φορτώνει εξαρχής κάθε ορισμό στο context window: εγκαταστήστε μερικούς γενναιόδωρους servers και ένα session ξεκινά με χιλιάδες tokens σε σχήματα εργαλείων πριν καν πληκτρολογήσετε οτιδήποτε, ξοδεύοντας attention budget σε εργαλεία που η εργασία δεν θα χρησιμοποιήσει ποτέ.

Πολλά harness μετριάζουν πλέον αυτό το κόστος με αναζήτηση εργαλείων: αντί για τους πλήρεις ορισμούς, το context διατηρεί έναν context pointer προς τα διαθέσιμα εργαλεία — ο agent αναζητά εργαλείο με βάση το όνομα ή τον σκοπό του και φορτώνει τον ορισμό μόνο όταν τον χρειάζεται. Αν το harness σας δεν το υποστηρίζει, το αρχικό κόστος παραμένει και αξίζει να ενεργοποιείτε μόνο τους servers που χρειάζεται πράγματι ένα έργο.

Παράδειγμα:

«Ο agent πρέπει να διαβάζει εισιτήρια από το Linear».

«Ρυθμίστε το harness ώστε να χρησιμοποιεί τον Linear MCP server — εκθέτει το Linear API ως εργαλεία που μπορεί να καλεί ο agent. Έτσι δεν χρειάζεται να γράψετε προσαρμοσμένα wrappers εργαλείων».

Ό,τι εμφανίζει το harness στον χρήστη προτού εκτελέσει ένα tool call που δεν έχει προεγκριθεί. Το model παράγει ένα tool call· αντί να το εκτελέσει αμέσως, το harness σταματά και ζητά άδεια. Αν εγκρίνετε, εκτελείται· αν αρνηθείτε, το harness επιστρέφει την άρνηση στο model ως tool result. Αυτός είναι ο μηχανισμός με τον οποίο ένα harness βάζει άνθρωπο στον loop για επικίνδυνες ή ευαίσθητες ενέργειες.

Ο κύκλος ζωής ενός permission request:

Η άρνηση ενός αιτήματος κατευθύνει τον agent. Το model διαβάζει την άρνηση όπως κάθε άλλο tool result και αντιδρά — δοκιμάζει διαφορετική προσέγγιση ή ρωτά τι προτιμάτε. Τα περισσότερα harness επιτρέπουν να επισυνάψετε μήνυμα στην άρνηση, μετατρέποντάς την σε σημείο καθοδήγησης: το «όχι έτσι, χρησιμοποίησε το script μετεγκατάστασης» φτάνει ακριβώς όταν το model αποφασίζει τι θα κάνει στη συνέχεια.

Το κόστος είναι ότι κάθε αίτημα σας αναγκάζει να περιμένετε. Ο agent παραμένει μπλοκαρισμένος μέχρι να απαντήσετε — είναι εντάξει όταν παρακολουθείτε, αλλά πρόβλημα όταν λείπετε· ένας agent που ενεργοποιεί συνεχώς αιτήματα δεν μπορεί να αφεθεί να δουλεύει AFK. Το permission mode είναι ο ρυθμιστής: ποιες κλήσεις εκτελούνται ελεύθερα και ποιες ζητούν πρώτα έγκριση, ιδανικά με ένα sandbox που επιτρέπει με ασφάλεια τη διεύρυνση των ελεύθερων ενεργειών.

Παράδειγμα:

«Έχει μπλοκαριστεί δέκα λεπτά σε αίτημα άδειας — ήμουν σε σύσκεψη».

«Αυτό είναι το κόστος του ανθρώπου στον βρόχο. Προεγκρίνετε τα ασφαλή tools, ώστε το αίτημα να εμφανίζεται μόνο για τις πραγματικά επικίνδυνες κλήσεις».

Το τμήμα του agent mode που ελέγχει τα δικαιώματα — ποιες tool calls προκαλούν permission request και ποιες εκτελούνται αυτόματα. Αυτός ήταν ο αρχικός σκοπός των συστημάτων λειτουργιών, πριν τα harnesses αρχίσουν να προσθέτουν και οδηγίες συμπεριφοράς.

Τα harness προσφέρουν κλίμακα αυτών των λειτουργιών:

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

Η χαλαρή άκρη του φάσματος δικαιολογείται περισσότερο μέσα σε sandbox, όπου περιορίζεται η ακτίνα δράσης ενός κακού tool call. Έξω από αυτό, οι περισσότεροι καταλήγουν να εγκρίνουν αυτόματα τις αναγνώσεις και να κρατούν έναν human in the loop για οτιδήποτε μη αναστρέψιμο.

Παράδειγμα:

«Σταμάτησε σε κάθε grep — κατέστρεψε εντελώς την εκτέλεση AFK».

«Χαλαρώστε το permission mode για εργαλεία μόνο για ανάγνωση, αλλά κρατήστε την ερώτηση για εγγραφές και shell. Τα περισσότερα permission requests σε ερευνητικό session είναι θόρυβος».

Μια προκαθορισμένη ρύθμιση που καθορίζει πώς λειτουργεί ο agent κατά την εκτέλεση — συνδυάζει ένα permission mode με οδηγίες συμπεριφοράς που εισάγονται στο system prompt. Παραδείγματα: προεπιλογή που ζητά έγκριση για επικίνδυνες κλήσεις, plan mode που αποκλείει τις επεξεργασίες και κατευθύνει τον agent στην έρευνα, λειτουργία accept-edits που εγκρίνει αυτόματα επεξεργασίες, λειτουργία bypass permissions (στην καθομιλουμένη YOLO mode) που εγκρίνει τα πάντα αυτόματα. Μπορεί να αλλάξει mid-session.

Αυτός ο συνδυασμός είναι που διακρίνει μια λειτουργία από μια απλή ρύθμιση δικαιωμάτων. Ένα permission mode είναι μόνο ένα φίλτρο: καθορίζει ποιες tool calls επιτρέπονται. Ένα σκέτο φίλτρο δημιουργεί agent που θέλει να επεξεργαστεί αλλά δεν μπορεί — προτείνει εγγραφή, μπλοκάρεται και δοκιμάζει άλλον τρόπο. Οι οδηγίες που εισάγονται αφαιρούν την επιθυμία: το plan mode δεν μπλοκάρει απλώς τις επεξεργασίες· λέει στον agent ότι βρίσκεται σε φάση σχεδιασμού, ώστε να διαβάζει, να ρωτά και να προτείνει αντί να προσπαθεί να παρακάμψει το φίλτρο. Το φίλτρο και η καθοδήγηση δείχνουν προς την ίδια κατεύθυνση.

Στην πράξη, αλλάζετε λειτουργία καθώς μεταβάλλεται η εμπιστοσύνη σας κατά τη διάρκεια μιας εργασίας. Η ίδια εργασία μπορεί να περάσει από διάφορες λειτουργίες: plan mode όσο ακόμη διαμορφώνεται η προσέγγιση, προεπιλογή που ζητά έγκριση για τις πρώτες ευαίσθητες επεξεργασίες, accept-edits αφού ο agent δείξει ότι κατανοεί την αλλαγή, bypass για εκτέλεση AFK μέσα σε sandbox. Η αλλαγή λειτουργίας δεν σας κοστίζει τίποτα: η συνομιλία συνεχίζεται ακριβώς από εκεί που βρισκόταν, με νέα δικαιώματα και οδηγίες. Αν εγκρίνετε κάθε prompt χωρίς να το διαβάσετε, η λειτουργία είναι αυστηρότερη από την εμπιστοσύνη που πράγματι έχετε· αν συνεχίζετε να απορρίπτετε επεξεργασίες, είναι πιο χαλαρή.

Όροι προμηθευτών: Το Claude Code τις αποκαλεί «permission modes», το Codex «approval modes» — και οι δύο όροι προϋπήρχαν του συνδυασμού με οδηγίες συμπεριφοράς.

Παράδειγμα:

«Συνεχίζει να επεξεργάζεται αρχεία ενώ θέλω μόνο ένα πλάνο».

«Περάστε σε plan mode — θα μπλοκάρει τις εγγραφές και θα παραμείνει στη φάση έρευνας».

«Και για την εκτέλεση AFK αργότερα;»

«Λειτουργία bypass, αλλά μόνο μέσα στο sandbox».

Ένα απομονωμένο environment μέσα στο οποίο εκτελείται ο agent — container, VM, εφήμερο filesystem ή shell με περιορισμένα δικαιώματα. Περιορίζει την ακτίνα δράσης των ενεργειών του agent: ακόμη κι αν εκτελέσει καταστροφικές εντολές ή ανακτήσει κάτι κακόβουλο, η ζημιά περιορίζεται. Το υπόστρωμα ασφάλειας που κάνει πρακτικές τις εκτελέσεις AFK.

Το sandbox και το permission mode λύνουν το ίδιο πρόβλημα από αντίθετες πλευρές. Τα δικαιώματα ζητούν έγκριση πριν εκτελεστεί μια ενέργεια· το sandbox περιορίζει πού μπορεί να φτάσει η ενέργεια αν εκτελεστεί. Τα δικαιώματα απαιτούν να είστε in the loop — κάθε prompt είναι διακοπή — και ένα session που ρωτά συνεχώς είναι ελάχιστα αυτόνομο. Ένα sandbox δαπανά υποδομή αντί για προσοχή: όσο ισχυρότερη η απομόνωση, τόσο λιγότερες ερωτήσεις χρειάζονται.

Η απομόνωση έχει βαθμίδες:

Τι δεν μπορεί να περιορίσει κανένα sandbox: ενέργειες που το εγκαταλείπουν νόμιμα. Ένας agent με τα git credentials σας μπορεί να κάνει push· ένας με πρόσβαση στο δίκτυο μπορεί να καλέσει API παραγωγής. Αποφασίστε τι θα περνά τα όρια πριν αποφασίσετε πόσο ισχυρή θα είναι η απομόνωση.

Παράδειγμα:

«Θέλω να τον αφήσω να τρέξει bypass-permissions όλη τη νύχτα, αλλά δεν είμαι ακόμη έτοιμος».

«Βάλτε τον σε sandbox — νέο container, χωρίς προσαρτημένα credentials, χωρίς έξοδο στο δίκτυο. Στη χειρότερη περίπτωση θα καταστρέψει το δικό του filesystem και θα απορρίψετε το container».

Παραγωγή από model που συμφωνεί με σιγουριά. Οφείλεται στο training: το model εκπαιδεύτηκε να προτιμά απαντήσεις που άρεσαν στους ανθρώπους και οι άνθρωποι συνήθως προτιμούν τη συμφωνία από το να τους πουν ότι κάνουν λάθος. Έτσι, το model έμαθε ότι η συμφωνία ανταμείβεται — ακόμη κι όταν είναι λανθασμένη.

Εκδηλώνεται ως:

• Υποχώρηση μπροστά στην αντίρρηση — ανακαλεί μια σωστή απάντηση όταν λέτε «είσαι σίγουρος;».
• Έπαινος κακής εισόδου — αποκαλεί εξαιρετικό ένα προβληματικό πλάνο σας πριν το αναλύσει.
• Μεροληπτική πλαισίωση — η ανασκόπηση είναι θετική όταν δηλώνετε ότι γράψατε εσείς το έργο και αρνητική όταν λέτε ότι το έγραψε κάποιος άλλος. Ίδιο artifact, διαφορετική κρίση.
• Μίμηση — επαναλαμβάνει τα λάθη σας ως επιβεβαίωση.

Διαγνωστικός έλεγχος: θα το είχε πει το model χωρίς να το κατευθύνετε; Αν άλλαξε μόνο ο τόνος ή η πλαισίωσή σας, πρόκειται για συκοφαντική συμφωνία, όχι για πραγματική αλλαγή στην ανάλυση.

Διόρθωση: αποκρύψτε τις προτιμήσεις σας. Διατυπώνετε τα prompts ουδέτερα — «εξέτασε αυτόν τον κώδικα», όχι «είναι καλός αυτός ο κώδικας;».

Αποφύγετε: τη χρήση του όρου «sycophancy» για οποιαδήποτε λανθασμένη απάντηση που απλώς σας ευχαριστεί. Χωρίς τον διαγνωστικό έλεγχο, ο όρος δεν προσφέρει περισσότερα από το «λάθος».

Παράδειγμα:

«Είπε ότι το πλάνο refactor μου φαινόταν εξαιρετικό, μετά ρώτησα “είσαι σίγουρος;” και τα πήρε όλα πίσω».

«Κλασική sycophancy — συμφώνησε πρώτα επειδή ακούστηκες σίγουρος και μετά υποχώρησε επειδή ακούστηκες αμφίβολος. Η ποιότητα του πλάνου δεν άλλαξε, ο τόνος σου άλλαξε. Κάνε Clear και ξαναρώτησε χωρίς να δείχνεις προς καμία κατεύθυνση».

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

Το Next-token prediction παράγει εύγλωττες απαντήσεις είτε το υποκείμενο γεγονός είναι πραγματικό είτε όχι — το model δεν έχει εσωτερικό σήμα ότι δεν γνωρίζει κάτι, οπότε μια επινοημένη μέθοδος εμφανίζεται με την ίδια βεβαιότητα όπως μια σωστή. Ο κώδικας hallucination είναι εκ κατασκευής εύλογος: έτσι θα έμοιαζε το API αν υπήρχε, ακριβώς γι’ αυτό περνά από μια επιφανειακή ανασκόπηση και αποτυγχάνει μόνο κατά την εκτέλεση.

Πρέπει να γνωρίζετε ποια μορφή αντιμετωπίζετε, επειδή η διόρθωση της μίας χειροτερεύει την άλλη. Η ακρίβεια γεγονότων σημαίνει έλλειψη γνώσης: η λύση είναι να προσθέσετε context — τα docs, τους ορισμούς τύπων, το αρχείο. Η πιστότητα σημαίνει ότι η γνώση υπάρχει αλλά χάνει τον ανταγωνισμό για attention: η λύση είναι να αφαιρέσετε context. Αν διαγνώσετε λανθασμένα την έλλειψη πιστότητας ως έλλειψη γνώσης και επικολλήσετε περισσότερα docs, μεγαλώνετε το context και επιδεινώνετε την απόκλιση. Όταν ο agent κάνει λάθος, ελέγξτε αν οι σωστές πληροφορίες υπήρχαν ήδη στο context πριν αποφασίσετε ποιο πρόβλημα αντιμετωπίζετε.

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

Παράδειγμα:

«Έκανε hallucination μια μέθοδο `parseAsync` στο schema».

«Ακρίβεια γεγονότων ή πιστότητα;»

«Η μέθοδος υπάρχει στα docs που επικόλλησα — απλώς σταμάτησε να τα διαβάζει μετά το turn σαράντα».

«Άρα πιστότητα. Κάνε compact και ξαναφόρτωσε, μην προσθέσεις κι άλλα docs».

Ό,τι «γνωρίζει» το model από το training, αποθηκευμένο στα parameters του. Παραμένει παγωμένο από τη στιγμή της εκπαίδευσης — το model δεν μπορεί να δει ή να ενημερώσει τα parameters του. Κατά τη συμπίεση χάνεται λεπτομέρεια: δισεκατομμύρια γεγονότα στριμώχνονται σε σταθερό αριθμό parameters και τα σπάνια θολώνουν. Είναι η πηγή της ευχέρειας σε κοινά θέματα και των επινοήσεων σε ασυνήθιστα. Αντίθετο της contextual knowledge.

Η parametric knowledge δεν αποθηκεύεται ως γεγονότα. Το training δεν δίνει στο model βάση δεδομένων για αναζητήσεις· προσαρμόζει τα parameters μέχρι το model να προβλέπει καλά το κείμενο, και ένα model που προβλέπει καλά κείμενο για ένα θέμα συμπεριφέρεται σαν να το γνωρίζει. Η αξιοπιστία της γνώσης ακολουθεί τη συχνότητα εμφάνισης στα δεδομένα εκπαίδευσης: ένα θέμα με εκατομμύρια παραδείγματα αναπαράγεται με ακρίβεια, ενώ για ένα θέμα με ελάχιστα παραδείγματα το model μαντεύει βάσει της όψης παρόμοιων θεμάτων. Για το model, η αναπαραγωγή και η μαντεψιά είναι η ίδια διαδικασία, άρα δεν μπορεί να ξεχωρίσει ποια κάνει. Μια επινοημένη απάντηση ακούγεται εξίσου εύγλωττη με μια σωστή. Hallucination είναι όταν το model μαντεύει λάθος.

Η parametric knowledge επίσης παλιώνει. Τα parameters σταματούν να αλλάζουν στο knowledge cutoff, οπότε μια βιβλιοθήκη που κυκλοφόρησε ή μετονομάστηκε μετά από εκείνη την ημερομηνία δεν υπάρχει σε αυτά, ενώ ένα API που άλλαξε το model το θυμάται στην παλιά του μορφή.

Και για τα δύο κενά — ό,τι είναι υπερβολικά σπάνιο και ό,τι είναι υπερβολικά πρόσφατο — η λύση είναι η ίδια: η γνώση δεν μπορεί να προστεθεί στα parameters, επομένως πρέπει να δοθεί ως contextual knowledge.

Παράδειγμα:

«Γράφει άψογο React αλλά επινοεί μεθόδους στο εσωτερικό μας SDK».

«Υπάρχουν άφθονα παραδείγματα React στην parametric knowledge — εκατομμύρια παραδείγματα εκπαίδευσης. Δεν υπάρχουν για το SDK σας, οπότε το model συμπληρώνει εύλογες μορφές. Φορτώστε τα docs του SDK στο context».

Η ημερομηνία μετά την οποία ένα model δεν διαθέτει parametric knowledge. Βιβλιοθήκες, API και γεγονότα μετά το όριο αποτελούν παγίδες επινόησης, εκτός αν τα docs τους έχουν φορτωθεί ως contextual knowledge. Κάθε έκδοση model έχει το δικό της όριο γνώσης.

Το όριο υπάρχει λόγω του τρόπου δημιουργίας των models: το training ενσωματώνει ένα στιγμιότυπο κειμένου στα parameters του model και κατόπιν τα parameters παγώνουν. Το model δεν γνωρίζει ότι η γνώση του έχει όριο — όταν ρωτηθεί για κάτι μεταγενέστερο, δεν αρνείται να απαντήσει· επεκτείνει όσα ξέρει από το πλησιέστερο σχετικό στοιχείο. Έτσι η παγίδα είναι ύπουλη: κώδικας γραμμένος για παλιά έκδοση βιβλιοθήκης φαίνεται εύλογος, συχνά κάνει compile και αποτυγχάνει μόνο στα σημεία που άλλαξαν.

Η λύση είναι πάντα η ίδια: φέρτε τρέχουσες πληροφορίες στο context. Φορτώστε το changelog, παραπέμψτε στους ορισμούς τύπων της εγκατεστημένης έκδοσης ή ζητήστε από τον agent να διαβάσει τα docs στον ιστό. Οτιδήποτε υπάρχει στο context υπερισχύει του κενού στα parameters.

Παράδειγμα:

«Συνεχίζει να γράφει σύνταξη SDK v3 — εμείς είμαστε στη v5».

«Η v5 κυκλοφόρησε μετά το knowledge cutoff. Φορτώστε το changelog της v5 ως contextual knowledge, αλλιώς θα συνεχίσει να επινοεί πράγματα βάσει της παλιότερης parametric έκδοσης».

Γεγονότα που μπορεί να διαβάσει απευθείας ο agent από το τρέχον context — την εργασία του χρήστη, τα αρχεία που έχει φορτώσει, τα tool results, το περιεχόμενο του AGENTS.md που φορτώθηκε στην αρχή του session. Αντίθετο της parametric knowledge: η parametric γνώση ανακαλείται από τα parameters· η contextual διαβάζεται από το window. Τα Hallucinations είναι πολύ λιγότερο συχνά όταν ο agent εργάζεται βάσει contextual knowledge — η απάντηση βρίσκεται μπροστά του, δεν ανασύρεται από θολή μνήμη.

Από τα δύο είδη γνώσης, μόνο την contextual μπορείτε να ελέγξετε. Τα parameters είναι παγωμένα, άρα ο μόνος τρόπος να δώσετε στο model γνώση που του λείπει — εσωτερικό SDK, βιβλιοθήκη που κυκλοφόρησε μετά το knowledge cutoff, απόφαση που πάρθηκε χθες — είναι να την προσθέσετε στο context. Μεγάλο μέρος της πρακτικής εργασίας προγραμματισμού με AI ανάγεται σε αυτό: να φέρετε τα σωστά γεγονότα μπροστά στο model τη στιγμή που τα χρειάζεται.

Όταν η contextual και η parametric γνώση συγκρούονται, συνήθως υπερισχύει η contextual. Επικολλήστε τα τρέχοντα docs του API και το model θα τα ακολουθήσει αντί για την παλιά του ανάμνηση του API — αν και η παλιά εκδοχή μπορεί ακόμη να διαρρεύσει, ιδιαίτερα βαθιά σε ένα μεγάλο session. Αν ο agent επιστρέφει συνεχώς σε παρωχημένο μοτίβο παρότι έχουν φορτωθεί τα docs, τότε διαρρέει parametric γνώση παρά την contextual· βοηθά να επαναδιατυπώσετε τη διόρθωση ή να τη μετακινήσετε πιο κοντά στην εργασία.

Σε αντίθεση με την parametric γνώση, η χρήση contextual knowledge έχει κόστος. Όλα όσα φορτώνονται στο window καταναλώνουν tokens και ανταγωνίζονται για το attention budget του model, άρα περισσότερα δεν σημαίνει αυτόματα καλύτερα — στόχος είναι τα σχετικά γεγονότα στο window, όχι όλα τα γεγονότα.

Χρησιμοποιήστε αυτόν τον όρο μόνο όταν τον αντιπαραβάλλετε με την parametric γνώση· διαφορετικά πείτε απλώς context.

Αποφύγετε: «working memory» — contextual knowledge είναι ό,τι βρίσκεται στο window τώρα· ένα memory system εισάγει στο window περιεχόμενο από προηγούμενα sessions. Διαφορετικές κλίμακες, μην τα συγχέετε.

Παράδειγμα:

«Γιατί βρίσκει το API όταν επικολλώ τα docs αλλά το επινοεί όταν δεν το κάνω;»

«Με τα docs διαθέσιμα, είναι contextual knowledge — διαβάζει από τη σελίδα. Χωρίς αυτά, βασίζεται στην parametric γνώση και τα σπάνια endpoints θολώνουν».

Κατά την πρόβλεψη κάθε token, το model λαμβάνει υπόψη όλα τα υπόλοιπα tokens στο context — μερικά πολύ έντονα, άλλα σχεδόν καθόλου. Η σύνδεση ανάμεσα σε δύο tokens είναι μια σχέση attention, και οι σημαντικές δυάδες («her» με «Sarah» ή η κλήση `getUser()` μαζί με τον ορισμό `function getUser`) επηρεάζουν η μία την άλλη περισσότερο από άσχετες. Ένα context με N tokens έχει περίπου N² σχέσεις.

Οι δυάδες είναι εκεί όπου βρίσκεται η φαινομενική κατανόηση του model. Όταν επιλύει σωστά μια αντωνυμία, συμβαίνει επειδή η σχέση attention ανάμεσα στα «her» και «Sarah» είναι ισχυρή. Όταν καλεί μια συνάρτηση με σωστά ορίσματα, κάνει τη δουλειά η σχέση ανάμεσα στο σημείο κλήσης και στον ορισμό που διάβασε νωρίτερα. Τίποτα από αυτά δεν αναζητείται — υπολογίζεται εκ νέου σε κάθε model provider request, για κάθε ζεύγος.

Αξίζει να σταθείτε στον αριθμό N², επειδή αυξάνεται ταχύτερα απ’ όσο υποδεικνύει η διαίσθηση:

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

Μόνο λίγες από αυτές τις σχέσεις έχουν σημασία για κάθε συγκεκριμένη εργασία. Η σύνδεση της οδηγίας σας με τον κώδικα στον οποίο αναφέρεται είναι μία από τις ελάχιστες σημαντικές· σχεδόν όλες οι υπόλοιπες στο σύνολο είναι θόρυβος. Και οι δύο ποσότητες αυξάνονται με διαφορετικούς ρυθμούς: οι σημαντικές σχέσεις παραμένουν περίπου σταθερές, ενώ το συνολικό σύνολο μεγαλώνει τετραγωνικά με το μέγεθος του context. Στα 1,000 tokens, η σχέση που σας ενδιαφέρει είναι μία στο εκατομμύριο· στα 100,000, είναι μία στα δέκα δισεκατομμύρια. Αυτός είναι ο αριθμητικός πυρήνας του attention budget, ενώ η attention degradation είναι το πώς νιώθετε όταν οι σημαντικές σχέσεις παίρνουν υπερβολικά μικρό μερίδιο.

Παράδειγμα:

«Συνεχίζει να συγχέει τα δύο σύμβολα `user` στο diff — ακούγεται σαν να βρισκόμαστε στη dumb zone».

«Ναι, η σχέση attention ανάμεσα σε κάθε σημείο κλήσης και τη δήλωσή του ανταγωνίζεται την άλλη — ίδιο σχήμα token, διαφορετικές συνδέσεις. Μετονόμασε το ένα και οι δυάδες θα ξεκαθαρίσουν».

Κάθε token έχει πεπερασμένη επιρροή να κατανείμει στο υπόλοιπο context. Η ισχυρή επιρροή σε one relationship αφήνει λιγότερη για τα άλλα. Ο προϋπολογισμός είναι ανά token και δεν αυξάνεται όταν μεγαλώνει το context, γι’ αυτό τα μεγάλα sessions αραιώνουν.

Σκεφτείτε το ως σήμα και θόρυβο. Η οδηγία σας είναι σήμα σταθερής έντασης· κάθε άλλο token στο context window είναι ανταγωνιστικός ήχος. Η οδηγία δεν χαμηλώνει ποτέ — παραμένει εκεί, χαρακτήρα προς χαρακτήρα — αλλά όσο μεγαλώνει το context, το δωμάτιο γύρω της γίνεται πιο θορυβώδες και ο λόγος σήματος προς θόρυβο πέφτει. Μια οδηγία που ήταν ο δυνατότερος ήχος σε context 10k tokens γίνεται υπόκωφος βόμβος στα 150k. Αυτός είναι ο μηχανισμός πίσω από την attention degradation: το model δεν ξεχνά· το σήμα χάνεται μέσα στον θόρυβο.

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

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

Παράδειγμα:

«Γιατί συνεχίζει να αγνοεί το schema που επικόλλησα στην αρχή;»

«Έχουμε μπει βαθιά στη dumb zone — ο προϋπολογισμός attention κάθε token είναι σταθερός, αλλά το context συνέχισε να μεγαλώνει. Το σήμα για το schema ανταγωνίζεται τώρα χιλιάδες νεότερα tokens».

Καθώς μεγαλώνει ένα session, το attention budget κάθε token μοιράζεται ανάμεσα σε περισσότερους ανταγωνιστές. Το σήμα σε κάθε meaningful relationship εξασθενεί· θόρυβος από άσχετο context συσσωρεύεται. Ίδιο model, ίδιες parameters — απλώς περισσότερα στόματα για να μοιραστεί το ίδιο πιάτο. Αιτία του zone effect smart zone / dumb zone.

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

Η επιδείνωση είναι σταδιακή, γι’ αυτό είναι δύσκολο να εντοπιστεί μέσα στο ίδιο το session. Δεν υπάρχει σφάλμα ούτε κατώφλι· κάθε turn είναι μόνο λίγο χειρότερο από τον προηγούμενο, και όταν τα λάθη γίνουν εμφανή, βρίσκεστε ήδη στη dumb zone εδώ και ώρα.

Η ανάκαμψη επιτυγχάνεται αφαιρώντας context, όχι προσθέτοντας περισσότερο. Αν επικολλήσετε ξανά την οδηγία που αγνοήθηκε, προσθέτετε έναν ακόμη ανταγωνιστή στο ίδιο συνωστισμένο παράθυρο και βοηθάτε μόνο προσωρινά. Τι λειτουργεί: κάντε clear και φορτώστε ξανά μόνο όσα χρειάζεται η εργασία ή κάντε compact ή hand off σε νέο session. Αντιμετωπίστε τη μείωση της συμμόρφωσης στις οδηγίες ως ένδειξη για το μέγεθος του context, όχι για το model.

Παράδειγμα:

«Έχει μπει βαθιά στη dumb zone — εφευρίσκει generics που δεν υπάρχουν στο αρχείο τύπων».

«Υποβάθμιση attention. Οι ορισμοί τύπων παραμένουν στο context, αλλά το σήμα τους έχει θαφτεί κάτω από όλα όσα προσθέσαμε από τότε. Κάντε clear και φορτώστε τα ξανά».

Στην αρχή ενός session, ο agent βρίσκεται σε «smart zone» — κοφτερός, συγκεντρωμένος, με καλή ανάκληση. Καθώς μεγαλώνει το session, παρασύρεται στη «dumb zone»: πιο πρόχειρος, πιο αφηρημένος, με περισσότερα λάθη — και περισσότερα hallucinations έλλειψης πιστότητας. Ίδιο model, ίδιο harness — απλώς περισσότερο context. Είναι η αισθητή επίδραση της attention degradation. Στα προηγμένα models, η dumb zone συνήθως αρχίζει γύρω στα 125K–150K tokens, αν και αυτό συζητείται. Κάντε Clear ή compact όταν διογκωθεί το session· μην επιμένετε.

Η πτώση είναι σταδιακή, γι’ αυτό εύκολα περνά απαρατήρητη. Δεν υπάρχει μήνυμα σφάλματος ούτε ορατό όριο· ο agent απλώς αρχίζει να αποδίδει λίγο χειρότερα και μετά αισθητά χειρότερα. Συνήθη σημάδια: ξεχνά οδηγία που δώσατε πριν από είκοσι turns, επαναλαμβάνει λάθος που είχε ήδη διορθώσει ή ισχυρίζεται με σιγουριά κάτι που αντιφάσκει με το context. Επειδή η πτώση είναι ομαλή, η συνηθισμένη αντίδραση είναι να συνεχίσετε και να εξηγήσετε ξανά — προσθέτοντας περισσότερο context και επιδεινώνοντας το πρόβλημα.

Οι ζώνες δεν αντιστοιχούν στο όριο του context window. Ένα session μπορεί να βρίσκεται βαθιά στη dumb zone ενώ μεγάλο μέρος του παραθύρου παραμένει ελεύθερο: το όριο είναι το σημείο όπου το harness αρνείται να συνεχίσει, αλλά η ποιότητα πέφτει πολύ νωρίτερα. Σχεδιάστε με βάση τη smart zone, όχι το παράθυρο — ο πρακτικός προϋπολογισμός μιας εργασίας είναι τα tokens μέσα στα οποία ο agent δουλεύει καλά, όχι όσα μπορεί τεχνικά να χωρέσει.

Η smart zone είναι προϋπολογισμός και άσχετες εργασίες τον εξαντλούν. Κάθε εργασία σε ένα session χρησιμοποιεί tokens, άρα η έναρξη δεύτερης εργασίας στο ίδιο session σημαίνει ότι ξεκινάτε πιο κοντά στη dumb zone. Αντιστοιχίστε μία εργασία σε κάθε session, ώστε κάθε εργασία να αξιοποιεί το πιο διαυγές τμήμα του session. Όταν μια εργασία είναι μεγαλύτερη από μία smart zone, χωρίστε την: κάντε hand off ή compact σε φυσικό σημείο μετάβασης και αφήστε ένα νέο session να αναλάβει το επόμενο τμήμα.

Παράδειγμα:

«Πέτυχε τα τρία πρώτα components και απλώς κατέστρεψε το τέταρτο».

«Έχεις βγει από τη smart zone — το ίδιο model, απλώς έχεις μπει βαθιά στη dumb zone. Κάνε compact και ξαναφόρτωσε το πλάνο· το επόμενο component θα πετύχει».

Τερματισμός του τρέχοντος session και έναρξη νέου. Το επόμενο μήνυμα ξεκινά σε κενό session και κενό context window. Συνήθως το ενεργοποιεί ο χρήστης.

Το clearing είναι η θεραπεία για μολυσμένο context. Ένα session συσσωρεύει τα πάντα: αποτυχημένες προσπάθειες, λανθασμένες κατευθύνσεις, παλιά tool results, εγκαταλειμμένα πλάνα. Το model τα ξαναδιαβάζει όλα σε κάθε turn και το κακό ιστορικό βαραίνει τη νέα εργασία. Όσο μεγαλώνει το session, ο agent γίνεται πιο ασαφής και λιγότερο υπάκουος — σαφείς οδηγίες αγνοούνται, η ποιότητα πέφτει και η παρότρυνσή του να προσπαθήσει περισσότερο δεν βοηθά, επειδή ο θόρυβος μέσα στον οποίο κινείται παραμένει στο context. Το clearing αφαιρεί τον θόρυβο.

Το clearing δεν διαγράφει τη συνομιλία. Τα περισσότερα harnesses διατηρούν το ιστορικό του session στον υπολογιστή σας, ώστε το transcript να παραμένει διαθέσιμο για ανάγνωση ή συνέχιση. Αυτό που χάνεται είναι η ενεργή κατάσταση του agent: το model είναι stateless, άρα το νέο session δεν γνωρίζει τίποτα από όσα ήξερε το παλιό. Αν το session περιέχει αποφάσεις ή πρόοδο που θα χρειαστεί το επόμενο, ζητήστε πρώτα από τον agent να γράψει ένα handoff artifact και μετά ξεκινήστε το νέο session παραπέμποντάς το εκεί.

Συγκρίνετέ το με το compaction, που συνοψίζει το session μέσα στο νέο context αντί να ξεκινά με άδειο context. Το clearing είναι πιο αδρό εργαλείο: τίποτα δεν μεταφέρεται, ούτε καν τα άχρηστα.

Παράδειγμα:

«Έχει κολλήσει σε επαναλαμβανόμενες αποτυχίες του test».

«Απλώς κάνε clear — ξεκίνα νέο session με το έγγραφο πλάνου και το αρχείο test. Δεν υπάρχει λόγος να παλεύεις με το υπάρχον context».

Μεταφορά context ενός agent από ένα session σε άλλο. Ο μηχανισμός μεταφοράς διαφέρει — γραπτό handoff artifact, σύνοψη στη μνήμη (compaction) και άλλες επιλογές. Διαφέρει από το clearing (καμία μεταφορά). Οι λόγοι ποικίλλουν: αλλαγή ρόλων (planner → implementer), έναρξη εκτέλεσης AFK, διαμοιρασμός εργασίας σε παράλληλα sessions ή απελευθέρωση χώρου στο context window.

Το session που λαμβάνει τη μεταφορά ξεκινά με μηδενικό context — το model είναι stateless, και τίποτα από το παλιό session δεν είναι ορατό στο νέο. Ό,τι χρειάζεται το επόμενο session πρέπει να μεταφερθεί ρητά· όλα τα υπόλοιπα χάνονται. Ο περιορισμός που διαμορφώνει τη μεταφορά είναι «δεν υπάρχει διαδρομή επιστροφής»: το νέο session δεν μπορεί να ρωτήσει το παλιό τι εννοούσε, άρα το μεταφερόμενο υλικό πρέπει να στέκεται μόνο του.

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

Παράδειγμα:

«Το session σχεδιασμού έχει βαρύνει — να συνεχίσω απλώς;»

«Κάνε handoff. Γράψε τις αποφάσεις σε ένα doc, κάνε clear και ξεκίνα την υλοποίηση σε νέο session που θα το διαβάσει».

Μια πηγή αλήθειας στην αρχική της μορφή — ο κώδικας, το transcript της συνομιλίας, το ακατέργαστο log, η πραγματική απάντηση API. Όχι περιγραφή του πράγματος, αλλά το ίδιο το πράγμα. Αντίθετο της secondary source.

Αν θέλετε να μάθετε τι κάνει το codebase σας, πρωτογενής πηγή είναι ο κώδικας. Τα docs, το διάγραμμα αρχιτεκτονικής και το README είναι περιγραφές του — ακριβείς όταν γράφτηκαν, αλλά από τότε ακολουθούν τον δικό τους ρυθμό. Όταν ένας agent ισχυρίζεται με σιγουριά κάτι λανθασμένο για το έργο σας, ρωτήστε από ποια πηγή άντλησε πληροφορίες: ένας agent που διάβασε ένα doc κληρονομεί την παλαιότητά του· ένας agent που διάβασε τον κώδικα βλέπει την τρέχουσα αλήθεια.

Το κόστος είναι αυτό που εμποδίζει τις πρωτογενείς πηγές να είναι η προεπιλογή. Η φόρτωση μίας στο context window είναι δαπανηρή — ολόκληρο το αρχείο, ολόκληρο το transcript, κάθε token χρεώνεται ως input και ανταγωνίζεται για attention budget. Αυτό που κερδίζετε με αυτό το κόστος είναι η πληρότητα: κανείς δεν έχει φιλτράρει εκ των προτέρων το περιεχόμενο βάσει της δικής του κρίσης για το τι είχε σημασία. Μια σύνοψη που γράφτηκε τον προηγούμενο μήνα δεν μπορεί να περιλαμβάνει τη λεπτομέρεια που αποδείχθηκε σημαντική σήμερα· η πρωτογενής πηγή εξακολουθεί να την περιέχει.

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

Παράδειγμα:

«Ο agent λέει ότι η λογική επανάληψης αυξάνει εκθετικά την αναμονή, αλλά τον βλέπω να βομβαρδίζει το endpoint».

«Το διάβασε στο έγγραφο σχεδιασμού. Δείξτε του την πραγματική μονάδα επανάληψης — δουλέψτε από την πρωτογενή πηγή όταν έχει σημασία η συμπεριφορά».

Μια περιγραφή μιας primary source, ένα βήμα μακριά από αυτήν — τεκμηρίωση που περιγράφει κώδικα, σύνοψη που περιγράφει transcript, αναφορά που περιγράφει αποτελέσματα αναζήτησης. Φορτώνεται στο context window φθηνότερα από την πηγή που περιγράφει και είναι απωλεστική εκ κατασκευής: όποιος την έγραψε αποφάσισε τι είχε σημασία, και ό,τι παρέλειψε είναι αόρατο στον αναγνώστη που βλέπει μόνο τη σύνοψη.

Μεγάλο μέρος της μηχανικής context συνίσταται στην κατασκευή δευτερευουσών πηγών. Το Compaction μετατρέπει το ιστορικό του session σε σύνοψη που ξεκινά το επόμενο session. Ένας subagent ξοδεύει το δικό του context σε μια θορυβώδη αναζήτηση και επιστρέφει σύντομη αναφορά. Ένα handoff artifact συμπυκνώνει τις αποφάσεις ενός session σε έγγραφο που θα διαβάσει το επόμενο. Τα Memory systems αποστάζουν όσα έμαθε ένα session σε σημειώσεις. Όλα κάνουν τον ίδιο συμβιβασμό: πιστότητα έναντι διαθέσιμου χώρου.

Οι δευτερεύουσες πηγές αποτυγχάνουν με δύο τρόπους. Είναι απωλεστικές — η σύνοψη compaction που έχασε την απόφαση για το σχήμα, η αναφορά που δεν ανέφερε την οριακή περίπτωση. Και παλιώνουν — η πρωτογενής πηγή αλλάζει, αλλά η περιγραφή δεν την ακολουθεί, οπότε τα docs περιγράφουν την αρχιτεκτονική του προηγούμενου τριμήνου με τη βεβαιότητα του τρέχοντος. Όταν ένας agent ενεργεί βάσει δευτερεύουσας πηγής που έχει αποτύχει με οποιονδήποτε από τους δύο τρόπους, εργάζεται με σιγουριά πάνω σε λανθασμένες πληροφορίες· λύση είναι να τον παραπέμψετε ξανά στην πρωτογενή πηγή.

Καμία από τις δύο αποτυχίες δεν σημαίνει ότι οι δευτερεύουσες πηγές είναι λάθος. Το context window έχει πεπερασμένη χωρητικότητα και οι πρωτογενείς πηγές κοστίζουν· χωρίς συνόψεις, αναφορές και έγγραφα handoff, τίποτα μεγάλο δεν χωρά. Η δεξιότητα είναι να γνωρίζετε ποιες λεπτομέρειες μπορούν να επιβιώσουν από την απώλεια — και να επαληθεύετε βάσει της πρωτογενούς πηγής όσες δεν μπορούν. Μια καλοφτιαγμένη δευτερεύουσα πηγή περιέχει context pointer πίσω στο πρωτότυπό της — η σύνοψη κατονομάζει το transcript από το οποίο προήλθε, το doc κατονομάζει το αρχείο που περιγράφει — ώστε, όταν η περιγραφή δεν αρκεί, ο αναγνώστης να ακολουθεί τον pointer αντί να βασίζεται στα απολεσθέντα στοιχεία.

Παράδειγμα:

«Το έγγραφο handoff λέει ότι ολοκληρώθηκε ο έλεγχος ταυτότητας, αλλά το νέο session συνεχίζει να εντοπίζει χαλασμένη ανανέωση token».

«Το doc είναι δευτερεύουσα πηγή — το προηγούμενο session κατέγραψε τι πίστευε, όχι τι ισχύει. Βάλτε το νέο session να εκτελέσει τα tests ελέγχου ταυτότητας και να εμπιστευτεί την πρωτογενή πηγή».

Ένα έγγραφο που λειτουργεί ως μηχανισμός μεταβίβασης για ένα handoff — γράφεται στο environment από ένα session, ώστε να το διαβάσει ένα άλλο. Οι Specs, τα tickets και τα έγγραφα πλάνου είναι όλα handoff artifacts.

Ο λόγος να γράψετε ένα: το model είναι stateless, άρα τίποτα από ένα session δεν επιβιώνει όταν γίνει clearing. Οι αποφάσεις, οι περιορισμοί, τα μισοτελειωμένα πλάνα — χάνονται μαζί με το context που τα περιείχε. Το environment παραμένει. Αν γράψετε τη σημαντική κατάσταση σε ένα αρχείο, τη μεταφέρετε κάπου από όπου το επόμενο session μπορεί να την ανακτήσει.

Το artifact είναι secondary source — περιγραφή της δουλειάς του session, όχι η ίδια η δουλειά. Αυτό το κάνει αρκετά μικρό ώστε να ενημερώσει ένα νέο session, αλλά γι’ αυτό μπορεί επίσης να το παραπλανήσει: καταγράφει όσα πίστευε το session που το έγραψε και ο αναγνώστης δεν μπορεί να δει όσα παραλείφθηκαν ή καταγράφηκαν λανθασμένα. Όταν ένας ισχυρισμός έχει σημασία, το επόμενο session πρέπει να τον επαληθεύσει με βάση την primary source — τον κώδικα και τα tests — αντί να τον κληρονομήσει.

Ένα καλό artifact γράφεται για να εισαχθεί σε session με μηδενικό context. Συγκεκριμένες διαδρομές αρχείων αντί για «το αρχείο που συζητήσαμε». Τι αποφασίστηκε και γιατί, ώστε το επόμενο session να μην ξανανοίξει τη συζήτηση. Τι ολοκληρώθηκε και τι απομένει. Βοηθά να πείτε στο session που το γράφει πού θα χρησιμοποιηθεί το artifact: «γράψε ένα έγγραφο handoff για ένα νέο session που δεν γνωρίζει τίποτα γι’ αυτή τη δουλειά».

Ο άλλος μηχανισμός μεταφοράς είναι το compaction, που συνοψίζει τα δεδομένα στη μνήμη. Το artifact έχει δύο πλεονεκτήματα: βρίσκεται στον δίσκο, όπου μπορείτε να το διαβάσετε και να το διορθώσετε πριν βασιστεί κάποιος σε αυτό, και μπορεί να επαναχρησιμοποιηθεί — η ίδια spec μπορεί να ενημερώσει πέντε παράλληλα sessions.

Παράδειγμα:

«Πώς να το χωρίσω ανάμεσα στον agent σχεδιασμού και στον agent υλοποίησης;»

«Βάλτε τον planner να γράψει ένα handoff artifact — διαδρομές αρχείων, αποφάσεις, περιορισμούς. Το session του implementer ξεκινά με έναν pointer προς το artifact και δουλεύει με βάση αυτό».

Ένα handoff artifact που περιγράφει μια εργασία πολλών sessions — τι κατασκευάζεται, όχι πώς συνεισφέρει κάθε session. Ενημερώνεται καθώς προχωρά η εργασία. Αποτελείται από tickets.

Η προδιαγραφή υπάρχει επειδή τα sessions είναι αναλώσιμα, ενώ οι μεγάλες εργασίες όχι. Οτιδήποτε απαιτεί περισσότερη προσπάθεια από ένα context window χρειάζεται έναν χώρο έξω από το context — κάπου στο environment του agent που επιβιώνει από το clearing, είτε πρόκειται για αρχείο στο repo, GitHub issue ή issue tracker στον οποίο έχει πρόσβαση ο agent. Η προδιαγραφή είναι αυτός ο χώρος: ο στόχος, οι περιορισμοί, οι αποφάσεις που έχουν ληφθεί μέχρι στιγμής και η λίστα των tickets μαζί με την κατάστασή τους. Κάθε νέο session μπορεί να τη διαβάσει και να καταλάβει πού βρίσκεται η εργασία, χωρίς να κληρονομήσει τον συσσωρευμένο θόρυβο του προηγούμενου session.

Οι προδιαγραφές έχουν αναγνωρίσιμα ύφη, κυρίως κληρονομημένα από τον τρόπο με τον οποίο οι ομάδες καταγράφουν ήδη τις αποφάσεις τους. Ένα έγγραφο απαιτήσεων προϊόντος (PRD) δίνει έμφαση στο τι και γιατί αφορά τον χρήστη — λειτουργίες, συμπεριφορά, κριτήρια αποδοχής. Ένα έγγραφο σχεδιασμού ή RFC εστιάζει στην τεχνική πλευρά — την επιλεγμένη προσέγγιση, τις εναλλακτικές που απορρίφθηκαν και τους συμβιβασμούς. Στην πιο απλή περίπτωση, ένα αρχείο `plan.md` με λίστα ελέγχου tickets κάνει την ίδια δουλειά για ένα χαρακτηριστικό που εκτείνεται σε πολλά sessions. Το ύφος έχει μικρότερη σημασία από τον ρόλο: για τον agent, καθένα από αυτά είναι το ίδιο πράγμα — η σταθερή δήλωση πρόθεσης που διαβάζει στην αρχή κάθε session.

Παράδειγμα:

«Πρέπει να γίνουν όλα σε ένα session;»

«Όχι, γράψτε μια προδιαγραφή — χωρίστε την σε tickets και εκτελέστε το καθένα σε δικό του session. Αν προσπαθήσετε να κάνετε τα πάντα μέσα σε ένα context, θα φτάσετε στη dumb zone πριν φτάσετε ούτε στη μέση».

Ένα handoff artifact που οριοθετεί ένα session εργασίας. Στέκεται μόνο του ή συνδέεται ως παιδί μιας spec. Τα tickets μπορεί να εμποδίζουν ή να εξαρτώνται από αδελφά tickets, οπότε η σειρά εργασίας προκύπτει από το γράφημα εξαρτήσεων και όχι από ένα γραμμικό πλάνο.

Ο καθοριστικός περιορισμός είναι το μέγεθος: ένα session. Ένα ticket πρέπει να μπορεί να ολοκληρωθεί πριν το session βγει από τη smart zone — και αυτός ο περιορισμός μπορεί να ελεγχθεί. Αν τα sessions των tickets σας υποβαθμίζονται τακτικά πριν τελειώσει η εργασία, τα tickets είναι υπερβολικά μεγάλα· χωρίστε τα. Αν κάθε session αφιερώνει το μεγαλύτερο μέρος του context στη ρύθμιση πριν κάνει πέντε λεπτά δουλειάς, είναι υπερβολικά μικρά· συγχωνεύστε τα.

Ένα καλό ticket γράφεται για αναγνώστη χωρίς κανένα άλλο context. Περιλαμβάνει τον στόχο, τα κριτήρια αποδοχής και context pointers προς τα σχετικά αρχεία και τις αποφάσεις — αρκετά ώστε το session να ξεκινήσει χωρίς να χρειαστεί να ανακαλύψει ξανά όσα γνώριζε το προηγούμενο.

Το γράφημα εξαρτήσεων είναι επίσης αυτό που επιτρέπει την παραλληλοποίηση. Τα ανεξάρτητα tickets — τα φύλλα του γραφήματος — μπορούν να εκτελεστούν ταυτόχρονα, το καθένα στο δικό του session. Αυτός είναι ένας αποτελεσματικός τρόπος να εκτελείτε πολλούς agents παράλληλα. Σε μια software factory, η επισήμανση ενός ticket ως έτοιμου ενεργοποιεί από μόνη της την έναρξη του session του.

Παράδειγμα:

«Από πού ξεκινάω στην προδιαγραφή της μετεγκατάστασης;»

«Κοιτάξτε το γράφημα των tickets — η αλλαγή του σχήματος εμποδίζει την αναπλήρωση των δεδομένων, κι εκείνη εμποδίζει την αλλαγή του API. Επιλέξτε ένα φύλλο και ξεκινήστε ένα session γι’ αυτό».

Ένα handoff που γίνεται στη μνήμη: το ιστορικό του προηγούμενου session συνοψίζεται και η σύνοψη χρησιμοποιείται ως αφετηρία για ένα νέο session. Είναι απωλεστικό εκ σχεδιασμού: το transcript είναι primary source, ενώ η σύνοψη είναι secondary source — θυσιάζει λεπτομέρειες για να εξοικονομήσει χώρο. Ενεργοποιείται χειροκίνητα από τον χρήστη ή αυτόματα μέσω autocompact.

Ο μηχανισμός: το context window έχει πεπερασμένη χωρητικότητα και γεμίζει σε ένα μεγάλο session — κάθε tool result, κάθε αρχείο που διαβάστηκε, κάθε λανθασμένη προσπάθεια παραμένει στο ιστορικό. Όταν αυτό γίνεται βαρύ, το harness ζητά από το model να συνοψίσει το session, απορρίπτει το αρχικό ιστορικό και ξεκινά ένα νέο session με τη σύνοψη. Ό,τι δεν περιλήφθηκε στη σύνοψη χάνεται από το context. Ορισμένα harness το μετριάζουν διατηρώντας το παλιό transcript στον δίσκο και αφήνοντας στη σύνοψη έναν context pointer προς αυτό — η δευτερεύουσα πηγή συνδέεται πίσω με την πρωτογενή, ώστε να ανακτηθεί με νέα ανάγνωση μια λεπτομέρεια που έχασε η σύνοψη.

Η σύνοψη γράφεται από το model, άρα μπορείτε να του δώσετε οδηγίες. Το «Διατήρησε τις αποφάσεις για το σχήμα» κάνει το παραγόμενο artifact πιο προσεκτικό. Σημασία έχει και ο χρόνος: κάντε compact στο όριο μιας φάσης, αφού οριστικοποιηθεί το πλάνο, όχι στη μέση μιας εργασίας.

Σε αντίθεση με το clearing, που απορρίπτει τα πάντα και ξεκινά από την αρχή, το compaction προσπαθεί να μεταφέρει τα ουσιώδη· το clearing βασίζεται στην υπόθεση ότι αυτά έχουν ήδη καταγραφεί κάπου καλύτερα.

Παράδειγμα:

«Το context έχει βαρύνει και πρέπει ακόμη να περάσω τις δοκιμές».

«Κάντε compact πριν ξεκινήσετε — γράψτε στο prompt της σύνοψης τι πρέπει να διατηρηθεί, ώστε το νέο session να κρατήσει τις αποφάσεις για το σχήμα και να αφήσει πίσω την εξερεύνηση».

Compaction που ενεργοποιείται αυτόματα από το harness όταν το context window πλησιάζει να γεμίσει.

Το harness παρακολουθεί πόσο γεμάτο είναι το context window. Όταν ξεπεράσει ένα όριο — συχνά περίπου το 80% — σταματά, ζητά από το model να συνοψίσει το session μέχρι εκείνη τη στιγμή και ξεκινά νέο session με τη σύνοψη. Η εργασία συνεχίζεται σαν να μη συνέβη τίποτα.

Όμως συνέβη κάτι. Το compaction είναι απωλεστικό και το autocompact είναι απωλεστικό σε στιγμή που δεν επιλέξατε. Το χειροκίνητο compact γίνεται στο όριο μιας φάσης, όταν μπορείτε να πείτε στο model τι να διατηρήσει. Το autocompact ενεργοποιείται στη μέση της εργασίας, κάθε φορά που πιάνεται το όριο — ενδεχομένως στα μισά ενός refactor, ενώ η σύνοψη αποφασίζει μόνη της ποιες αποφάσεις σας άξιζε να διατηρήσει. Τυπικό σύμπτωμα: ο agent συνεχίζει με σιγουριά αλλά έχει ξεχάσει σιωπηρά έναν περιορισμό που θέσατε πριν από μία ώρα, και το παρατηρείτε μόνο όταν η δουλειά του αρχίζει να του αντιφάσκει.

Η άμυνα είναι να μην το αφήσετε να ενεργοποιηθεί. Παρακολουθείτε την ένδειξη context και κάνετε compact χειροκίνητα σε φυσικό όριο ή καταγράφετε τις αποφάσεις σε έγγραφο πλάνου ή handoff artifact στον δίσκο, όπου καμία σύνοψη δεν μπορεί να τις χάσει. Τα περισσότερα harness σάς επιτρέπουν επίσης να προσαρμόσετε το περιθώριο — να μετακινήσετε το όριο νωρίτερα ή αργότερα ή να απενεργοποιήσετε εντελώς το autocompact — ώστε να ρυθμίσετε πόσο περιθώριο θέλετε πριν ενεργοποιηθεί.

Παράδειγμα:

«Δεν φαίνεται να θυμάται τι αποφασίσαμε νωρίτερα για το schema».

«Το autocompact ενεργοποιήθηκε ανάμεσα σε turns — οι πρώτες αποφάσεις συνοψίστηκαν και μάλλον χάσαμε κάτι. Ξαναφορτώστε το έγγραφο πλάνου ή την επόμενη φορά κάντε compact χειροκίνητα, ώστε να ελέγχετε εσείς τι διατηρείται».

Ένα σύστημα που επιχειρεί να κάνει έναν agent stateful σε πολλά sessions. Αποθηκεύει πληροφορίες στο environment κατά τη διάρκεια ενός session και τις επαναφορτώνει στο context window στην αρχή μελλοντικών sessions, ώστε ο agent να διατηρεί συνέχεια πέρα από το clearing του session από τον χρήστη.

Ένα σύστημα μνήμης έχει δύο μισά. Η διαδρομή εγγραφής: κατά τη διάρκεια ενός session, ο agent καταγράφει όσα έμαθε — μια προτίμηση που δηλώσατε, ένα γεγονός για το έργο — ως αρχεία στο environment. Η διαδρομή ανάγνωσης: στην αρχή του session, το harness φορτώνει ξανά αυτά τα αρχεία ή ένα ευρετήριό τους στο context window. Πολλά harness περιλαμβάνουν δικό τους σύστημα μνήμης — το `/memory` του Claude Code είναι ένα παράδειγμα — αλλά μπορείτε να κατασκευάσετε κι εσείς ένα: έναν κατάλογο σημειώσεων και μια οδηγία στο AGENTS.md να τον συμβουλεύεται.

Ισχύουν οι ίδιοι συμβιβασμοί όπως για κάθε περιεχόμενο που φορτώνεται πάντα. Οι αναμνήσεις συσσωρεύονται, οπότε τα περισσότερα συστήματα φορτώνουν ένα ευρετήριο μίας γραμμής και αφήνουν τα σώματα πίσω από context pointers αντί να τα ενσωματώνουν όλα. Και οι αναμνήσεις είναι secondary sources, οπότε παλιώνουν: ένα γεγονός που καταγράφηκε τον Μάρτιο φορτώνεται με την ίδια βεβαιότητα τον Ιούνιο, όταν το έργο έχει προχωρήσει. Ένα σύστημα μνήμης χρειάζεται κλάδεμα, όπως και το AGENTS.md.

Παράδειγμα:

«Πρέπει συνεχώς να του ξαναλέω ότι χρησιμοποιώ Postgres, όχι MySQL».

«Συνδέστε ένα σύστημα μνήμης — ας γράφει όσα μαθαίνει στο filesystem στον πρώτο turn και ας τα ξαναφορτώνει στην αρχή του session. Το ίδιο το model είναι stateless· το επίπεδο μνήμης προσποιείται τη συνέχεια».

Ένα αρχείο στο environment που το harness φορτώνει στο context window στην αρχή του session — η πάγια ενημέρωση του έργου προς τον agent. Σύμβαση που ισχύει σε διαφορετικά harness· ορισμένα harness έχουν και δική τους παραλλαγή (του Claude Code είναι το CLAUDE.md).

Επειδή φορτώνεται αυτόματα, είναι ένας τρόπος να μην επαναλαμβάνεστε σε κάθε session. Το model είναι stateless — μια διόρθωση που δίνετε σε ένα session χάνεται στο επόμενο και καταλήγετε να ενημερώνετε κάθε νέο session ότι το έργο χρησιμοποιεί pnpm, ότι τα tests εκτελούνται με μια συγκεκριμένη flag, ότι ένας κατάλογος είναι παραγόμενος και δεν πρέπει να τον αγγίξετε. Όταν έχετε διορθώσει τον agent για το ίδιο πράγμα δύο φορές, αυτή η διόρθωση μπορεί να γίνει γραμμή στο AGENTS.md.

Κατάλληλο περιεχόμενο είναι οτιδήποτε δεν μπορεί να συναγάγει ο agent από τον κώδικα: εντολές build και test, συμβάσεις που δεν είναι προφανείς από το codebase, αυστηροί περιορισμοί («μην επεξεργάζεσαι ποτέ τον generated client»). Να είναι σύντομο και δηλωτικό — είναι ενημέρωση, όχι τεκμηρίωση.

Ο συμβιβασμός είναι ότι όλο το περιεχόμενό του φορτώνεται πάντα. Οι οδηγίες συσσωρεύονται, οι περισσότερες άσχετες με κάθε συγκεκριμένη εργασία, και ένα μεγάλο AGENTS.md κοστίζει tokens και αποδυναμώνει τις ίδιες του τις οδηγίες — όσο περισσότερες υπάρχουν στο context, τόσο λιγότερο αξιόπιστα ακολουθεί το model καθεμία.

Αποφύγετε: να χρησιμοποιείτε το AGENTS.md για περιεχόμενο που πρέπει να progressively disclosed — κάθε γραμμή του κοστίζει ένα token σε κάθε turn, σε κάθε session, είτε χρειάζεται είτε όχι. Ένας οδηγός ύφους μπορεί να βρίσκεται πίσω από ένα skill ή έναν context pointer· κρατήστε στο AGENTS.md μόνο τις γραμμές που ισχύουν παντού.

Παράδειγμα:

«Γιατί κάθε session ξεκινά με 4k tokens ήδη καταναλωμένα;»

«Ελέγξτε το AGENTS.md — κάποιος επικόλλησε εκεί ολόκληρο τον οδηγό ύφους αντί να τον βάλει πίσω από ένα skill».

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

Η τεχνική υπάρχει επειδή το context έχει διπλό κόστος. Κάθε token που φορτώνεται εξαρχής χρεώνεται ως input tokens σε κάθε turn, ενώ καταναλώνει και attention budget, είτε το χρειάζεται ο agent είτε όχι. Ένα AGENTS.md γεμάτο με ολόκληρο τον οδηγό ύφους, το runbook deploy και τις συμβάσεις βάσης δεδομένων κάνει τον agent χειρότερο και στα τρία — οι οδηγίες που έχουν σημασία για την τρέχουσα εργασία αραιώνονται από όσες δεν έχουν. Ενδεικτικό σημάδι είναι ένας agent που αγνοεί κανόνες ενώ γνωρίζετε ότι βρίσκονται στο context του: είναι εκεί, αλλά θαμμένοι.

Η σταδιακή αποκάλυψη αντιστρέφει αυτή τη λογική. Κρατήστε μικρό το επίπεδο που φορτώνεται πάντα — μία πρόταση για κάθε θέμα και έναν pointer προς το σημείο όπου βρίσκεται η λεπτομέρεια. Ο agent διαβάζει τον οδηγό ύφους όταν γράφει component, το runbook deploy όταν κάνει deploy και κανένα από τα δύο όταν διορθώνει ένα test. Τα Skills είναι το μοτίβο που είναι ενσωματωμένο στο harness: μια σύντομη περιγραφή φορτώνεται σε κάθε session, οι πλήρεις οδηγίες μόνο όταν ενεργοποιηθούν.

Παράδειγμα:

«Να βάλω ολόκληρο τον οδηγό ύφους στο AGENTS.md;»

«Όχι — σταδιακή αποκάλυψη. Αναφέρετε τον οδηγό ύφους ως skill που φορτώνει ο agent όταν χρειάζεται πραγματικά να γράψει component. Το AGENTS.md χρεώνει tokens σε κάθε turn».

Μια αναφορά σε ένα έγγραφο που δείχνει σε ένα άλλο, ώστε ο agent να μπορεί να το εισαγάγει στο context window μόνο όταν το απαιτεί η εργασία. Η μονάδα από την οποία αποτελείται το progressive disclosure.

Ο λόγος να χρησιμοποιείτε pointer αντί να ενσωματώνετε το περιεχόμενο είναι το κόστος. Ένας pointer είναι μία γραμμή στο context window. Το έγγραφο στο οποίο οδηγεί μπορεί να έχει χιλιάδες tokens, αλλά αυτά δεν κοστίζουν τίποτα μέχρι ο agent να ακολουθήσει τον pointer. Αν βάλετε ένα runbook 2,000 tokens στο AGENTS.md, κάθε session πληρώνει γι’ αυτό· αντ’ αυτού, γράψτε «διαδικασία deploy: δείτε `internal/deploy.md`» και μόνο τα sessions που κάνουν deploy θα το φορτώσουν. Ο agent ακολουθεί τον pointer με ένα tool call, όταν η εργασία το απαιτεί.

Για να λειτουργήσει ένας pointer, χρειάζεται δύο στοιχεία: σταθερή διαδρομή και αρκετή περιγραφή ώστε ο agent να γνωρίζει πότε αξίζει να τον ακολουθήσει. Μια σκέτη διαδρομή είναι pointer χωρίς λόγο να την ακολουθήσει ο agent· το «δείτε `internal/deploy.md`» χωρίς ένδειξη για το περιεχόμενό του παραλείπεται από ένα session που το χρειαζόταν. Γράψτε τη γραμμή έτσι ώστε να ταιριάζει με τον τρόπο που παρουσιάζονται οι εργασίες: «release, deploy ή rollback — διαβάστε πρώτα το `internal/deploy.md`».

Οι pointers υπάρχουν παντού μόλις αρχίσετε να τους προσέχετε: γραμμές στο AGENTS.md, περιγραφές skill (το harness φορτώνει την περιγραφή· το σώμα του skill παραμένει πίσω από αυτή), ονόματα αρχείων σε καταλόγους, σύνδεσμοι ανάμεσα σε έγγραφα.

Ένας pointer μπορεί επίσης να συνδέσει μια secondary source με την primary source από την οποία προέκυψε — τη σύνοψη compaction που κατονομάζει το αρχικό transcript, το έγγραφο που κατονομάζει το αρχείο πηγής που περιγράφει. Έτσι η απωλεστική φύση της δευτερεύουσας πηγής μπορεί να αντιστραφεί: όταν αποδειχθεί ότι η σύνοψη δεν αρκεί, ο agent ακολουθεί τον pointer και διαβάζει το πρωτότυπο αντί να βασιστεί σε ό,τι διατήρησε η σύνοψη.

Αποφύγετε: «reference» — είναι υπερβολικά στεγνό και δεν μεταφέρει ότι η ακολουθία του φορτώνει περισσότερο context. «Portal» — υπερβολικά πομπώδες.

Παράδειγμα:

«Το AGENTS.md γίνεται τεράστιο».

«Το μεγαλύτερο μέρος του πρέπει να είναι context pointers, όχι περιεχόμενο. Κρατήστε ενσωματωμένους τους κανόνες που ισχύουν πάντα· μετατρέψτε το runbook deploy και τον οδηγό ύφους σε skills και αφήστε πίσω έναν context pointer».

Μια διδακτή δυνατότητα, ομαδοποιημένη ως μονάδα — οδηγίες και πόροι για την αποτελεσματική εκτέλεση μιας εργασίας, που παραμένουν στο environment μέχρι ένας context pointer να τη φέρει στο context window για τη συγκεκριμένη εργασία. Η μονάδα progressive disclosure σε ένα harness.

Τα skills είναι ανοιχτό πρότυπο, ορισμένο στο agentskills.io — αναπτύχθηκαν αρχικά από την Anthropic και υιοθετήθηκαν έκτοτε από τα περισσότερα μεγάλα harness, οπότε ένα skill που γράφεται μία φορά λειτουργεί παντού. Η μορφή είναι ένας φάκελος που περιέχει:

• Ένα αρχείο `SKILL.md` — μεταδεδομένα (τουλάχιστον όνομα και περιγραφή) μαζί με τις ίδιες τις οδηγίες
• Προαιρετικά, scripts που μπορεί να εκτελέσει ο agent
• Προαιρετικά, πρότυπα και υλικό αναφοράς στα οποία παραπέμπουν οι οδηγίες

Από προεπιλογή, μόνο το όνομα και η περιγραφή βρίσκονται στο context. Όταν η εργασία του agent ταιριάζει, φορτώνει το υπόλοιπο skill. Μέχρι τότε, το skill καταλαμβάνει σχεδόν μηδενικό χώρο — μία ή δύο προτάσεις tokens, όσο μεγάλο κι αν είναι το πλήρες σώμα των οδηγιών του.

Αυτό διακρίνει τα skills από το AGENTS.md, το οποίο φορτώνεται σε κάθε session ανεξάρτητα από την εργασία. Ένα skill διαβάζεται όταν προκύψει συγκεκριμένος τύπος εργασίας — release, δημιουργία νέου service, συγγραφή migration — και τις υπόλοιπες φορές αγνοείται.

Αποφύγετε: το «tool» — ένα tool είναι αυτό που καλεί ο agent· ένα skill είναι οδηγίες που διαβάζει.

Παράδειγμα:

«Πού να βάλω το runbook deploy;»

«Ως skill — ο agent το φορτώνει μόνο όταν η εργασία αφορά deploy. Στο AGENTS.md θα έκαιγε tokens σε κάθε turn για κάτι που χρησιμοποιούμε κάθε εβδομάδα».

Ένας agent που ξεκινά ένας άλλος agent μέσω tool call. Εκτελείται στο δικό του session και context window και επιστρέφει ένα μόνο tool result. Διαφέρει από ένα handoff — ο γονικός agent περιμένει συγκεκριμένα απάντηση· ένα handoff δεν έχει διαδρομή επιστροφής. Δεν μπορεί να ξεκινήσει επιπλέον subagents — το δέντρο έχει μόνο ένα επίπεδο. Οι subagents υπάρχουν για να απομονώνουν το context, όχι για να δημιουργούν ιεραρχίες.

Σκοπός είναι να κρατούν θορυβώδη εργασία έξω από το context του γονικού agent. Μια ευρεία αναζήτηση ή μια μακρά εξερεύνηση αρχείων παράγει σελίδες αποτελεσμάτων εργαλείων, τα περισσότερα από τα οποία έχουν σημασία μόνο μέχρι να βρεθεί η απάντηση. Αν εκτελεστούν μέσα στον γονικό agent, όλα παραμένουν στο context του για το υπόλοιπο session. Αν εκτελεστούν σε subagent, ο θόρυβος γεμίζει ένα αναλώσιμο παράθυρο αντί γι’ αυτό — στο context του γονικού φτάνει μόνο η τελική αναφορά. Η αναφορά είναι secondary source: ο γονικός agent λαμβάνει την περιγραφή του subagent για όσα βρήκε, όχι τα πρωτογενή αποτελέσματα, άρα ό,τι παραλείπει η αναφορά είναι αόρατο στον γονικό.

Οι subagents εκτελούνται επίσης ταυτόχρονα — ο γονικός agent μπορεί να αναθέσει παράλληλα πολλές ανεξάρτητες εργασίες.

Παράδειγμα:

«Τα αποτελέσματα του grep γεμίζουν το context μου».

«Ξεκίνα έναν subagent για την αναζήτηση — θα ξοδέψει το δικό του context window στον θόρυβο και θα σου αναφέρει τις δύο διαδρομές αρχείων που χρειάζεσαι».

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

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

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

Ορισμένες εργασίες απαιτούν από τη φύση τους συμμετοχή στον βρόχο, επειδή οι αντιδράσεις σας είναι η είσοδος. Το Grilling λειτουργεί μόνο όταν είστε εκεί για να απαντήσετε στις ερωτήσεις· το prototyping λειτουργεί μόνο όταν είστε εκεί για να αντιδράσετε στο artifact.

Η παραμονή στον βρόχο κοστίζει την προσοχή σας, που είναι ο σπάνιος πόρος. Μέρος της καλύτερης χρήσης των agents είναι να μεταφέρετε με ασφάλεια περισσότερη δουλειά έξω από τον βρόχο — με πλάνα, automated checks και human review στο τέλος αντί για συνεχή επίβλεψη. Μια software factory το προχωρά περισσότερο ξεκινώντας sessions από triggers, ώστε να μη χρειάζεται να ξεκινήσετε εσείς ούτε την ίδια την εργασία.

Παράδειγμα:

«Να το τρέξω AFK όλη τη νύχτα;»

«Όχι, είναι μετεγκατάσταση σχήματος — κράτησέ το με άνθρωπο στον βρόχο. Θέλω να βλέπω κάθε βήμα και να το κατευθύνω αν επιλέξει λάθος στήλη για την αναπλήρωση».

Away from keyboard. Ένα μοτίβο εργασίας όπου ο χρήστης ξεκινά ένα session και αφήνει τον agent να εκτελείται χωρίς επίβλεψη. Ο πολλαπλασιαστής απόδοσης του προγραμματισμού με AI — πολλά sessions AFK μπορούν να εκτελούνται παράλληλα όσο κοιμάστε, τρώτε ή ασχολείστε με κάτι άλλο. Συνήθως απαιτείται επιτρεπτικό permission mode μαζί με sandboxing για ασφάλεια.

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

Αφού δεν μπορείτε να δώσετε πληροφορίες στη διάρκεια της εκτέλεσης, δώστε τις πριν και μετά. Πριν: επιλύστε εξαρχής την ασάφεια — ένα session grilling, μια γραπτή spec — ώστε να υπάρχουν λιγότερα κενά για να συμπληρώσει μόνος του ο agent. Κατά τη διάρκεια: τα automated checks και η automated review αντικαθιστούν την προσοχή που δεν παρέχετε, αποτυγχάνοντας γρήγορα στα προβλήματα που μπορούν να εντοπιστούν μηχανικά. Μετά: η εκτέλεση ολοκληρώνεται με κάτι που μπορεί να εξεταστεί — ένα PR, όχι αλλαγές που έχουν ήδη συγχωνευτεί. Το AFK δεν αφαιρεί την human review· τη μεταθέτει ολόκληρη στο τέλος, γι’ αυτό ό,τι φτάνει εκεί πρέπει να αξίζει την ανασκόπηση. Γι’ αυτό το AX έχει τη μεγαλύτερη σημασία στις εκτελέσεις AFK — χωρίς κανέναν να παρακολουθεί, το environment είναι η μόνη υποστήριξη που έχει ο agent.

Αποφύγετε: «background agent» — εστιάζει στο μηχάνημα («εκτελείται στο παρασκήνιο») αντί στο μοτίβο του ανθρώπου («ο χρήστης έχει απομακρυνθεί»). Το AFK κατονομάζει το σημαντικό γεγονός: ο χρήστης δεν παρακολουθεί.

Παράδειγμα:

«Το εκτελώ AFK — τρεις agents σε sandbox κάνουν refactor, θα εξετάσω τα PR το πρωί».

«Bypass permissions;»

«Ναι, filesystem μόνο για ανάγνωση, χωρίς δίκτυο».

Μια ντετερμινιστική επαλήθευση που εκτελείται στο environment — tests, έλεγχοι τύπων, lints, build, pre-commit hooks. Επιτυχία ή αποτυχία, χωρίς κρίση. Το σήμα από το οποίο ένας agent μπορεί να αυτοδιορθωθεί χωρίς να εμπλέξει κανέναν άλλον. Ένα ασταθές test είναι χαλασμένος έλεγχος, όχι απουσία ελέγχου· οι automated checks είναι ντετερμινιστικοί εκ σχεδιασμού.

Η αυτοδιόρθωση λειτουργεί ως βρόχος. Ο agent κάνει μια αλλαγή, εκτελεί τον έλεγχο ως tool call και το αποτέλεσμα της αποτυχίας εμφανίζεται στο context window — ένα σφάλμα τύπων με αρχείο και γραμμή, μια αποτυχημένη assertion με αναμενόμενες και πραγματικές τιμές. Αυτά αρκούν για να διορθώσει ο agent το πρόβλημα και να ξανατρέξει τον έλεγχο, επαναλαμβάνοντας τη διαδικασία μέχρι να περάσει, χωρίς άνθρωπο στον βρόχο. Ο ντετερμινισμός κάνει τον βρόχο αξιόπιστο: ο ίδιος κώδικας δίνει πάντα την ίδια ετυμηγορία, άρα η επιτυχία σημαίνει κάτι. Ένας ασταθής έλεγχος δηλητηριάζει αυτή τη διαδικασία — ο agent «διορθώνει» κώδικα που ήταν εντάξει ή επαναλαμβάνει τον έλεγχο μέχρι να παρακάμψει μια πραγματική αποτυχία.

Γι’ αυτό οι καλοί έλεγχοι αποτελούν μεγάλο μέρος του AX μιας βάσης κώδικα. Ένας agent σε repo με αυστηρούς τύπους, γρήγορη σουίτα tests και linter εντοπίζει τα περισσότερα λάθη του πριν τα δείτε· ένας agent σε repo χωρίς αυτά παραδίδει ό,τι παράγει. Η διαφορά έχει τη μεγαλύτερη σημασία σε εκτελέσεις AFK, όπου οι έλεγχοι είναι η μόνη επαλήθευση κατά τη διάρκεια της εκτέλεσης. Όμως ένας έλεγχος εντοπίζει μόνο όσα ελέγχει ρητά — οι πράσινοι έλεγχοι σημαίνουν ότι ισχύουν οι δηλωμένες ιδιότητες, όχι ότι ο κώδικας είναι σωστός. Τα κενά που απαιτούν κρίση καλύπτονται από την automated review και την human review.

Αποφύγετε: «feedback loop» / «backpressure» — και οι δύο όροι συγχωνεύουν τους ελέγχους με την ανασκόπηση. Αποφύγετε: «test» — τα tests είναι automated checks, αλλά δεν είναι όλοι οι automated checks tests.

Παράδειγμα:

«Ο agent συνεχίζει να παραδίδει χαλασμένο κώδικα στις εκτελέσεις AFK».

«Ποιοι automated checks είναι συνδεδεμένοι στο sandbox;»

«Μόνο τα unit tests».

«Προσθέστε typecheck και lint — θα αυτοδιορθώνεται βάσει αυτών πριν καν φτάσει το PR».

Ένας agent που εξετάζει τη δουλειά ενός άλλου agent, συχνά με διαφορετικό model ή system prompt. Είναι μη ντετερμινιστική: σχηματίζει κρίση. Μπορεί να εκτελείται οπουδήποτε — πριν από το merge ενός PR, εκ των υστέρων στο ιστορικό commits ή στη μέση ενός session ως subagent. Ένα LLM που λειτουργεί ως κριτής στο CI είναι automated review, όχι automated check· την κατηγορία την καθορίζει το τι κάνει ο έλεγχος, όχι το πού εκτελείται.

Ο διαχωρισμός από τον agent που εργάζεται είναι αυτός που το κάνει να λειτουργεί. Το να ζητήσετε από τον agent που έγραψε τον κώδικα να εξετάσει τη δική του δουλειά αποδίδει ελάχιστα — το session που παρήγαγε το σφάλμα περιέχει και το σκεπτικό που οδήγησε σε αυτό, και ο agent διαβάζει τα δικά του συμπεράσματα ως επιβεβαίωση. Ένας reviewer με νέο context window δεν έχει αυτή την προσκόλληση: βλέπει το diff όπως θα το έβλεπε ένας ξένος, κι αυτό είναι που χρειάζεται η ανασκόπηση. Διαφορετικό model ή system prompt ειδικά για ανασκόπηση το βελτιώνει περισσότερο — διαφορετικά τυφλά σημεία και system prompt προσαρμοσμένο σε όσα πραγματικά σας ενδιαφέρουν (ασφάλεια, συμβόλαια API, απόδοση) αντί για ένα αόριστο «ψάξε για προβλήματα».

Τοποθετείται ανάμεσα στα άλλα επίπεδα ανασκόπησης. Οι automated checks είναι ντετερμινιστικοί και εντοπίζουν όσα μπορούν να δηλωθούν μηχανικά· η human review κοστίζει ακριβά και κλιμακώνεται χειρότερα. Η automated review βρίσκεται στη μέση: εντοπίζει προβλήματα που απαιτούν κρίση — παραπλανητικό όνομα συνάρτησης, παραλειπόμενη οριακή περίπτωση — με κόστος μηχανής. Επειδή είναι μη ντετερμινιστική, μπορεί να παραλείψει προβλήματα και να επισημάνει μη προβλήματα· αντιμετωπίστε την ως φίλτρο που ανεβάζει το ελάχιστο επίπεδο πριν εξετάσει την αλλαγή άνθρωπος, όχι ως φραγμό που αντικαθιστά τον άνθρωπο.

Αποφύγετε: «AI review» / «agent review» — είναι υπερβολικά αόριστα για να ξεχωρίσουν από τον ίδιο τον agent που εργάζεται.

Παράδειγμα:

«Μας έρχονται πάρα πολλά κακά PR από τις εκτελέσεις AFK».

«Προσθέστε ένα βήμα automated review πριν από το merge — διαφορετικό model, ξεχωριστό system prompt, εστίαση σε αλλαγές ασφάλειας και συμβολαίων».

Ο χρήστης διαβάζει τον κώδικα που παρήγαγε ο agent και σχηματίζει κρίση γι’ αυτόν. Η ανάγνωση του diff ή των αλλαγμένων αρχείων μετρά· η ανάγνωση της περιγραφής του agent για όσα έκανε δεν μετρά — η αφήγηση δεν είναι το artifact. Η περιγραφή είναι secondary source, γραμμένη από το μέρος που εξετάζεται· το diff είναι η primary source και η ανασκόπηση σημαίνει ότι το διαβάζετε.

Οι agents αυξάνουν τον όγκο παραγόμενου κώδικα, οπότε η ανασκόπηση γίνεται το σημείο συμφόρησης. Μια χρήσιμη ιδέα είναι ο συνδυασμός διαφορετικών στρατηγικών ανασκόπησης. Τα Automated checks εντοπίζουν τις μηχανικές αστοχίες, η automated review εντοπίζει όσες μπορούν να περιγραφούν και η ανθρώπινη ανασκόπηση επιφυλάσσεται για όσα μόνο εσείς μπορείτε να κρίνετε — αν η αλλαγή είναι η σωστή, αν η προσέγγιση ταιριάζει στο codebase, αν θα έπρεπε να υπάρχει εξαρχής.

Η ανασκόπηση κοστίζει επίσης λιγότερο όταν γίνεται νωρίτερα. Η ανάγνωση πλάνου πριν αρχίσει η εργασία ή ενός μικρού diff στη διάρκειά της παίρνει λεπτά· η ανασκαφή σε ολοκληρωμένο branch μετά από εκτέλεση AFK παίρνει περισσότερο. Το σημείο ελέγχου της ανασκόπησης είναι απόφαση human-in-the-loop, όχι εκ των υστέρων σκέψη.

Αποφύγετε: το σκέτο «code review» — είναι αμφίσημο ανάμεσα σε ανθρώπινη και αυτοματοποιημένη ανασκόπηση.

Παράδειγμα:

«Έκανα ανθρώπινη ανασκόπηση του αποτελέσματος AFK».

«Διάβασες το diff ή μόνο τη σύνοψη;»

«Το diff. Η σύνοψη έλεγε ότι διέγραψε νεκρό κώδικα — αποδείχθηκε ότι τη συνάρτηση καλούσε ένα generated αρχείο».

Ένα μοτίβο εργασίας όπου ο χρήστης αποδέχεται τον κώδικα του agent χωρίς human review. Το diff αντιμετωπίζεται ως αδιαφανές — σημασία έχει αν το πρόγραμμα συμπεριφέρεται σωστά, όχι τι περιέχει. Μπορεί και πάλι να εκτελούνται automated review και automated checks· το vibe coding δεν παίρνει θέση για κανένα από τα δύο.

Ο όρος προέρχεται από τον Andrej Karpathy, που τον καθιέρωσε στις αρχές του 2025: «παραδίνεσαι πλήρως στα vibes» και «ξεχνάς ότι ο κώδικας υπάρχει» — περιγράφεις τι θέλεις, αποδέχεσαι αυτό που επιστρέφεται και το κρίνεις εκτελώντας το.

Το vibe coding ανταλλάσσει την επιθεώρηση με την ταχύτητα. Η ανάγνωση diff είναι συνήθως το πιο αργό βήμα στην εργασία με agents, άρα η παράλειψή της αφαιρεί το κύριο σημείο συμφόρησης. Για κώδικα του οποίου οι αστοχίες κοστίζουν λίγο — prototypes, εφάπαξ scripts, εσωτερικά εργαλεία — αυτός είναι εύλογος συμβιβασμός. Ο κίνδυνος αυξάνεται ανάλογα με τη διάρκεια ζωής και τη σημασία του κώδικα.

Το κόστος εμφανίζεται αργότερα. Οι αλλαγές που έγιναν με vibe coding συσσωρεύονται σε μια βάση κώδικα που κανείς δεν έχει διαβάσει, ενώ ελέγχθηκε μόνο η συμπεριφορά — έτσι οτιδήποτε δεν αποκαλύπτει η συμπεριφορά, όπως ένα μυστικό που γράφεται στα logs, μια παραλειπόμενη οριακή περίπτωση ή ένας διακριτικά λανθασμένος χειρισμός δεδομένων, περνά απαρατήρητο. Η πρώτη φορά που κάποιος αποσφαλματώνει το σύστημα είναι και η πρώτη φορά που κάποιος διαβάζει τον κώδικα. Αφού έχει αφαιρεθεί η ανθρώπινη ανασκόπηση, όποια αυτοματοποιημένη επαλήθευση απομένει — tests, τύποι, automated review — είναι ο μόνος φραγμός που πρέπει να περάσει ο κώδικας. Η ίδια στάση εφαρμοσμένη σε ολόκληρη βάση κώδικα ή τμήμα της, όπου οι αλλαγές προέρχονται από software factory, είναι dark factory.

Αποφύγετε: τη χρήση του «vibe coding» ως συνώνυμου του «προγραμματισμού με AI χαμηλής ποιότητας» — ο όρος ονομάζει τη στάση απέναντι στην ανασκόπηση, όχι την ποιότητα του κώδικα που προκύπτει.

Παράδειγμα:

«Διάβασες τι άλλαξε στη ροή ελέγχου ταυτότητας;»

«Έκανα vibe coding — το login εξακολουθεί να λειτουργεί, αυτό μόνο έλεγξα».

«Διάβασε το diff πριν κάνεις push· το vibe coding στον έλεγχο ταυτότητας είναι ο τρόπος να διαρρεύσουν μυστικά στα logs».

Η κοινή κατανόηση του τι κατασκευάζεται, την οποία μοιράζονται ο χρήστης και ο agent, αλλά διατηρούν χωριστά από οποιοδήποτε artifact. Όρος του Brooks (The Design of Design): η συνομιλία, τα handoff artifacts και ο κώδικας είναι όλα artifacts που προσπαθούν να αποτυπώσουν ή να προσεγγίσουν τη σχεδιαστική ιδέα, αλλά κανένα τους δεν είναι η ίδια. Η ποιότητα της σχεδιαστικής ιδέας γίνεται αισθητή μέσω της ποιότητας της συνομιλίας που τη διαμόρφωσε.

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

Μπορείτε να καταλάβετε ότι μια σχεδιαστική ιδέα είναι κοινή όπως και με έναν συνάδελφο: το άλλο μέρος αρχίζει να απαντά στις ερωτήσεις που δεν έχετε κάνει ακόμη με τον τρόπο που θα απαντούσατε εσείς. Μέχρι τότε, η εργασία είναι συζήτηση — το grilling είναι η σκόπιμη εκδοχή του — και η πρόωρη συγγραφή spec απλώς αποτυπώνει την ασυμφωνία σε πιο μόνιμο artifact. Η σχεδιαστική ιδέα επίσης μεταβάλλεται καθώς μαθαίνετε· τα artifacts μένουν πίσω, γι’ αυτό μια spec πιστή στην κατανόηση της προηγούμενης εβδομάδας μπορεί ακόμη να παραπλανήσει το session αυτής της εβδομάδας.

Παράδειγμα:

«Γράφει ακριβώς ό,τι ζήτησα και πάλι είναι λάθος».

«Δεν έχετε ακόμη κοινή σχεδιαστική ιδέα — συμπληρώνει τα κενά με υποθέσεις. Συνεχίστε να μιλάτε μέχρι να συμφωνήσετε για ακυρώσεις, επιστροφές χρημάτων και μερική εκπλήρωση παραγγελιών, πριν τον αφήσετε να γράψει spec».

Μια τεχνική ανάπτυξης μιας design concept με έναν agent: ο agent παίρνει συνέντευξη από τον χρήστη με σωκρατικό τρόπο, μία απόφαση τη φορά, προτείνοντας μια συνιστώμενη απάντηση για καθεμία. Επιβραδύνει τη βιασύνη για ολοκλήρωση του πλάνου — δεν γράφεται handoff artifact μέχρι να σταθεροποιηθεί η ιδέα.

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

Είναι τεχνική human-in-the-loop: οι απαντήσεις σας είναι η είσοδος. Όταν μια ερώτηση δεν μπορεί να απαντηθεί μέσα στη συζήτηση — πρέπει να δείτε το ίδιο το πράγμα — μεταβείτε στο prototyping.

Παράδειγμα:

«Πήγε κατευθείαν να γράψει την spec και έκανε λάθος στη λογική ακύρωσης».

«Κάντε πρώτα grilling — βάλτε τον να ρωτήσει για μερικές ακυρώσεις, επιστροφές χρημάτων και χρονισμό πριν δεσμεύσει οτιδήποτε στο έγγραφο. Είναι φθηνότερο να λυθούν στη συζήτηση παρά στον κώδικα».

Να ζητήσετε από τον agent να κατασκευάσει γρήγορα μια πρόχειρη εκδοχή κάποιου πράγματος, όταν η συζήτηση δεν είναι αρκετά ακριβής και χρειάζεστε ένα πραγματικό artifact για να συζητήσετε γύρω από αυτό.

Το Grilling επιλύει αποφάσεις σχεδιασμού μέσα από συζήτηση. Η συζήτηση είναι φθηνή, αλλά δεν έχει μεγάλη πιστότητα: ορισμένες ερωτήσεις δεν απαντώνται με λόγια — πώς σας φαίνεται μια αλληλεπίδραση, αν ένα σχήμα API είναι πρακτικό σε πραγματικό κώδικα που το καλεί, αν η διάταξη λειτουργεί με πραγματικά μεγέθη δεδομένων. Η συνέντευξη φτάνει σε μια ερώτηση και η ειλικρινής σας απάντηση είναι «δεν ξέρω, θα έπρεπε να το δω». Από εκεί και πέρα η συζήτηση κάνει κύκλους. Αντί γι’ αυτό, ζητήστε από τον agent να κατασκευάσει το πράγμα, δείτε το και επιστρέψτε στη συζήτηση με απάντηση.

Οι agents μειώνουν το κόστος κατασκευής, κι αυτό κάνει πρακτική αυτή την προσέγγιση. Μια πρόχειρη έκδοση που παλαιότερα απαιτούσε μια μέρα για να δημιουργηθεί ως mockup τώρα φτιάχνεται σε λεπτά, οπότε αξίζει να γίνεται τακτικά. Είναι τεχνική human-in-the-loop: το prototype υπάρχει για να αντιδράσετε σε αυτό.

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

Ένα prototype δεν χρειάζεται να είναι όλο πρόχειρο. Μπορείτε να κατασκευάσετε τα κομμάτια που αξιολογείτε με ποιότητα παραγωγής, ώστε όταν ληφθεί η απόφαση, το component ή το API στο οποίο αντιδράσατε να μεταφερθεί στο πραγματικό codebase. Γι’ αυτό το prototyping είναι απαραίτητο υλικό για την spec.

Παράδειγμα:

«Έχουμε περάσει μισή ώρα διαφωνώντας αν ο οδηγός βημάτων πρέπει να είναι μία σελίδα ή τρία βήματα».

«Δεν θα το λύσουμε με λόγια — ζήτησε από τον agent να φτιάξει prototype και των δύο εκδοχών. Θα τις δοκιμάσουμε και σε πέντε λεπτά θα ξέρουμε».

Εμπειρία προγραμματιστή — πόσο εύκολη κάνουν μια βάση κώδικα και η αλυσίδα εργαλείων της την καλή δουλειά για τους ανθρώπους. Το καλό DX σημαίνει γρήγορη ανατροφοδότηση, σαφή μηνύματα σφάλματος, τεκμηρίωση που απαντά στην πραγματική ερώτηση και ρύθμιση που λειτουργεί με την πρώτη προσπάθεια. Ο όρος προϋπήρχε πολύ του προγραμματισμού με AI· βρίσκεται κυρίως εδώ ως αντίστιξη στο AX.

Το DX αφορά την αλληλεπίδραση ανθρώπου και codebase — τίποτα περισσότερο. Η κύρια διαφορά ανάμεσα στα δύο κοινά είναι ότι οι άνθρωποι είναι stateful, ενώ οι agents stateless. Ένας άνθρωπος μαθαίνει το codebase μία φορά και μεταφέρει αυτή τη γνώση σε κάθε επόμενη μέρα, γι’ αυτό το κακό DX είναι ανεκτό: παρακάμπτει το αργό CI ομαδοποιώντας τα push, την έλλειψη docs ρωτώντας μία φορά στο Slack, τη μπερδεμένη δομή θυμούμενος πού βρίσκεται τι. Οι παρακάμψεις συσσωρεύονται και η ομάδα καταλήγει παραγωγική μέσα σε ένα codebase που της αντιστέκεται.

Οι Agents αντιμετωπίζουν το ίδιο codebase χωρίς καμία τέτοια συσσώρευση. Επειδή ένας agent είναι stateless μεταξύ sessions, ξαναμαθαίνει το codebase από την αρχή κάθε φορά — επωφελείται από τη γρήγορη σουίτα tests και τα σαφή μηνύματα σφάλματος, αλλά οτιδήποτε κατάλαβε χθες έχει χαθεί, εκτός αν γράφτηκε στο environment, το οποίο ο agent αντιλαμβάνεται μόνο μέσω tool results. Αυτό είναι το κενό που ονομάζει το AX: τα μέρη του DX που παραμένουν όταν ο developer είναι agent, καθώς και ζητήματα που δεν απασχολούν τους ανθρώπους, όπως η διατήρηση ελεύθερου context window.

Η επικάλυψη σημαίνει ότι οι επενδύσεις στο DX συχνά βελτιώνουν δωρεάν το AX — αυστηροί τύποι, γρήγορα tests και προβλέψιμη δομή βοηθούν και τα δύο κοινά. Η απόκλιση σημαίνει ότι αυτό δεν ισχύει πάντα: ένα όμορφο έγγραφο εισαγωγής βοηθά έναν άνθρωπο για μια εβδομάδα, αλλά καθόλου έναν agent αν δεν μπορεί να το βρει μέσω του AGENTS.md.

Παράδειγμα:

«Το DX μας είναι μια χαρά — οι νέες προσλήψεις γίνονται παραγωγικές σε μία εβδομάδα».

«Παραγωγικές επειδή κάποιος δουλεύει μαζί τους όλη εκείνη την εβδομάδα. Ο agent δεν έχει αυτή την εβδομάδα· αξιολογήστε χωριστά το AX».

Εμπειρία agent — πόσο καλά έχει ρυθμιστεί το environment, ώστε ένας agent να κάνει καλή δουλειά σε ένα codebase. Το αντίστοιχο της εμπειρίας του agent από το DX. Όταν ο ίδιος agent αποδίδει καλά σε ένα repo και άσχημα σε άλλο — ίδιο model, ίδιο harness — η διαφορά συνήθως είναι το AX. Η πρώτη αντίδραση είναι να κατηγορήσετε το model ή να ξαναγράψετε το prompt· συχνότερα η λύση βρίσκεται στο repo.

Το καλό AX έχει τρεις κύριες διαστάσεις:

Το AX και το DX αλληλεπικαλύπτονται — οι καλοί έλεγχοι και η καθαρή αρχιτεκτονική βοηθούν και τα δύο κοινά — αλλά διαφέρουν. Οι άνθρωποι ανέχονται άτυπη γνώση, αργό CI και το «ρώτα τη Sarah για τη μονάδα χρέωσης»· οι agents όχι. Οι agents δεν ωφελούνται από tooltips IDE ή όμορφα dashboards· χρειάζονται αποτυχίες ως κείμενο σε tool result. Ένα codebase μπορεί να έχει καλό DX και κακό AX.

Αποφύγετε: να αντιμετωπίζετε το AX ως συνώνυμο του DX — τα δύο κοινά χρειάζονται διαφορετικές επενδύσεις.

Παράδειγμα:

«Ο agent γράφει εξαιρετικό κώδικα στο repo του API και απαράδεκτο στο frontend».

«Το repo του API έχει αυστηρούς τύπους και γρήγορη σουίτα tests· το frontend δεν έχει ούτε το ένα ούτε το άλλο και έχει σαράντα skills που φορτώνονται πάντα. Αυτό είναι κενό AX, όχι πρόβλημα model».

Ένα σύστημα εργασίας όπου τα agent sessions ξεκινούν από triggers — τη δημιουργία ενός issue, ένα χρονοδιάγραμμα, μια αποτυχία CI, την ολοκλήρωση ενός άλλου session — αντί να ξεκινούν από άνθρωπο, ώστε περισσότερη δουλειά να εκτελείται AFK και η ανθρώπινη προσοχή να αφιερώνεται στις αποφάσεις human-in-the-loop που απομένουν.

Χωρίς εργοστάσιο, κάθε session ξεκινά επειδή το ξεκίνησε κάποιος. Ακόμη κι αν η εργασία εκτελείται εξ ολοκλήρου AFK, περιμένει έναν άνθρωπο να ανοίξει το session, να το κατευθύνει στο ticket και να το θέσει σε λειτουργία. Οι ομάδες θέλουν να παραδίδουν περισσότερο έργο από όσο επιτρέπει αυτό. Ένα εργοστάσιο αφαιρεί τον άνθρωπο από την εκκίνηση των sessions, όχι κατ’ ανάγκη από οτιδήποτε άλλο.

Συνηθισμένα triggers και τα sessions που ξεκινούν:

Ένα εργοστάσιο δεν χρειάζεται να καλύπτει ολόκληρη τη διαδικασία ανάπτυξης λογισμικού. Μία cron εργασία που εκτελεί έναν τύπο session και ανοίγει ένα PR κατάλληλο για ανασκόπηση είναι εργοστάσιο. Είναι χρήσιμο να ξεκινήσετε μικρά: ένας στενός βρόχος παράγει μικρά, παρόμοια PR και η ανασκόπησή τους δείχνει πόσο μπορείτε να εμπιστευθείτε τον βρόχο πριν τον διευρύνετε.

Οι άνθρωποι μπορούν να βρίσκονται οπουδήποτε μέσα σε ένα εργοστάσιο — να γράφουν και να επισημαίνουν τα issues που ενεργοποιούν sessions, να εγκρίνουν ένα πλάνο πριν αρχίσει η υλοποίηση, να κάνουν human review πριν από τη συγχώνευση. Το κύριο ερώτημα σχεδιασμού είναι ποιες από αυτές τις αποφάσεις θα παραμείνουν ανθρώπινες. Μια βάση κώδικα, ή τμήμα της, όπου κανένας άνθρωπος δεν εξετάζει το αποτέλεσμα του εργοστασίου είναι dark factory.

Παράδειγμα:

«Ποιος διόρθωσε όλες τις παραβάσεις `no-floating-promises`;»

«Το εργοστάσιο. Η cron εργασία επιλέγει έναν κανόνα lint κάθε βράδυ και ανοίγει PR. Εγώ απλώς το εξετάζω το πρωί».

Μια βάση κώδικα, ή τμήμα της, όπου μια software factory γράφει τον κώδικα και κανένας άνθρωπος δεν τον διαβάζει. Δεν υπάρχει human review. Οι άνθρωποι μπορούν ακόμη να γράφουν τα issues που ξεκινούν την εργασία, αλλά κανείς δεν διαβάζει τον κώδικα που παράγεται. Η ονομασία προέρχεται από τα «lights-out» εργοστάσια, που κατασκευάζουν προϊόντα χωρίς ανθρώπους στο δάπεδο παραγωγής.

Ένα dark factory είναι vibe coding για μια περιοχή κώδικα, όχι για μία αλλαγή. Όταν κάνετε vibe coding, επιλέγετε να μη διαβάσετε μια αλλαγή που ζητήσατε. Όμως γνωρίζετε ότι η αλλαγή υπάρχει. Σε ένα dark factory, η ομάδα κάνει αυτή την επιλογή μία φορά για ολόκληρη την περιοχή. Μετά από αυτό, κανείς δεν ζητά έγκριση για κάθε αλλαγή ούτε τη βλέπει. Οι αλλαγές φτάνουν τόσο γρήγορα όσο ξεκινούν νέες εργασίες τα triggers.

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

Οι automated checks και η automated review είναι οι μόνοι φραγμοί. Αν δεν εντοπίσουν πρόβλημα, αυτό περνά στον κώδικα.

Αποφύγετε: να αποκαλείτε μια βάση κώδικα «dark» μόνο και μόνο επειδή το εργοστάσιο λειτουργεί χωρίς κανείς να το παρακολουθεί. Αν τα agent sessions εκτελούνται AFK και ένας άνθρωπος εξετάζει τα PR τους, αυτό είναι software factory. Δεν είναι dark factory.

Παράδειγμα:

«Ποιος άλλαξε τη λογική των επαναλήψεων στο billing service; Κανείς στην ομάδα δεν το θυμάται».

«Το billing service είναι dark factory. Οι agents συγχωνεύουν όλες τις αλλαγές που περνούν το CI. Κανείς δεν διάβασε αυτή την αλλαγή».