Coding agents: το ίδιο AI μπορεί να αποδίδει αλλιώς ανάλογα με το harness

Το ίδιο μοντέλο AI μπορεί να δώσει πολύ διαφορετικό αποτέλεσμα στον προγραμματισμό, ακόμη κι όταν το task, τα εργαλεία και ο διαθέσιμος χρόνος παραμένουν ίδια. Η αιτία δεν βρίσκεται πάντα στα model weights. Συχνά βρίσκεται στο coding agent harness: το σύστημα που οργανώνει το context, εκθέτει τα εργαλεία, επιστρέφει τα αποτελέσματα και αποφασίζει πότε η προσπάθεια συνεχίζεται ή σταματά.

Η μελέτη «Same Model, Different Harness: Different Coding-Agent Results» της Sydney Lewis απομονώνει αυτή τη μεταβλητή. Συγκρίνει δύο διαμορφώσεις του ίδιου open-source harness, με κοινά tasks, μοντέλο, evaluator και χρονικό όριο. Όταν το context πιέστηκε, η διαμόρφωση που συντόμευε μηχανικά τα παλιά tool results και αντιδρούσε σε επαναλαμβανόμενη ή στάσιμη εργασία πέτυχε περισσότερη μερική πρόοδο και περισσότερες πλήρεις λύσεις σε δύο benchmarks.

Για μια επιχείρηση που αγοράζει ή αναπτύσσει AI εργαλεία για software development, το πρακτικό συμπέρασμα είναι σαφές: δεν αξιολογείται μόνο το μοντέλο. Αξιολογείται το μοντέλο μαζί με το harness, το runtime, τα permissions, τα tests και τον τρόπο μέτρησης του αποτελέσματος.

Τι είναι το coding agent harness

Ένας coding agent ξεκινά από ένα issue, ένα repository και έναν στόχο. Αναζητά σχετικά αρχεία, διαβάζει κώδικα, εκτελεί εντολές, κάνει edits και τρέχει tests. Το μοντέλο προτείνει τις επόμενες ενέργειες, αλλά δεν έρχεται σε άμεση επαφή με το repository. Το harness μεταφράζει τις αποφάσεις του σε πραγματικές ενέργειες και επιστρέφει τα αποτελέσματα στην επόμενη κλήση.

Στην πράξη, το harness ορίζει το system prompt, το διαθέσιμο tool interface, τη μορφή των tool results, τα permissions, το sandbox, τους κανόνες retry, την πολιτική context και τα κριτήρια τερματισμού. Αποφασίζει επίσης ποιο patch θα κρατηθεί, πότε θα εκτελεστεί ο evaluator και ποια στοιχεία θα καταγραφούν για audit. Γι’ αυτό δύο προϊόντα με τα ίδια model weights μπορούν να συμπεριφέρονται διαφορετικά στο ίδιο repository.

Η συγκεκριμένη εργασία χρησιμοποιεί το Yuj, ένα open-source coding agent harness, και συγκρίνει δύο ρυθμίσεις του ίδιου συστήματος. Αυτή η επιλογή είναι σημαντική: η διαφορά δεν αποδίδεται σε δύο εντελώς διαφορετικά προϊόντα, αλλά σε ένα συγκεκριμένο πακέτο διαχείρισης context, ανίχνευσης στασιμότητας και command safeguards.

Η ευρύτερη αρχιτεκτονική είναι παρόμοια με όσα περιγράφονται και στους terminal agents ως πλήρες σύστημα: model, harness, runtime και governance λειτουργούν μαζί. Το όνομα του μοντέλου περιγράφει μόνο ένα μέρος της τελικής εμπειρίας.

Γιατί το πλήρες transcript γίνεται περιορισμός

Κάθε βήμα ενός agent αφήνει κείμενο πίσω του: αποτελέσματα αναζήτησης, ολόκληρα αρχεία, logs, errors, test output, απαντήσεις του μοντέλου και νέες εντολές. Αν όλα αυτά επαναλαμβάνονται αυτούσια σε κάθε επόμενη κλήση, το transcript μεγαλώνει μέχρι να καταλάβει το διαθέσιμο context window.

