Codex και ροή εργασιών πολλαπλών πρακτόρων: εργαστείτε με πράκτορες χωρίς να χάσετε τον έλεγχο
· 7 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Την πρώτη φορά που ένας παράγοντας κωδικοποίησης επιδιορθώνει πραγματικά ένα σφάλμα για εσάς, η αντίδραση είναι σχεδόν πάντα η ίδια: ένα μείγμα ενθουσιασμού και καχυποψίας. Ωραίο, σίγουρα. Αλλά μετά κοιτάς τη διαφορά και αναρωτιέσαι: "Εντάξει, αλλά τι ακριβώς άγγιξε; Μπορώ να τον εμπιστευτώ; Θα το κάνει ξανά με τον ίδιο τρόπο αύριο;".
Εκεί νομίζω αρχίζει το ενδιαφέρον κομμάτι. Όχι όταν ο πράκτορας γράφει μια συνάρτηση, αλλά όταν γίνεται αρκετά ικανός να αναλάβει ολόκληρα κομμάτια εργασίας: διαβάστε το αποθετήριο, δημιουργήστε μια ενημέρωση κώδικα, εκτελέστε δοκιμές, ανοίξτε ένα PR, επιστρέψτε μετά από ένα σχόλιο αξιολόγησης. Το Codex κινείται ακριβώς προς αυτή την κατεύθυνση: εργασία στο παρασκήνιο, ξεχωριστά δέντρα εργασίας, ενσωματωμένο πρόγραμμα περιήγησης, αυτοματισμοί, πρόσθετα, μνήμη και πιο συγκεκριμένα στοιχεία ελέγχου αδειών.
Το θέμα δεν είναι να φανταστεί κανείς ένα μέλλον όπου κανείς δεν διαβάζει πια κώδικα. Θα ήταν ένα τρομερό μέλλον, καθώς και αρκετά αφελές. Το θέμα είναι να καταλάβουμε πώς να συνεργαστείτε με πράκτορες που μπορούν να κάνουν πολλά χωρίς να τους αφήσουν να κάνουν τα πάντα.
Η αλλαγή συνήθειας
Με την παραδοσιακή αυτόματη συμπλήρωση ήσασταν πάντα στο τιμόνι. Το AI πρότεινε μια γραμμή, αποφασίσατε. Με έναν ατζέντη, όμως, η σχέση αλλάζει: του δίνεις έναν στόχο και περνάει από πολλά βήματα μόνος του.
Αυτό είναι ισχυρό, αλλά μετατοπίζει το πρόβλημα. Το ερώτημα δεν είναι πλέον μόνο «μπορεί το μοντέλο να προγραμματίσει;». Το ερώτημα γίνεται:
- Του έδωσα αρκετά μικρό πεδίο εφαρμογής;
- ξέρετε πώς να ελέγξετε το αποτέλεσμα;
- Εργάζομαι σε απομονωμένο περιβάλλον;
- Η τελική αναθεώρηση εξακολουθεί να είναι ανθρώπινη και προσεκτική;
Μια υγιής ροή εργασίας μοιάζει περισσότερο με αυτό παρά με ένα μαγικό ραβδί:
Ακούγεται λιγότερο ρομαντικό από το "ο πράκτορας χτίζει τα πάντα", αλλά λειτουργεί πολύ καλύτερα. Και είναι επίσης ο τρόπος με τον οποίο λειτουργούν οι ομάδες που είναι καλές με τους ανθρώπους: ξεκάθαρες εργασίες, γρήγορη ανατροφοδότηση, ρητή ευθύνη.
Η καλή προτροπή είναι σχεδόν ένα καλό εισιτήριο
Η πιο επικίνδυνη προτροπή είναι η ασαφής αλλά σίγουρη: "διορθώστε τη σελίδα τιμολογίων", "βελτίωση της αρχιτεκτονικής", "εκκαθάριση της ενότητας ελέγχου ταυτότητας". Αυτά είναι αιτήματα που ακούγονται παραγωγικά και δημιουργούν τεράστιες διαφορές. Αλλά μετά βρίσκεις τον εαυτό σου να κάνει αρχαιολογία.
Μια χρήσιμη προτροπή είναι πιο βαρετή. Για παράδειγμα: εφαρμόστε την εξαγωγή CSV για τη σελίδα τιμολογίων, γνωρίζοντας ότι ο πίνακας βρίσκεται στο app/(dashboard)/invoices/page.tsx, τα ερωτήματα είναι στο src/server/invoices.ts και υπάρχει ήδη ένα παρόμοιο μοτίβο στο app/(dashboard)/reports.
Στη συνέχεια, προσθέστε σαφείς περιορισμούς: μην αλλάξετε το σχήμα της βάσης δεδομένων, μην προσθέσετε εξαρτήσεις εάν ένα μικρό βοηθητικό πρόγραμμα είναι αρκετό, διατηρήστε το υπάρχον στυλ διεπαφής χρήστη. Και κλείστε με την επαλήθευση: npm test -- invoices και npm run build.
Αυτός ο τύπος σύντομης περιγραφής δεν είναι για να "εξηγηθεί καλύτερα στο AI". Χρησιμεύει πάνω από όλα για να σας καταστήσει πιο σαφές τι αναθέτετε. Εάν δεν μπορείτε να το γράψετε συγκεκριμένα, ίσως η εργασία να μην είναι ακόμα έτοιμη για έναν πράκτορα.
Τρεις δουλειές που αναθέτω πρόθυμα
Η πρώτη είναι επαναλαμβανόμενη αλλά επαληθεύσιμη εργασία: προσθήκη δοκιμών, μετεγκατάσταση κλήσεων σε ένα νέο εσωτερικό API, ενημέρωση εισαγωγών, αντικατάσταση καταργημένων στοιχείων, διόρθωση σφαλμάτων TypeScript. Εδώ ο πράκτορας μπορεί να εξοικονομήσει ώρες και ο κίνδυνος είναι ελεγχόμενος.
Το δεύτερο είναι η διερευνητική εργασία: "βρες πού υπολογίζεται αυτό το σύνολο", "εξήγησέ μου γιατί αυτό το τεστ είναι εύθραυστο", "αναπαραγωγή του σφάλματος και πες μου ποια αρχεία φαίνεται να επηρεάζονται". Ακόμη και όταν δεν παράγει αμέσως ένα έμπλαστρο, μπορεί να κάνει χρήσιμη αναγνώριση.
Το τρίτο είναι οι επαναλαμβανόμενες εργασίες συντήρησης: μικρές ενημερώσεις εξάρτησης, εκκαθάριση παλιών σημαιών χαρακτηριστικών, περίληψη αποκλεισμένων PR, έλεγχος ξεχασμένων TODO. Δεν είναι λαμπερό, αλλά είναι ακριβώς το είδος της δουλειάς που τείνει να συσσωρεύεται.
Τρεις δουλειές που κρατάω ανθρώπινες
Οι αποφάσεις για τα προϊόντα παραμένουν ανθρώπινες. Εάν μια αλλαγή αλλάξει τον τρόπο με τον οποίο ένας χρήστης πληρώνει, διαγράψει δεδομένα, δει τιμές ή κατανοήσει μια άδεια, θέλω ένα υπεύθυνο άτομο.
Τα όρια ασφαλείας αξίζουν επίσης την ανθρώπινη προσοχή: ταυτότητα, ρόλοι, διακριτικά, ευαίσθητα δεδομένα καταγραφής, μετεγκαταστάσεις βάσεων δεδομένων. Ένας πράκτορας μπορεί να βοηθήσει στην εφαρμογή, αλλά δεν χρειάζεται να είναι ο μόνος λήπτης αποφάσεων.
Τέλος, κρατάω ό,τι απαιτεί αρχιτεκτονικό γούστο ανθρώπινο. Ένας πράκτορας μπορεί να προτείνει έναν ανασχηματιστή, αλλά η κατανόηση του εάν μια αφαίρεση είναι πραγματικά απαραίτητη ή αν απλώς λύνουμε ένα ανύπαρκτο πρόβλημα παραμένει δουλειά.
Η αναθεώρηση δεν είναι προαιρετική
Ο πειρασμός, όταν ένας πράκτορας είναι καλός, είναι να εμπιστευτείς το πράσινο του CI. Είναι κατανοητό. Είναι επίσης όταν αρχίζουν τα προβλήματα.
Πάντα κοιτάζω τουλάχιστον πέντε πράγματα:
- Η ενημέρωση κώδικα επιλύει μόνο την ζητούμενη εργασία;
- Άγγιξε αρχεία που δεν είχαν καμία σχέση με αυτό;
- Καλύπτουν τα τεστ νέα συμπεριφορά ή απλώς ευτυχισμένη ευκαιρία;
- Ο κώδικας ακολουθεί τοπικά μοτίβα;
- Αντιμετωπίζονται τα σφάλματα όπως στο υπόλοιπο έργο;
Όταν κάτι δεν πάει καλά, η ανατροφοδότηση πρέπει να είναι συγκεκριμένη. Το «Fix it» είναι τεμπέλης. Καλύτερα: αυτό το βοηθητικό πρόγραμμα αντιγράφει το parseMoney σε src/lib/money.ts. επαναχρησιμοποιήστε αυτήν τη λειτουργία, προσθέστε μια δοκιμή για την περίπτωση EUR και μην αλλάξετε το δημόσιο API της μονάδας χρέωσης.
Οι πράκτορες ανταποκρίνονται πολύ καλύτερα σε μικρά, επαληθεύσιμα σχόλια. Περιέργως, το ίδιο κάνουν και οι άνθρωποι.
Τα προστατευτικά κιγκλιδώματα αξίζει τον κόπο
Εάν ένας πράκτορας μπορεί να διαβάζει αρχεία, να γράφει κώδικα και να εκτελεί εντολές, θα πρέπει να αντιμετωπίζεται ως μια ισχυρή διαδικασία. Δεν χρειάζεται παράνοια, χρειάζεται υγιεινή.
Χρησιμοποιήστε ξεχωριστά δέντρα εργασίας ή κλαδιά. Έτσι, μπορείτε να συγκρίνετε τη διαφορά, να πετάξετε τα αποτυχημένα πειράματα και να μην ανακατέψετε τη δουλειά του πράκτορα με αυτό που κάνατε.
Περιορίστε τα δικαιώματα. Εντολές όπως rg, git diff, npm test και npm run build μπορεί να είναι αρκετά δωρεάν. Οι αναπτύξεις, οι μετεγκαταστάσεις βάσεων δεδομένων, η πρόσβαση σε μυστικά και οι καταστροφικές εντολές πρέπει να παραμένουν σαφείς.
Μειώστε την πρόσβαση στο δίκτυο όταν δεν το χρειάζεστε. Για πολλές εργασίες, αρκεί η επίσημη τεκμηρίωση, το μητρώο πακέτων και συγκεκριμένες εσωτερικές υπηρεσίες. Λιγότερη επιφάνεια, λιγότερες εκπλήξεις.
Παρακολούθηση ενεργειών. Όταν μια ενημερωμένη έκδοση κώδικα φθάνει σε αναθεώρηση, θα πρέπει να μπορείτε να ανακατασκευάσετε τις προτροπές, τις εντολές που εκτελούνται, τις δοκιμές που έχουν περάσει και τα αρχεία που έχουν τροποποιηθεί. Όχι για να δημιουργήσουμε γραφειοκρατία, αλλά για να μπορέσουμε να καταλάβουμε τι έγινε αν κάτι πάει στραβά.
Ένας εύκολος τρόπος για να ξεκινήσετε ως ομάδα
Αν εισήγαγα πράκτορες σε μια μικρή ομάδα, θα ξεκινούσα χωρίς μεγάλες επαναστάσεις.
Θα δημιουργούσα μια ετικέτα agent-ready για ζητήματα με σαφή εμβέλεια. Θα πρόσθετα ένα πρότυπο με πλαίσιο, περιορισμούς και εντολές επαλήθευσης. Θα ζητούσα μικρό PR, ιδανικά κάτω από μερικές εκατοντάδες γραμμές. Θα χρειαζόμουν δοκιμή ή στιγμιότυπα οθόνης για ορατές αλλαγές. Και πάνω από όλα θα κρατούσα υπεύθυνο για τη συγχώνευση.
Μετά από δύο εβδομάδες θα κοίταζα τα δεδομένα: ποιες εργασίες επιταχύνθηκαν πραγματικά, ποιες αναθεωρήσεις ήταν βαριές, ποιες προτροπές προκαλούν σύγχυση, ποια μέρη της βάσης κωδικών είναι πολύ εύθραυστα για να τα αναθέσουμε.
Είναι μια λιγότερο θεαματική προσέγγιση από το "από σήμερα θα κάνουμε τα πάντα με τους πράκτορες", αλλά είναι αυτή που σας επιτρέπει να φτάσετε στην τρίτη εβδομάδα χωρίς τύψεις.
Το πιο ανθρώπινο κομμάτι
Το αστείο είναι ότι όσο πιο αυτόνομοι πράκτορες γίνονται, τόσο πιο σημαντικές γίνονται και πάλι οι κλασικές δεξιότητες: να γράφεις ένα καλό εισιτήριο, να κάνεις μικρές περικοπές, να δημιουργείς τεστ, να διαβάζεις διαφοροποιήσεις, να επικοινωνείς συμβιβασμούς. Ο πράκτορας επιταχύνει αυτούς που ήδη ξέρουν πώς να δουλεύουν καλά. Ενισχύει επίσης το χάος όσων αναθέτουν άσχημα.
Επομένως, όχι, δεν βλέπω τις ροές εργασίας πολλαπλών πρακτόρων ως συντόμευση για να σταματήσετε να ασχολείστε με τη μηχανική. Τους βλέπω ως έναν τρόπο για να μεταφέρετε περισσότερη ενέργεια στα μέρη που έχουν σημασία: να αποφασίσετε τι να κατασκευάσετε, να βεβαιωθείτε ότι λειτουργεί, να διατηρήσετε το σύστημα κατανοητό.
Οι πράκτορες μπορούν να κάνουν σπουδαίους ασύγχρονους συναδέλφους. Αλλά ένας ασύγχρονος συνάδελφος, για να είναι χρήσιμος, χρειάζεται πλαίσιο, όρια και αναθεώρηση. Όπως όλοι οι άλλοι.