Του Kwame Boateng
Η κωδικοποίηση με τη βοήθεια AI περιγράφεται συχνά ως μια ταχύτερη εκδοχή του προγραμματισμού σε ζεύγη. Αυτή η σύγκριση είναι πλέον υπερβολικά περιορισμένη. Όταν ένας πράκτορας μπορεί να επιθεωρήσει ένα αποθετήριο, να αλλάξει πολλά αρχεία, να εκτελέσει εργαλεία, να δημιουργήσει μια προεπισκόπηση και να ανοίξει ένα pull request, το κεντρικό πρόβλημα συνεργασίας δεν είναι πλέον απλώς «Μπορεί να γράψει κώδικα;». Είναι «Μπορούν οι άνθρωποι να δουν, να ελέγξουν, να εγκρίνουν και αργότερα να ανασυνθέσουν τι συνέβη;»
Γι’ αυτό η σημαντικότερη αλλαγή σχεδιασμού στις ομάδες λογισμικού με τη βοήθεια πρακτόρων μπορεί να είναι η μετάβαση από τα ιδιωτικά prompts στους ορατούς χώρους εργασίας. Το Slack Code, για παράδειγμα, περιγράφεται ως συνδυασμός καναλιών έργων με πράκτορες κωδικοποίησης, ελέγχου διαφορών κώδικα, ζωντανών προεπισκοπήσεων HTML, ροών εργασίας για σχόλια και εγκρίσεις, αυτόματης αρχειοθέτησης και αρχείων καταγραφής ελέγχου. Η εφαρμογή Copilot του GitHub έχει επίσης προσθέσει ένα παράθυρο «Η δουλειά μου» για την οργάνωση ζητημάτων και pull requests σε διάφορα έργα. Αυτές οι δυνατότητες δείχνουν προς μια πρακτική αρχή: η εργασία ενός πράκτορα θα πρέπει να μοιάζει λιγότερο με μια αδιαφανή απάντηση και περισσότερο με ένα σύνολο αλλαγών που περνά από μια ελεγχόμενη διαδικασία παραγωγής.
Η συνομιλία δεν είναι το αρχείο εργασίας
Μια συνομιλία με έναν πράκτορα μπορεί να είναι χρήσιμη για τη διερεύνηση μιας ιδέας, αλλά αποτελεί αδύναμο σύστημα καταγραφής. Σημαντικές λεπτομέρειες μπορεί να είναι θαμμένες σε ένα μακρύ νήμα: ποια αρχεία άλλαξαν, ποιες εντολές εκτελέστηκαν, ποιες παραδοχές έκανε ο πράκτορας, τι απέρριψε ένας αξιολογητής και αν το τελικό αποτέλεσμα διαφέρει από την αρχική πρόταση.
Ένας διαρκής χώρος εργασίας καθιστά αυτές τις λεπτομέρειες ελέγξιμες. Θα πρέπει να συνδέει το αίτημα με ένα συγκεκριμένο αποθετήριο ή έργο, να διατηρεί το σχέδιο του πράκτορα, να εμφανίζει τις ενέργειες των εργαλείων και τις αλλαγές στα αρχεία, να συνδέεται με δοκιμές και προεπισκοπήσεις και να καταγράφει ποιος ενέκρινε το αποτέλεσμα. Η ακριβής διεπαφή μπορεί να διαφέρει—ένα σύστημα παρακολούθησης ζητημάτων, ένα pull request, ένα κανάλι συνεργασίας ή μια κονσόλα πράκτορα—αλλά οι πληροφορίες θα πρέπει να παραμένουν διαθέσιμες μετά το τέλος της συνεδρίας.
Αυτό έχει σημασία για συνηθισμένους λόγους μηχανικής λογισμικού, όχι μόνο για λόγους συμμόρφωσης. Αν εμφανιστεί ένα σφάλμα δύο εβδομάδες αργότερα, μια ομάδα χρειάζεται περισσότερα από την τελική διαφορά. Μπορεί να χρειάζεται να γνωρίζει την αρχική απαίτηση, το παραγόμενο σχέδιο, τα στοιχεία των δοκιμών, τα σχόλια του αξιολογητή και αν ένας άνθρωπος αποδέχτηκε ρητά έναν επικίνδυνο συμβιβασμό. Ένα διαρκές αρχείο συντομεύει αυτή την έρευνα.
Πέντε επίπεδα ορατής εργασίας
Οι ομάδες που υιοθετούν πράκτορες κωδικοποίησης μπορούν να αντιμετωπίζουν κάθε αλλαγή ως έναν μικρό, ελέγξιμο φάκελο υπόθεσης. Πέντε επίπεδα είναι ιδιαίτερα χρήσιμα:
- Πρόθεση: το ζήτημα, τα κριτήρια αποδοχής, οι περιορισμοί και το ζητούμενο εύρος.
- Σχέδιο: η προτεινόμενη προσέγγιση του πράκτορα πριν编辑σει αρχεία. Για μια μη τετριμμένη εργασία, αυτό είναι σημείο ελέγχου για έγκριση και όχι διακοσμητικό στοιχείο.
- Διαφορά: οι ακριβείς προσθήκες, διαγραφές, αλλαγές εξαρτήσεων, επεξεργασίες διαμόρφωσης και παραγόμενα στοιχεία.
- Στοιχεία τεκμηρίωσης: αποτελέσματα δοκιμών, έξοδος lint, έλεγχοι ασφάλειας, στιγμιότυπα οθόνης και μια ζωντανή ή διαθέσιμη προς ανάπτυξη προεπισκόπηση, όπου χρειάζεται.
- Αρχείο απόφασης: σχόλια αξιολογητών, ζητούμενες αλλαγές, έγκριση, απόρριψη, επαναφορά ή εργασία παρακολούθησης.
Το ζητούμενο δεν είναι να υποχρεωθεί κάθε αλλαγή να περάσει από μια βαριά επιτροπή. Ένα τυπογραφικό λάθος και μια αλλαγή στη ροή πληρωμής δεν θα πρέπει να υπόκεινται στους ίδιους ελέγχους. Το ζητούμενο είναι το επίπεδο ελέγχου να είναι ανάλογο με τον πιθανό αντίκτυπο.
Οι εγκρίσεις πρέπει να συνδέονται με ενέργειες
Ο «άνθρωπος στον βρόχο» είναι υπερβολικά ασαφής έννοια για να αποτελέσει χρήσιμο έλεγχο. Ένα άτομο μπορεί να εγκρίνει ένα σχέδιο χωρίς να δει την τελική διαφορά ή να εγκρίνει μια αλλαγή κώδικα χωρίς να παρατηρήσει ότι ο πράκτορας τροποποίησε επίσης ένα αρχείο ανάπτυξης. Οι καλύτερες ροές εργασίας δηλώνουν τι επιτρέπει η έγκριση.
Για παράδειγμα, μια ομάδα μπορεί να επιτρέπει σε έναν πράκτορα να διαβάζει ένα αποθετήριο και να εκτελεί αυτόματα τοπικές δοκιμές, να απαιτεί έγκριση πριν από την εγγραφή εκτός ενός καθορισμένου κλάδου και να απαιτεί ξεχωριστή έγκριση πριν από τη συγχώνευση ή την ανάπτυξη. Ένας πράκτορας μπορεί να προτείνει μια μετάβαση βάσης δεδομένων, αλλά να απαγορεύεται να την εκτελέσει στην παραγωγή. Η προτεινόμενη προσέγγιση των ΗΑΕ για την ταξινόμηση των εργασιών που μπορούν να ολοκληρώνουν οι πράκτορες έναντι εκείνων που μπορούν απλώς να προτείνουν αντικατοπτρίζει αυτό το ευρύτερο μοτίβο: η αυτονομία θα πρέπει να αποδίδεται ανά εργασία και όχι να θεωρείται δεδομένη συνολικά.
Οι εγκρίσεις χρειάζονται επίσης εύρος και ημερομηνία λήξης. Μια έγκριση για «ενημέρωση του κειμένου της σελίδας προορισμού» δεν θα πρέπει να εξουσιοδοτεί σιωπηρά την προσθήκη ενός νέου πακέτου αναλυτικών στοιχείων. Ένα σχέδιο που εγκρίθηκε χθες δεν θα πρέπει αυτόματα να καλύπτει μια ουσιωδώς αλλαγμένη διαφορά σήμερα. Η διεπαφή θα πρέπει να καθιστά αυτά τα όρια ορατά.
Οι προεπισκοπήσεις μετατρέπουν την αξιολόγηση σε επιθεώρηση
Η αξιολόγηση κώδικα είναι συχνά ευκολότερη όταν οι άνθρωποι μπορούν να επιθεωρήσουν το αποτέλεσμα αντί να το συμπεράνουν από τα αρχεία πηγαίου κώδικα. Μια ζωντανή προεπισκόπηση HTML μπορεί να αποκαλύψει προβληματικές αποστάσεις, καταστάσεις που λείπουν, μη προσβάσιμα στοιχεία ελέγχου ή μια ακούσια αλλαγή στην πλοήγηση που ένας αξιολογητής μπορεί να παραβλέψει σε μια διαφορά κειμένου.
Οι προεπισκοπήσεις δεν αποτελούν απόδειξη ορθότητας. Θα πρέπει να βρίσκονται δίπλα στις δοκιμές και την αξιολόγηση του πηγαίου κώδικα, όχι να τα αντικαθιστούν. Δημιουργούν όμως ένα κοινό αντικείμενο συζήτησης: ένας αξιολογητής μπορεί να αναφερθεί σε μια συγκεκριμένη οθόνη, κατάσταση ή αλληλεπίδραση και να αφήσει σχόλια συνδεδεμένα με την προτεινόμενη αλλαγή.
Αυτό είναι ιδιαίτερα πολύτιμο όταν στη διαδικασία αξιολόγησης συμμετέχουν μη ειδικοί. Ένας υπεύθυνος προϊόντος μπορεί να μην είναι σε θέση να αξιολογήσει μια αλλαγή στο framework, αλλά μπορεί να είναι το κατάλληλο άτομο για να επιβεβαιώσει ότι η ροή εργασίας ανταποκρίνεται στην απαίτηση. Ένας σχεδιαστής μπορεί να επικυρώσει μια οπτική παλινδρόμηση. Ένας ειδικός ασφάλειας μπορεί να επικεντρωθεί στα δικαιώματα και στη διαχείριση δεδομένων. Ο χώρος εργασίας με τη βοήθεια πράκτορα μπορεί να κατευθύνει κάθε ερώτηση στο άτομο που είναι καταλληλότερο να την απαντήσει.
Οι διαφορές χρειάζονται πλαίσιο, όχι μόνο χρώμα
Μια οικεία διαφορά με κόκκινο και πράσινο παραμένει απαραίτητη, αλλά οι αλλαγές που παράγονται από πράκτορες μπορεί να είναι αρκετά εκτεταμένες ώστε να κατακλύσουν έναν αξιολογητή. Οι ομάδες θα πρέπει να ζητούν από τους πράκτορες να διατηρούν τα commits ή τις ομάδες αλλαγών περιορισμένες, να εξηγούν γιατί άλλαξε κάθε ουσιαστικό αρχείο και να επισημαίνουν ξεχωριστά τα παραγόμενα αρχεία ή τα αρχεία προμηθευτών.
Χρήσιμες ερωτήσεις για την ανασκόπηση περιλαμβάνουν:
- Ποια συμπεριφορά που βλέπει ο χρήστης άλλαξε;
- Ποια αρχεία άλλαξαν μόνο για την υποστήριξη της υλοποίησης;
- Ποιες παραδοχές έκανε ο agent σχετικά με την υπάρχουσα συμπεριφορά;
- Ποια τεστ προστέθηκαν, τροποποιήθηκαν ή δεν εκτελέστηκαν;
- Θα μπορούσε αυτή η αλλαγή να επηρεάσει δικαιώματα, διατήρηση δεδομένων, χρεώσεις ή εξωτερικά API;
Αυτές οι ερωτήσεις μετατρέπουν την ανασκόπηση από ένα αόριστο αίτημα του τύπου «ρίξε μια ματιά» σε μια επαναλαμβανόμενη εξέταση. Βοηθούν επίσης να αποκαλυφθεί ένας συνηθισμένος τρόπος αποτυχίας: μια εύλογη λειτουργία που συνοδεύεται από μια ελλιπή ενημέρωση των τεστ ή από μια ακούσια αλλαγή ρύθμισης.
Αρχειοθετήστε το σκεπτικό που έχει σημασία
Η διατήρηση κάθε διακριτικού από κάθε συνομιλία με ένα μοντέλο δεν είναι αυτομάτως χρήσιμη. Τα μεγάλα ιστορικά μπορεί να είναι ακριβά στην αποθήκευση και δύσκολα στην αναζήτηση, ενώ η έρευνα για τη συμπύκνωση του πλαισίου προειδοποιεί ότι οι περιλήψεις μπορεί να χάσουν σημαντικές πληροφορίες. Επομένως, μια πρακτική διαδρομή ελέγχου θα πρέπει να διατηρεί τεκμήρια που σχετίζονται με τις αποφάσεις, αντί να αποθηκεύει αδιακρίτως τα πάντα.
Κατ’ ελάχιστον, διατηρήστε το αίτημα, το εγκεκριμένο σχέδιο, το τελικό diff, τα αποτελέσματα των εργαλείων και των τεστ, την αναφορά προεπισκόπησης ή ανάπτυξης, τις αποφάσεις των αξιολογητών και κάθε εξαίρεση που χορηγήθηκε. Αν ένας agent χρησιμοποίησε εξωτερικές πηγές ή ανέκτησε εσωτερικά έγγραφα, καταγράψτε τις σχετικές αναφορές στις πηγές και το σημείο στο οποίο αυτές επηρέασαν την αλλαγή. Για εργασίες υψηλού κινδύνου, μπορεί να δικαιολογείται η διατήρηση της πλήρους αλληλεπίδρασης και του αρχείου καταγραφής εκτέλεσης.
Κάντε τα αρχεία ανιχνεύσιμα ως προς τυχόν παραποίηση, όπου το απαιτούν οι συνέπειες, και καθορίστε κανόνες διατήρησης πριν από μια κρίση. Μια διαδρομή ελέγχου που εξαφανίζεται όταν αρχειοθετείται ένα κανάλι —ή που δεν μπορεί να διακρίνει ένα τροποποιημένο αποτέλεσμα από το αρχικό— δεν θα υποστηρίξει μια σοβαρή διερεύνηση.
Πώς αυτό αλλάζει τις σταδιοδρομίες στον χώρο του λογισμικού
Η αναδυόμενη δεξιότητα δεν είναι απλώς η συγγραφή καλύτερων prompts. Είναι ο σχεδιασμός εργασίας που μπορεί να επιθεωρήσει και να εμπιστευτεί ένας άλλος άνθρωπος. Οι προγραμματιστές θα πρέπει να αισθάνονται άνετα με τον καθορισμό κριτηρίων αποδοχής, την ανάλυση εργασιών σε επιμέρους τμήματα, την ανασκόπηση diff σε μεγάλη κλίμακα, τη δημιουργία ουσιαστικών τεστ και την απόφαση για το πότε ένας agent πρέπει να σταματήσει και να ρωτήσει.
Οι επαγγελματίες προϊόντος και σχεδιασμού θα διαδραματίσουν μεγαλύτερο ρόλο στην ανασκόπηση προεπισκοπήσεων και στην αποσαφήνιση της πρόθεσης. Οι μηχανικοί QA μπορούν να βοηθήσουν στον καθορισμό πυλών έγκρισης και περιπτώσεων αποτυχίας. Οι engineering managers θα πρέπει να μετρούν την απόδοση χωρίς να επιβραβεύουν την ανάληψη αόρατου ρίσκου. Οι τεχνικοί συγγραφείς και οι ειδικοί επιχειρησιακής λειτουργίας μπορούν να συνεισφέρουν καθιστώντας τις αποφάσεις, τις εξαιρέσεις και τα runbooks ανθεκτικά στον χρόνο.
Μια χρήσιμη άσκηση είναι να πάρετε μια συνηθισμένη λειτουργία και να χαρτογραφήσετε την αλυσίδα τεκμηρίωσής της: αίτημα, σχέδιο, branch, diff, τεστ, προεπισκόπηση, έγκριση, κυκλοφορία και επαναφορά. Στη συνέχεια, ρωτήστε πού ένας μελλοντικός συνεργάτης θα αναγκαζόταν να μαντέψει. Κάθε εικασία είναι υποψήφια για έναν καλύτερο χώρο εργασίας, μια σαφέστερη άδεια ή ένα πιο ανθεκτικό αρχείο.
Ένας απλός κανόνας λειτουργίας
Αφήστε τους agents να κινούνται γρήγορα μέσα σε μια ορατή και αναστρέψιμη ζώνη. Δώστε τους έναν καθορισμένο χώρο εργασίας, περιορίστε τις ευαίσθητες ενέργειες, απαιτήστε έγκριση σε ουσιαστικά όρια, επισυνάψτε τεκμήρια στην αλλαγή και διατηρήστε την τελική απόφαση. Ο στόχος δεν είναι να επιβραδυνθεί η αυτοματοποίηση μέχρι να μοιάζει με χειροκίνητη συγγραφή κώδικα. Είναι να καταστεί η ταχύτητα συμβατή με τη λογοδοσία.
Στην ανάπτυξη με τη βοήθεια agents, ο καλύτερος συνεργάτης δεν είναι το σύστημα που παράγει τον περισσότερο κώδικα μεμονωμένα. Είναι το σύστημα του οποίου η εργασία μπορεί να γίνει κατανοητή, να αμφισβητηθεί, να εγκριθεί, να αναιρεθεί και να αποτελέσει αντικείμενο μάθησης.