Στη control διαμόρφωση της μελέτης, το μοντέλο έβλεπε την πλήρη χρονολογική συνομιλία μετά από έναν κοινό βασικό καθαρισμό των tool results. Όταν το transcript δεν χωρούσε πλέον, η εκτέλεση σταματούσε ακόμη κι αν το patch δεν είχε ολοκληρωθεί. Ένα μεγάλο setup output ή ένα πρόωρο test log μπορούσε έτσι να καταναλώσει χώρο που θα ήταν χρησιμότερος αργότερα για νέο κώδικα και verification.

Το ουσιαστικό product insight είναι η διάκριση ανάμεσα στο μόνιμο audit record și în τρέχον working context. Το πρώτο πρέπει να διατηρείται για debugging, λογοδοσία και αναπαραγωγή. Το δεύτερο πρέπει να περιέχει ό,τι χρειάζεται η επόμενη απόφαση, χωρίς να επαναλαμβάνει αδιακρίτως όλο το παρελθόν. Το ίδιο δίλημμα εμφανίζεται σε μεγάλα research workflows, όπου το μεγαλύτερο context δεν αντικαθιστά τη σωστή επιλογή και σύνθεση πληροφορίας.

Τι άλλαξε στο treatment harness

Το treatment κρατούσε το πλήρες execution record, αλλά ανακατασκεύαζε τη working view πριν από κάθε νέο βήμα. Όταν η εκτιμώμενη χρήση έφτανε στο μισό του διαθέσιμου context window, παλαιότερα tool results συντομεύονταν μηχανικά. Τα τέσσερα νεότερα αποτελέσματα παρέμεναν πλήρη, ενώ από τα παλαιότερα διατηρούνταν η αρχή και το τέλος μέσα σε όρια που μειώνονταν όσο το αποτέλεσμα γερνούσε.

Η πολιτική ήταν ντετερμινιστική. Δεν χρησιμοποιούσε δεύτερο μοντέλο για περίληψη και δεν προσπαθούσε να μαντέψει σημασιολογικά ποιο detail είναι σημαντικό. Αυτό διευκολύνει το audit, επειδή η ομάδα μπορεί να δει ποιος κανόνας περιόρισε ποιο output. Δημιουργεί όμως και ρίσκο: ένα παλιό detail μπορεί να χρειαστεί αργότερα. Η εργασία δεν συγκρίνει τη μέθοδο με model-written summaries ή retrieval, άρα δεν τεκμηριώνει ότι είναι η καλύτερη γενική λύση.

Το treatment πρόσθετε επίσης detector για δύο μορφές στασιμότητας: επανάληψη της ίδιας αποτυχημένης εντολής και επαναλαμβανόμενη ανάγνωση αρχείων χωρίς edit. Όταν εμφανιζόταν το αντίστοιχο μοτίβο, το harness έδινε σταθερή απόκριση που ζητούσε διαφορετική ενέργεια προς τον στόχο. Το μοντέλο εξακολουθούσε να αποφασίζει την αλλαγή· ο detector δεν παρήγαγε κώδικα.

Το πακέτο περιλάμβανε ακόμη safeguards για προβλέψιμα προβλήματα εντολών, όπως υπερβολικό setup output ή απαγορευμένες ενέργειες. Η μελέτη αξιολογεί το πακέτο ως σύνολο. Δεν απομονώνει πόση από τη διαφορά προήλθε από τη συντόμευση, πόση από τον detector και πόση από τα command safeguards.

Πώς σχεδιάστηκε η paired σύγκριση

Κάθε επιλεγμένο task εκτελέστηκε μία φορά με control και μία φορά με treatment. Στα δύο arms διατηρήθηκαν ίδια τα model weights, το task, το context capacity, το tool interface, το serving setup, ο evaluator και το πρωτόκολλο. Η βασική μεταβλητή ήταν το configuration package του harness.

Το κύριο μοντέλο ήταν το Qwen3.6-35B-A3B σε τετραμπιτική έκδοση, τοπικά εξυπηρετούμενο μέσω llama-server. Τα benchmarks ήταν SWE-bench Verified, SWE-bench Pro και FeatureBench. Το Verified tight-window cohort περιλάμβανε 169 tasks, το Pro 316 και το FeatureBench 183 εκτελέσιμα canonical tasks. Οι model steps εκτελούνταν χωρίς network access και χωρίς πρόσβαση σε gold patches ή scorer-only inputs.

