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

Η θέση είναι σκόπιμα βαρετή: ένας agent είναι ένας ασυνήθιστα γρήγορος contributor χωρίς θεσμική κρίση, και η κλίμακα περιβαλλόντων υπάρχει ακριβώς για contributors σαν αυτόν. Dev, staging, production, με μια πύλη ανάμεσα σε κάθε ένα. Ποτέ δεν αφορούσε τον άνθρωπο. Πάντα αφορούσε την ακτίνα έκρηξης.

Γιατί παρακάμφθηκε η κλίμακα

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

Ο agent ξεκινά σαν autocomplete, και κανείς δεν κάνει stage το autocomplete. Μετά αρχίζει να τρέχει το test suite τοπικά, που είναι εντάξει. Μετά χρειάζεται να χτυπήσει μια πραγματική υπηρεσία για να αναπαράγει ένα bug, οπότε κάποιος του δίνει read access στο staging. Μετά τα δεδομένα staging είναι μπαγιάτικα, οπότε κάποιος τον στρέφει σε ένα production replica. Μετά μια εργασία χρειάζεται write, και το credential που βρίσκεται ήδη στο περιβάλλον τυχαίνει να το έχει. Σε καμία στιγμή κανείς δεν αποφάσισε ότι ο agent πρέπει να μπορεί να γράφει στο production. Έφτασε εκεί μέσα από μια σειρά ξεχωριστά λογικών βημάτων, που είναι ο τρόπος με τον οποίο φτάνουν τα περισσότερα incidents οπουδήποτε.

Τι κάνει διαφορετικά ένας agent

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

  • Η ταχύτητα αφαιρεί την παύση. Ένας άνθρωπος που κάνει κάτι καταστροφικό συνήθως διστάζει πρώτα. Αυτός ο δισταγμός είναι ένας άγραφος έλεγχος ασφαλείας, και είναι μεγάλο μέρος του γιατί η κλίμακα έχει κρατήσει για ανθρώπους παρόλο που επιβάλλεται χαλαρά. Ένας agent εκτελεί με πλήρη αυτοπεποίθηση σε δύο δευτερόλεπτα. Δεν υπάρχει παύση για να τον πιάσεις.
  • Καμία αίσθηση συνέπειας. Ένας μηχανικός ξέρει ότι αυτός ο πίνακας είναι ο πίνακας billing και η Πέμπτη είναι μέρα τιμολόγησης. Αυτή η γνώση δεν βρίσκεται στο repository, οπότε δεν βρίσκεται στο context του agent. Ξέρει το schema. Δεν ξέρει το ρίσκο.
  • Κυριολεκτικοί στόχοι. Όταν του ζητηθεί να περάσει ένα integration test, ένας agent θα εξετάσει το να μεταβάλει τα δεδομένα πάνω στα οποία κάνει assert το test. Αυτή είναι μια νόμιμη λύση στο δηλωμένο πρόβλημα. Είναι λάθος μόνο λόγω context που δεν έχει ο agent.
  • Όγκος. Ένας μηχανικός ανοίγει τρία pull requests την ημέρα. Ένας στόλος agents ανοίγει τριάντα. Η πιθανότητα ανά αλλαγή για μια κακή αλλαγή μπορεί να πέσει, και ο απόλυτος αριθμός κακών αλλαγών να ανέβει παρόλα αυτά.

Η κλίμακα, επαναδιατυπωμένη για agents

Τα ίδια τρία σκαλοπάτια, με το κομμάτι που αφορά ειδικά τους agents τονισμένο.

  • Dev: αναλώσιμο και απομονωμένο. Ένας agent, ένας workspace, καθόλου shared state. Αν δύο agents δουλεύουν στο ίδιο checkout θα μαλώσουν για τα ίδια αρχεία και θα ξοδέψεις το απόγευμά σου διαβάζοντας ένα merge conflict που κανείς τους δεν καταλαβαίνει. Τα εφήμερα branches και worktrees είναι φθηνά· το shared mutable state δεν είναι.
  • Staging: πραγματικό σχήμα, ψεύτικο ρίσκο. Το staging δικαιολογεί την ύπαρξή του μόνο αν μοιάζει δομικά με το production, ίδιο schema, ίδια τοπολογία υπηρεσιών, ίδια συμπεριφορά αποτυχίας, ενώ δεν περιέχει τίποτα του οποίου η απώλεια έχει σημασία. Seeded ή συνθετικά δεδομένα, ποτέ αντίγραφο production. Ένα production replica μέσα στο staging είναι production με χειρότερο monitoring.
  • Production: μόνο άνθρωποι και πύλες. Το output του agent φτάνει στο production με τον ίδιο τρόπο που φτάνει κάθε αλλαγή, μέσα από ένα reviewed pull request και το υπάρχον deploy gate σου. Καμία πλαϊνή πόρτα, κανένας service account με fast path.

