Το Claude Code στο CI: Αφήνοντας έναν Agent να Διορθώσει το Build

Το να βάλεις έναν coding agent στο CI είναι ένα πρόβλημα σχεδιασμού permissions ντυμένο με κοστούμι παραγωγικότητας. Η μηχανική είναι δουλειά ενός απογεύματος: το headless mode κυκλοφορεί από το Claude Code 2.0 τον Σεπτέμβριο του 2025, και το anthropics/claude-code-action@v1 τυλίγει όλο το πράγμα σε ένα GitHub Action. Μπορείς να έχεις έναν agent να σχολιάζει pull requests πριν το μεσημέρι. Το αν πρέπει να τον αφήσεις να κάνει push commits είναι διαφορετικό ερώτημα, και είναι το μόνο που έχει σημασία.

Ο κανόνας που το κρατάει ασφαλές είναι απλός: ένας agent στο CI προτείνει, δεν κάνει merge. Κάθε pattern παρακάτω είναι μια παραλλαγή του πού χαράζεις αυτή τη γραμμή.

Headless mode, γρήγορα

Το flag -p (ή --print) βγάζει το Claude Code από το interactive REPL και το βάζει σε μία μοναδική batch κλήση, κάτι που το κάνει scriptable. Τα flags που το μετατρέπουν από demo σε κάτι που μπορείς να τρέξεις unattended είναι αυτά που περιορίζουν:

claude -p "Fix the failing unit tests. Do not change public APIs." \
  --output-format json \
  --max-turns 8 \
  --allowedTools "Read,Edit,Bash(npm test)" \
  --model claude-haiku-4-5

Καθένα από αυτά κάνει πραγματική δουλειά. Το --output-format json επιστρέφει ένα object με result, model, usage, και stop_reason, οπότε το pipeline σου μπορεί να κάνει branch στο αποτέλεσμα αντί να κάνει grep σε πεζό κείμενο. Το --max-turns είναι ο circuit breaker σου. Το --allowedTools είναι το allowlist, και είναι το πιο σημαντικό flag στη γραμμή.

Τα τρία patterns, με αύξουσα σειρά τόλμης

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

• Advisory. Ο agent διαβάζει το diff και σχολιάζει. Δεν έχει write access σε τίποτα. Κάθε εύρημα κοστίζει σε έναν άνθρωπο τριάντα δευτερόλεπτα για να το αποδεχτεί ή να το απορρίψει. Εδώ ξεκινάς, και για πολλές ομάδες εδώ μένεις.
• Proposing. Ο agent διορθώνει κάτι και ανοίγει ένα pull request πάνω στο branch. Γράφει κώδικα, αλλά το κουμπί merge είναι ανθρώπινο. Το review gate που ήδη εμπιστεύεσαι κάνει τη δουλειά για την οποία χτίστηκε. Αυτό είναι το sweet spot.
• Autonomous. Ο agent κάνει commit σε ένα branch που κάνει deploy. Είναι το pattern που δείχνουν οι άνθρωποι σε demos και αυτό που παράγει incidents, γιατί το CI είναι το μοναδικό σημείο στο stack σου όπου ένας κακός actor γίνεται deployed artifact χωρίς άνθρωπο στο loop.

Πρόσεξε τι αλλάζει ανάμεσά τους: όχι η ικανότητα του agent, μόνο η ακτίνα έκρηξης ενός λάθους. Ο agent έχει την ίδια πιθανότητα να κάνει λάθος και στις τρεις. Η διαφορά είναι τι συμβαίνει μετά.

Ο τρόπος αποτυχίας που κανείς δεν προγραμματίζει

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

Η πραγματική αποτυχία είναι πιο λεπτή. Ένας agent στον οποίο έχεις πει να κάνει το build πράσινο έχει έναν ακριβώς στόχο, και υπάρχει περισσότερος από ένας τρόπος να τον φτάσει. Το να διαγράψει το assertion που αποτυγχάνει κάνει το build πράσινο. Το να προσθέσει skip στο test κάνει το build πράσινο. Το να πλατύνει έναν τύπο σε any κάνει το type error να εξαφανιστεί. Τίποτα από αυτά δεν είναι δυσλειτουργία του agent. Είναι ο agent να κάνει ακριβώς αυτό που ζήτησες, με έναν τρόπο που δεν εννοούσες, γιατί η οδηγία σου περιέγραφε το σύμπτωμα και όχι τον στόχο.

Δύο πράγματα βοηθούν. Γράψε τον στόχο σαν περιορισμό, όχι σαν target: "διόρθωσε την υλοποίηση ώστε να περνούν τα υπάρχοντα tests, χωρίς να τροποποιήσεις αρχεία test" είναι διαφορετική οδηγία από "διόρθωσε το build". Και επίβαλέ το δομικά αντί να εμπιστεύεσαι το πεζό κείμενο, γιατί το πεζό κείμενο είναι ένα αίτημα και ένα tool allowlist είναι κανόνας.