Η αξιολόγηση χρησιμοποίησε δύο αποτελέσματα. Η πλήρης επίλυση έδειχνε αν ο evaluator δεχόταν ολόκληρο το task. Το F2PF, δηλαδή fail-to-pass fraction, μετρούσε το ποσοστό των tests που απέτυχαν πριν από το patch και περνούσαν μετά. Έτσι η εργασία κατέγραφε και μερική πρόοδο χωρίς να τη βαφτίζει ολοκληρωμένη λύση. Το επίσημο SWE-bench περιγράφει το Verified ως ανθρώπινα φιλτραρισμένο υποσύνολο πραγματικών GitHub issues, με ποσοστό resolved ως βασική δημόσια μέτρηση.

Τα αποτελέσματα υπό πίεση context

Στο SWE-bench Verified με παράθυρο 20.480 tokens και σταθερό endpoint 480 δευτερολέπτων, το μέσο F2PF αυξήθηκε από 28,0% στο control σε 49,1% στο treatment. Οι πλήρεις λύσεις αυξήθηκαν από 43 σε 72. Πρόκειται για διαφορά 21,1 ποσοστιαίων μονάδων στη μερική αποκατάσταση των failing tests και 29 επιπλέον πλήρεις λύσεις στο κοινό cohort.

Στο SWE-bench Pro με παράθυρο 49.152 tokens, το F2PF αυξήθηκε από 15,2% σε 32,7% και οι πλήρεις λύσεις από 31 σε 72. Στο FeatureBench με 47.104 tokens, το F2PF αυξήθηκε από 10,5% σε 19,6%, αλλά οι πλήρεις λύσεις ήταν μόλις 2 και 3. Το τελευταίο αποτέλεσμα δείχνει γιατί χρειάζονται και οι δύο μετρήσεις: περισσότερα tests μπορεί να περνούν χωρίς το συνολικό feature task να έχει λυθεί.

Στις task-level δοκιμές, η κατεύθυνση του F2PF ήταν υπέρ του treatment και στα τρία πιεσμένα cohorts. Στην repository-level ανάλυση, η διαφορά F2PF παρέμεινε θετική, αλλά η στατιστική εικόνα για τις πλήρεις λύσεις ήταν πιο σύνθετη: στο Verified το προσαρμοσμένο direction test δεν πέρασε το ίδιο όριο, ενώ στο Pro παρέμεινε ισχυρό και στο FeatureBench οι πλήρεις λύσεις ουσιαστικά δεν άλλαξαν.

Όταν το context δεν είναι στενό σημείο

Η πιο χρήσιμη αντίστιξη εμφανίζεται στο ίδιο Verified cohort καθώς μεγαλώνει το context window. Η διαφορά F2PF υπέρ του treatment ήταν 21,1 ποσοστιαίες μονάδες στα 20.480 tokens, 6,4 μονάδες στα 43.008 και -0,3 μονάδες στα 262.144. Στο μεγαλύτερο παράθυρο, λιγότερο από 1% των tasks σε κάθε benchmark και arm έφτασε το όριο context.

Στο wide-window Verified, οι πλήρεις λύσεις ήταν 102 στο control και 101 στο treatment, ενώ το μέσο F2PF ήταν 69,0% και 68,7%. Το treatment εξυπηρέτησε κατά μέσο όρο λιγότερα prompt tokens ανά turn, αλλά οι παρατηρούμενες επιδόσεις παρέμειναν κοντά. Αυτό στηρίζει μια στενή, όχι καθολική, ερμηνεία: η συγκεκριμένη πολιτική βοηθά κυρίως όταν το αυξανόμενο transcript γίνεται πραγματικός περιορισμός.

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

Το ίδιο πακέτο σε τρία ακόμη μοντέλα