Η απομόνωση είναι το credential, όχι το URL

Εδώ είναι που οι ομάδες ξεγελούν τον εαυτό τους. Το να στρέψεις τον agent στο staging.internal δεν είναι απομόνωση αν το credential στο περιβάλλον του ισχύει και για το production. Το όριο του περιβάλλοντος ορίζεται από το τι μπορεί να φτάσει η ταυτότητα, όχι από το ποιο hostname αναφέρει η εργασία. Ένας agent με ευρύ ρόλο απέχει μία μπερδεμένη κλήση εργαλείου από τον λάθος λογαριασμό, και θα κάνει αυτή την κλήση ευγενικά και άμεσα.

Η εκδοχή αυτού που αντέχει είναι ασήμαντη πρακτική AWS, εφαρμοσμένη με συνέπεια:

  • Ξεχωριστοί λογαριασμοί ανά περιβάλλον, ώστε ένα λάθος που διασχίζει περιβάλλοντα να χρειάζεται μια role assumption που δεν υπάρχει αντί για ένα typo που υπάρχει.
  • Ένας αποκλειστικός ρόλος ανά εργασία agent, scoped στους πόρους που χρειάζεται εκείνη η εργασία, ο οποίος γίνεται assume μόνο για τη διάρκεια του run.
  • Κανένα μακρόβιο key στο περιβάλλον του agent. Τα βραχύβια credentials σημαίνουν ότι ένα διαρρεύσαν context είναι ένα πρόβλημα με ημερομηνία λήξης.
  • Deny-by-default στα καταστροφικά verbs. Ένας agent που ποτέ δεν χρειάζεται το DeleteObject πρέπει να είναι δομικά ανίκανος να το καλέσει, όχι απλώς απρόθυμος.
  • Ανθρώπινη έγκριση για οτιδήποτε διασχίζει σε έναν λογαριασμό που κρατά πραγματικά δεδομένα, σαν έλεγχο που ο agent δεν μπορεί να ικανοποιήσει μόνος του.

Τα review gates είναι το νόημα, όχι η τριβή

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

Το πλεονέκτημα ταχύτητας του agent βρίσκεται στη γένεση, όχι στην επαλήθευση. Γράφει μια εύλογη διόρθωση σε ενενήντα δευτερόλεπτα αντί για μια ώρα, κάτι που είναι γνήσιο και μεγάλο. Η επαλήθευση δεν ήταν ποτέ το bottleneck που αφαιρεί. Το να αφαιρέσεις το review gate δεν κάνει τον agent πιο γρήγορο σε αυτό στο οποίο είναι ήδη γρήγορος, απλώς αφαιρεί τον μηχανισμό που πιάνει το δέκα τοις εκατό του αυτοπεποίθους output που είναι λάθος. Κρατάς τη διόρθωση των ενενήντα δευτερολέπτων. Κρατάς τον reviewer. Αυτή είναι όλη η συμφωνία, και είναι καλή.

Το συμπέρασμα

Τίποτα από αυτά δεν είναι καινούρια μηχανική. Διαχωρισμός περιβαλλόντων, scoped credentials, review πριν το production: η ομάδα σου έγραψε αυτούς τους κανόνες για ανθρώπους και σε μεγάλο βαθμό τους ακολουθεί. Το λάθος είναι να αντιμετωπίζεις έναν agent σαν εργαλείο και όχι σαν contributor, γιατί τα εργαλεία δεν χρειάζονται κλίμακα περιβαλλόντων και οι contributors χρειάζονται. Δώσε στον agent ένα sandbox που μοιάζει με production και δεν κρατά τίποτα που έχει σημασία, μια ταυτότητα που λήγει και δεν μπορεί να φτάσει πέρα από το όριο, και έναν reviewer ανάμεσα σε αυτόν και το deploy. Μετά άφησέ τον να πάει γρήγορα μέσα σε αυτό το κουτί.

Διάβασε αυτό στη συνέχεια

Για τους ελέγχους σε επίπεδο λογαριασμού πίσω από αυτό, το multi-party approval in AWS Organizations καλύπτει την πύλη για operations που τίποτα δεν πρέπει να τρέχει μόνο του, στο ercan.cloud. Ο κόμβος είναι στο ercanermis.com.