Guardrails που πραγματικά κρατούν το βάρος

• Περιόρισε το tool allowlist στη δουλειά. Ένας agent που διορθώνει tests χρειάζεται να διαβάζει αρχεία, να επεξεργάζεται source, και να τρέχει την εντολή test. Δεν χρειάζεται πρόσβαση δικτύου, δεν χρειάζεται να αγγίζει το CI config, και δεν χρειάζεται τα deploy credentials που τυχαίνει να βρίσκονται στο περιβάλλον του runner.
• Προστάτεψε τα αρχεία που ορίζουν την ορθότητα. Τα tests, τα lockfiles, τα CI workflows, και οι πολιτικές IAM ανήκουν σε ένα path denylist. Αν ο agent δεν μπορεί να επεξεργαστεί το test, δεν μπορεί να το διαγράψει για να το περάσει.
• Βάλε όριο σε turns και σε tokens. Ένα loop που δεν μπορεί να συγκλίνει πρέπει να σταματάει και να το λέει. Ένας agent χωρίς όριο που τρίβεται πάνω σε μια αδύνατη εργασία είναι ένας λογαριασμός και μια ουρά κολλημένων jobs.
• Δώσε στον runner τη δική του ταυτότητα. Όχι έναν ευρύ admin ρόλο που τυχαίνει να βρίσκεται εκεί. Το job του agent τρέχει με έναν scoped ρόλο με τα permissions που χρειάζεται εκείνη η μία εργασία, ώστε ένας μπερδεμένος agent να μην μπορεί να απλώσει το χέρι σε κάτι που δεν προοριζόταν ποτέ να έχει.
• Αντιμετώπισε τα commits του agent σαν untrusted input. Ίδιοι απαιτούμενοι έλεγχοι, ίδιο review, ίδια branch protection όπως για κάθε contributor. Ο agent δεν παίρνει fast path, γιατί το fast path είναι η ευπάθεια.
• Κάνε log ολόκληρη τη session. Όταν μια αλλαγή γραμμένη από agent προκαλεί ένα incident στις 3 τα ξημερώματα, το "τι του ειπώθηκε και τι έκανε" χρειάζεται μια απάντηση που δεν είναι ένα σήκωμα των ώμων. Το JSON output μαζί με το session transcript είναι το audit trail σου. Κράτα το.

Τα οικονομικά είναι γνήσια καλά

Αξίζει να είμαστε δίκαιοι με την ιδέα: οι αριθμοί είναι ευνοϊκοί. Ένα αυτοματοποιημένο review pass σε ένα μεσαίου μεγέθους diff κοστίζει μερικά σεντς και τελειώνει σε λιγότερο από ένα λεπτό. Σε σύγκριση με το κόστος του context switch ενός reviewer, αυτή η αριθμητική βγαίνει σχεδόν σε κάθε όγκο pull request, που είναι ακριβώς ο λόγος που αυτό το pattern εξαπλώνεται.

Αυτή είναι όμως και η παγίδα. Αρκετά φθηνό για να τρέχει σε κάθε PR είναι αρκετά φθηνό για να τρέχει χωρίς να το σκέφτεσαι, και το οριακό κόστος του να προσθέσεις ένα ακόμα permission στο allowlist είναι πάντα μηδέν τη στιγμή που το προσθέτεις. Το κόστος έρχεται αργότερα, μονομιάς. Αποφάσισε το όριο όσο είναι ακόμα θεωρητικό.

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

Ένας agent στο pipeline σου είναι ένας contributor χωρίς κρίση, με άπειρη υπομονή, και όποια credentials έδωσες στον runner. Δώσε του τα στενά εργαλεία για μία δουλειά, προστάτεψε τα αρχεία που κωδικοποιούν τι σημαίνει σωστό, βάλε όριο στο loop, και κάνε τον να ανοίγει pull request όπως όλοι οι άλλοι. Η παραγωγικότητα είναι πραγματική. Προέρχεται από το ότι ο agent κάνει το κουραστικό πρώτο πέρασμα, όχι από την αφαίρεση του ανθρώπου που λέει ναι.

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

• Evals Before Agents: You Can't Ship What You Can't Score, γιατί ένας agent στο CI χωρίς scoreboard είναι ένα vibe check που τρέχει σε κάθε commit.
• IAM for LLM Apps: Least Privilege When the Caller Is a Model, για το πώς ορίζεις τον ρόλο με τον οποίο πραγματικά τρέχει ο agent του pipeline σου.

Για την πλευρά pipeline αυτού, το why automated tests are essential in your CI/CD pipeline καλύπτει τους ελέγχους που πρέπει να περάσει το output ενός agent, στο ercan.cloud. Ο κόμβος είναι στο ercanermis.com.