Οι ερευνητές πάγωσαν το treatment και το εφάρμοσαν χωρίς model-specific retuning στο ίδιο Verified cohort των 169 tasks, με παράθυρο 20.480 tokens και χρονικό όριο 480 δευτερολέπτων. Στο Devstral, το F2PF ανέβηκε από 17,2% σε 36,8% και οι πλήρεις λύσεις από 22 σε 53. Στο Nemotron, το F2PF ανέβηκε από 12,0% σε 18,3% και οι λύσεις από 16 σε 25. Στο Qwen3.8, το F2PF αυξήθηκε από 20,4% σε 35,3% και οι λύσεις από 32 σε 54.

Η μεταφορά του ίδιου πακέτου σε τρεις ακόμη αρχιτεκτονικές μειώνει την πιθανότητα το αποτέλεσμα να είναι ιδιομορφία ενός checkpoint. Δεν αποδεικνύει καθολική γενίκευση. Η μελέτη καλύπτει τέσσερα τοπικά open-weight checkpoints, συγκεκριμένες τετραμπιτικές εκδόσεις και repository-level coding tasks. Δεν αξιολογεί hosted frontier models, διαφορετικά tool ecosystems ή άλλες επιχειρηματικές εργασίες.

Το εύρημα συνδέεται με ένα ευρύτερο πρόβλημα επιλογής στους agents: η συμπεριφορά δεν είναι μόνο ιδιότητα του μοντέλου. Όπως δείχνει και η ανάλυση για τις προτιμήσεις των AI μοντέλων μέσα σε agentic workflows, το interface, η σειρά των επιλογών και οι κανόνες του συστήματος επηρεάζουν τι τελικά γίνεται.

Τι δεν αποδεικνύουν οι αριθμοί

Κάθε task είχε μία greedy trajectory ανά arm. Δεν μετρήθηκε run-to-run variation και δεν υπολογίστηκε πιθανότητα επιτυχίας από επαναλαμβανόμενες προσπάθειες. Δεν υπήρξε ανθρώπινη αξιολόγηση της ποιότητας των patches ως τελικό endpoint. Άρα δεν γνωρίζουμε πόσο σταθερά θα επαναλαμβανόταν το αποτέλεσμα ούτε αν δύο patches που περνούν τα ίδια tests είναι εξίσου συντηρήσιμα.

Το treatment συνδυάζει συντόμευση tool results, stall detection και safeguards. Χωρίς ablation δεν γνωρίζουμε την ξεχωριστή συνεισφορά κάθε μηχανισμού. Επίσης, η σύγκριση έγινε απέναντι σε πλήρες χρονολογικό transcript και όχι απέναντι σε retrieval ή model-generated summaries. Μια διαφορετική baseline πολιτική context θα μπορούσε να αλλάξει το μέγεθος της διαφοράς.

Η προέλευση των ρυθμίσεων από προηγούμενη ανάπτυξη στις ίδιες benchmark families δημιουργεί ακόμη έναν λόγο προσοχής. Οι συγγραφείς ζητούν επόμενα πειράματα που θα απομονώσουν τον detector, θα μεταβάλλουν μόνο τον χρόνο, θα επιτρέψουν προσαρμογή του harness στην κατάσταση του task και θα επαναλάβουν κάθε task πολλές φορές.

Πώς αξιολογείται ένας coding agent στην πράξη

Ο πρώτος κανόνας είναι να γράφεται ο tested solver ως ζεύγος: model + harness. Η αναφορά πρέπει να περιλαμβάνει model version, reasoning settings, system prompt, tool schema, permissions, sandbox, context policy, retry rules, time budget, evaluator και κανόνα επιλογής του τελικού patch. Χωρίς αυτά, ένα score δεν είναι επαναλήψιμο και δεν μεταφέρεται με ασφάλεια σε άλλο προϊόν.

Ο δεύτερος κανόνας είναι η χρήση ρεαλιστικών tasks από τα δικά σας repositories. Τα public benchmarks δίνουν κοινό σημείο αναφοράς, αλλά δεν καλύπτουν την αρχιτεκτονική, τα tests, τις εξαρτήσεις και τα deployment constraints της επιχείρησης. Ένα καλό pilot περιλαμβάνει bug fixes, μικρά features, refactors, migration work και tasks που απαιτούν ανάγνωση πολλών αρχείων πριν από το πρώτο edit.

Ο τρίτος κανόνας είναι η μέτρηση πέρα από το pass/fail. Χρειάζονται complete resolution, μερική πρόοδος, regression failures, χρόνος, turns, prompt tokens, tool errors, αιτία τερματισμού, ανθρώπινη διόρθωση και κόστος ανά αποδεκτή λύση. Για workflows με retries, budgets και εξωτερικές ενέργειες, η προσέγγιση πρέπει να εξετάζει και όσα αναλύονται στο Agent Mesh για ελεγχόμενα retries και evidence.

Ένα pilot για model και harness μαζί

Το pilot πρέπει να απαντά σε μία συγκεκριμένη επιχειρηματική απόφαση: αν ο agent είναι αρκετά αξιόπιστος για έναν ορισμένο τύπο task και με ποιο επίπεδο ανθρώπινου ελέγχου. Δεν χρειάζεται να ξεκινήσει με δεκάδες μοντέλα. Χρειάζεται σταθερό protocol, καθαρό baseline και επαναλαμβανόμενες εκτελέσεις.

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

Ασφάλεια, διακυβέρνηση και παρατηρήσιμη λειτουργία

Η διαχείριση context δεν πρέπει να αποσυνδεθεί από την ασφάλεια. Το durable record χρειάζεται πολιτική retention, έλεγχο πρόσβασης και προστασία μυστικών. Τα tool results μπορεί να περιέχουν source code, paths, προσωπικά δεδομένα ή credentials. Η συντόμευση της working view δεν τα αφαιρεί από το audit log ούτε μειώνει από μόνη της το ρίσκο αποθήκευσης.

Τα permissions πρέπει να εφαρμόζονται στο runtime και όχι μόνο να περιγράφονται στο prompt. Network access, write scope, package installation, branch protection και δυνατότητα εκτέλεσης scripts χρειάζονται τεχνικά όρια. Το NIST AI RMF προτείνει η αξιοπιστία να ενσωματώνεται στον σχεδιασμό, την ανάπτυξη, τη χρήση και την αξιολόγηση των AI συστημάτων· για coding agents αυτό μεταφράζεται σε μετρήσιμους ελέγχους πριν, κατά τη διάρκεια και μετά την εκτέλεση.

Τέλος, η ομάδα πρέπει να παρακολουθεί την ίδια την πολιτική harness. Κάθε αλλαγή σε truncation, retries, tool schemas ή stop rules μπορεί να μεταβάλει το tested solver, ακόμη κι αν το μοντέλο δεν αλλάξει. Οι ρυθμίσεις αυτές χρειάζονται versioning, release notes, regression cohort και δυνατότητα rollback όπως κάθε άλλο κρίσιμο κομμάτι λογισμικού.

Το επιχειρηματικό συμπέρασμα

Η μελέτη δεν αποδεικνύει ότι ένα συγκεκριμένο coding agent harness είναι πάντα καλύτερο. Αποδεικνύει κάτι πιο χρήσιμο: το harness είναι μέρος του συστήματος που λύνει το task και μπορεί να αλλάξει αισθητά το αποτέλεσμα χωρίς αλλαγή στα model weights. Η επίδρασή του γίνεται ιδιαίτερα ορατή όταν το context, ο χρόνος και τα tool outputs πιέζουν την εκτέλεση.

Για buyers, η ερώτηση «ποιο μοντέλο χρησιμοποιεί;» είναι ανεπαρκής. Χρειάζεται να προστεθούν: τι βλέπει το μοντέλο σε κάθε βήμα, πώς συμπιέζεται το ιστορικό, πώς ανιχνεύονται loops, ποια εργαλεία και permissions υπάρχουν, πώς επαληθεύεται το patch και ποια δεδομένα αποδεικνύουν σταθερή απόδοση στα δικά μας repositories.

Για builders, το harness δεν είναι αόρατη υποδομή. Είναι προϊόν, με δικές του αποφάσεις σχεδιασμού, κινδύνους και metrics. Όταν model και harness αξιολογούνται μαζί, η συζήτηση μετακινείται από τα εντυπωσιακά demos σε κάτι πολύ πιο χρήσιμο: ελεγχόμενη, επαναλήψιμη και επιχειρηματικά ασφαλή παραγωγή λογισμικού.