FrontierCode Diamond: 13,4% συγχωνεύσιμων αλλαγών σε 50 δύσκολες εργασίες (Ιούνιος 2026)

Πρόσθετο υλικό για τη διαμόρφωση εργαλείων υπάρχει στην τεκμηρίωση του Ailoot.

Τι είναι το FrontierCode και γιατί έχει σημασία;#

Η Cognition είναι η εταιρεία πίσω από το Devin (τον πρώτο αυτόνομο μηχανικό AI, Μάρτιος 2024) και το Windsurf (αποκτήθηκε τον Ιούλιο του 2025). Αναπτύσσει επίσης τη δική της σειρά μοντέλων SWE-1.x. Το benchmark δημοσιεύτηκε στο δημόσιο ιστολόγιο στη διεύθυνση cognition.com/blog/frontier-code.

Η βασική αλλαγή δεν αφορά νέους αριθμούς. Αφορά την κλίμακα με την οποία μετράμε πλέον τα πράγματα.

Το benchmark έχει τρία επίπεδα δυσκολίας: Extended (150 εργασίες, το πλήρες σύνολο), Main (οι 100 δυσκολότερες, μαζί με τις Diamond) και Diamond (50 εξαιρετικά δύσκολες εργασίες). Η Cognition άφησε σκόπιμα το Diamond «σε μεγάλο βαθμό χωρίς κορεσμό»—ακόμη και το καλύτερο μοντέλο λύνει λιγότερο από το 15%. Στόχος είναι να έχει το benchmark περιθώριο εξέλιξης για έναν χρόνο και να μην κορεστεί σε έναν μήνα, όπως συνέβη με το HumanEval.

Τι μετρά το FrontierCode: «Θα έκανε ο maintainer merge αυτό το PR;»#

Οι έξι άξονες αξιολόγησης (από το επίσημο ιστολόγιο της Cognition):

1. Συμπεριφορική ορθότητα — επιλύει το patch την εργασία;
2. Ασφάλεια έναντι παλινδρομήσεων — αποφεύγει να χαλάσει υπάρχοντα κώδικα;
3. Μηχανική καθαρότητα — περνά τους ελέγχους build, lint και στυλ;
4. Ορθότητα δοκιμών — είναι έγκυρες οι δοκιμές που έγραψε ο agent (δεν μετρούν δοκιμές που περνούν με οποιονδήποτε κώδικα);
5. Πεδίο εφαρμογής — αποφεύγει το patch να αγγίξει αρχεία που δεν ζητήθηκαν;
6. Ποιότητα κώδικα — ακολουθεί ο κώδικας τις συμβάσεις του έργου και είναι ευανάγνωστος;

Για να θεωρηθεί ένα patch κατάλληλο για merge, πρέπει να περάσει και τους έξι άξονες. Αν αποτύχει έστω και σε έναν, δεν θα γίνει merge.

Αυτή είναι η βασική αλλαγή στην οπτική. «Η ορθότητα είναι πλέον προαπαιτούμενο», όπως το διατυπώνει η Cognition. Παλαιότερα, τα benchmarks ρωτούσαν «Πέρασε ο κώδικας τις δοκιμές;». Τώρα ρωτούν «Θα δεχόταν ένας πραγματικός tech lead να ενταχθεί αυτό στο έργο;»

Η Cognition εισήγαγε τρεις νέες τεχνικές βαθμολόγησης:

• Reverse-Classical: μια δοκιμή που γράφτηκε από agent πρέπει να αποτυγχάνει σε μια προβληματική έκδοση του κώδικα. Διαφορετικά, η δοκιμή είναι προσχηματική.
• Code Scope: ένας αυτοματοποιημένος έλεγχος επαληθεύει ότι το patch μένει μέσα στα αρχεία και στο πλήθος γραμμών που συμφωνήθηκαν για την εργασία.
• Adaptive Classical Grading: το εργαλείο LLM «mutagent» προσαρμόζει αυστηρές δοκιμές σε έγκυρες παραλλαγές λύσεων.

Γιατί δεν λειτουργούν πια τα παλιά benchmarks;#

Οι AI agents είχαν ήδη αριστεύσει στο HumanEval έως το 2024. Το SWE-bench Verified είναι σε μεγάλο βαθμό το ίδιο: τον Αύγουστο του 2025, η OpenAI παραδέχτηκε δημόσια το πρόβλημα επιμόλυνσης (τα μοντέλα είχαν «δει» το σύνολο δεδομένων κατά την εκπαίδευση). Τα benchmarks έχασαν την ικανότητά τους να ξεχωρίζουν τα κορυφαία μοντέλα.

Η βασική μελέτη που υπονόμευσε το παλιό μέτρο δημοσιεύτηκε τον Μάρτιο του 2026.

Τι έκαναν:

• Επέλεξαν 4 ενεργούς maintainers από 3 αποθετήρια (scikit-learn, Sphinx, pytest).
• Τους ζήτησαν να αξιολογήσουν 296 PR που δημιουργήθηκαν από AI από το SWE-bench Verified—όλα αυτά τα PR περνούσαν αυτοματοποιημένες δοκιμές.
• Συνέκριναν τις αποφάσεις των maintainers με εκείνες του αυτοματοποιημένου αξιολογητή.

Με άλλα λόγια, το benchmark λέει «πέρασε», ενώ ο maintainer λέει «δεν θα γίνει merge»—και αυτό συμβαίνει κατά μέσο όρο σε ένα τέταρτο των περιπτώσεων. Οι 3 σημαντικότεροι λόγοι απόρριψης, από τον λιγότερο προς τον σοβαρότερο:

1. Ποιότητα κώδικα — δεν ταιριάζει με το στυλ του αποθετηρίου.
2. Χαλάει άλλο κώδικα — χαλάει γειτονικό κώδικα.
3. Αποτυχία βασικής λειτουργικότητας — δεν επιλύει πλήρως την εργασία, παρότι η δοκιμή είναι πράσινη.

Το FrontierCode επισημοποιεί ακριβώς αυτό το πρόβλημα. Η Cognition πήρε αυτή την ιδέα και την επέκτεινε σε ένα πλήρες benchmark με περισσότερους από 20 maintainers αντί για 4.

Ένα ακόμη καρφί στο φέρετρο είναι μια μελέτη του Δεκεμβρίου 2025 για την ασφάλεια των patch που δημιουργούνται από AI.

Σε αυτήν, το 61% των λύσεων του SWE-Agent με Claude 4 Sonnet ήταν λειτουργικά ορθό, αλλά μόνο το 10.5% ήταν ασφαλές.

Ο κώδικας περνά τη δοκιμή, κι όμως κάθε δεύτερο patch εισάγει ένα κενό ασφαλείας. Δεν μπορείτε να το δείτε καθόλου στα benchmarks του SWE-bench—δεν μετρούν την ασφάλεια. Το FrontierCode τουλάχιστον προσπαθεί να το εντοπίσει μέσω των αξόνων «μηχανική καθαρότητα» και ποιότητα κώδικα.

Πού κατατάσσονται τα μοντέλα: Opus 4.8 στο 13.4%, GPT-5.5 στο 6.3%#

Τι ξεχωρίζει από τον πίνακα:

• Ένας ξεκάθαρος πρωτοπόρος. Το Opus 4.8 της Anthropic προηγείται περίπου διπλάσια από τον πλησιέστερο ανταγωνιστή του. Το χάσμα που ήταν δύσκολο να παρατηρηθεί στο SWE-bench είναι ολοφάνερο στο FrontierCode.
• Τα μοντέλα ανοιχτού κώδικα δεν έχουν φτάσει ακόμη. Το Kimi K2.6—το καλύτερο μοντέλο ανοιχτού κώδικα—βαθμολογείται με 3.8% στο Diamond. Αυτό είναι 3–4 φορές χαμηλότερο από το Opus 4.8. Η Cognition δεν δημοσίευσε πλήρη πίνακα για το Kimi K2.6 στα Main και Extended, οπότε δεν υπάρχει ακόμη σύγκριση στο πλήρες σύνολο.
• Η Cognition τοποθέτησε ειλικρινά το δικό της μοντέλο στο χαμηλότερο μέρος του πίνακα.

Το υποσύνολο Diamond έμεινε σκόπιμα «χωρίς κορεσμό». Η Cognition έχτισε ένα περιθώριο ασφαλείας για τα επόμενα χρόνια. Αν τα προηγούμενα benchmarks κορέστηκαν σε 12–18 μήνες, το FrontierCode έχει σχεδιαστεί με υψηλότερο όριο.

Τι σημαίνει το «13% κατάλληλο για merge» για κάποιον που κάνει vibe coding με το Claude Code;#

Πρώτα, μια σημαντική αναδιατύπωση του πλαισίου: το σύνολο Diamond του FrontierCode είναι σκόπιμα εξαιρετικά δύσκολο. Σε συνηθισμένες εργασίες σε ένα νέο έργο startup χωρίς σαράντα εξαρτώμενες μονάδες, ένας AI agent τα πηγαίνει αισθητά καλύτερα. Το ίδιο Opus 4.8 βαθμολογείται με 51.8% κατάλληλο για merge στο Extended (150 εργασίες, το πλήρες σύνολο). Αυτή είναι εντελώς διαφορετική εικόνα.

Το αποτέλεσμα 51.8% αφορά το σύνολο Extended των 150 εργασιών του benchmark. Είναι υψηλότερο από το αποτέλεσμα Diamond, αλλά κανένας αριθμός δεν εκτιμά τη δυνατότητα merge των patches κάθε μοντέλου στις δικές σας εργασίες. Οι βαθμολογίες Main ή Extended που λείπουν για άλλα μοντέλα δεν δικαιολογούν τη συμπλήρωση της επίδοσής τους.

Τι σημαίνει αυτό για κάποιον που κάνει vibe coding και προωθεί κώδικα στην παραγωγή:

• Μια πράσινη δοκιμή δεν σημαίνει πλέον «έτοιμο για merge». Οι δοκιμές που γράφει η ίδια η AI μπορεί να είναι άχρηστες—περνούν με οποιονδήποτε κώδικα. Το FrontierCode το μετρά άμεσα μέσω του Reverse-Classical: αν μια δοκιμή δεν αποτυγχάνει σε μια προβληματική έκδοση, δεν μετρά.
• Το στυλ και οι συμβάσεις του αποθετηρίου έχουν σημασία. Αν ένα έργο έχει καθιερωμένο μοτίβο και η AI δεν το ακολουθεί, ένας πραγματικός συνεργάτης δεν θα δεχτεί την αλλαγή. Σε ατομικά έργα χωρίς κανόνες, αυτό δεν είναι σημαντικό. Σε μια ομάδα, είναι το νούμερο ένα πρόβλημα.
• Οι δοκιμές δεν λύνουν το ζήτημα της ασφάλειας. Θυμηθείτε το παραπάνω στοιχείο: μόνο το 10.5% των patch είναι ασφαλή, παρότι το 61% είναι σωστό. Αυτό πρέπει να ελέγχεται ξεχωριστά, με εργαλεία που εντοπίζουν token, αρχεία .env και προεπιλεγμένους κωδικούς πρόσβασης.
• Η υπέρβαση του πεδίου της εργασίας είναι τυπικό λάθος της AI. Της ζητάτε να διορθώσει μια συνάρτηση εξουσιοδότησης και παίρνετε ένα patch που ξαναέγραψε επίσης το εσωτερικό επίπεδο και την καταγραφή συμβάντων. Αυτός είναι ένας από τους 6 άξονες του FrontierCode.

Ποιες 6 κατηγορίες σφαλμάτων κάνει η AI σε δύσκολες εργασίες;#

Ας εξετάσουμε κάθε άξονα με απλά λόγια:

1. Συμπεριφορική ορθότητα — επιλύει το patch την εργασία;

Ο πιο βασικός άξονας. Η AI συχνά γράφει κώδικα που μοιάζει με λύση, αλλά επιλύει λάθος πρόβλημα. Της ζητώ να «προσθέσει ένδειξη ανάγνωσης στο μήνυμα» και παίρνω μια συνάρτηση markAsRead, αλλά δεν έχει συνδεθεί με το ίδιο το στοιχείο συνομιλίας. Η δοκιμή της συνάρτησης περνά. Η επιχειρηματική εργασία δεν έχει επιλυθεί.

2. Ασφάλεια έναντι παλινδρομήσεων — αποφεύγει να χαλάσει γειτονικό κώδικα;

Η AI αλλάζει μία μονάδα και τώρα κάποια άλλη δεν λειτουργεί. Η συνηθέστερη περίπτωση: ένας AI agent αλλάζει την υπογραφή μιας συνάρτησης, ξεχνώντας ότι καλείται από 17 άλλα σημεία. Δεν μπορείτε να το δείτε αυτό στο SWE-bench—εκεί εκτελούν δοκιμές μόνο για ένα αρχείο. Στο FrontierCode εκτελούν ολόκληρη τη σουίτα δοκιμών του αποθετηρίου.

3. Μηχανική καθαρότητα — περνά τους ελέγχους build, lint και στυλ;

Η AI μπορεί να παράγει κώδικα που μεταγλωττίζεται τοπικά αλλά αποτυγχάνει στο CI: μια εισαγωγή που λείπει, tabs αντί για κενά, δύο τελικά κενά ή ένα λάθος στο eslint.config.js. Σε ένα ενεργό έργο, το στυλ δεν είναι ιδιοτροπία· είναι κανόνας της ομάδας.

4. Ορθότητα δοκιμών — είναι έγκυρες οι δοκιμές που γράφει η AI;

Ο πιο δύσκολος άξονας. Η AI γράφει μια δοκιμή που περνά. Όμως περνά με οποιονδήποτε κώδικα, ακόμη και με προβληματικό κώδικα. Το έχω δει πολλές φορές: η δοκιμή ελέγχει «αν κατέρρευσε το script» και όχι «αν επέστρεψε το σωστό αποτέλεσμα». Το Reverse-Classical του FrontierCode εντοπίζει ακριβώς αυτή την περίπτωση.

5. Πεδίο εφαρμογής — αποφεύγει το patch να αγγίζει άσχετα αρχεία;

Της ζητώ να διορθώσει μία συνάρτηση και παίρνω patch για 12 αρχεία, μεταξύ των οποίων και αρχεία άσχετα με την εργασία. Αυτή είναι η ίδια «πρωτοβουλία» της AI που χαλάει ένα έργο παραγωγής, αλλάζοντας πράγματα που δεν της ζήτησα να αλλάξει. Αυτός ο άξονας αποτελεί απόλυτο εμπόδιο στο FrontierCode.

6. Ποιότητα κώδικα — ακολουθεί ο κώδικας τις συμβάσεις του αποθετηρίου;

Η AI γράφει τη δική της συνάρτηση «από την αρχή» αντί να χρησιμοποιήσει υπάρχοντες βοηθούς στο lib/. Ή ονομάζει μεταβλητές με τρόπο που δεν ταιριάζει στο στυλ του έργου. Ή βάζει λογική σε λάθος αρχιτεκτονικό επίπεδο. Από την οπτική της δοκιμής, όλα λειτουργούν. Από την οπτική του tech lead, δεν θα γίνει merge.

Πώς να ελέγχετε τον κώδικα AI πριν από το push: 5 βήματα#

1. Εκτελέστε ολόκληρη τη σουίτα δοκιμών, όχι μόνο τις δοκιμές που σχετίζονται με την αλλαγή

   Η AI συχνά αλλάζει κώδικα πέρα από την εργασία. Το πρόβλημα θα φανεί σε γειτονικές δοκιμές. Εκτελώ ολόκληρη τη σουίτα δοκιμών (με τη μοναδική εντολή npm test, χωρίς διαδρομή), όχι μόνο δοκιμές για ένα συγκεκριμένο αρχείο. Σε μεγάλα έργα, είναι βολικό να γίνεται αυτό παράλληλα με ένα git worktree (βλ. Git worktree στο Claude Code).

2. Εκτελέστε ελέγχους lint, στυλ και τύπων

   Τρεις εντολές με τη σειρά: eslint ., prettier --check ., tsc --noEmit. Ένας AI agent μπορεί να παραβλέψει τόσο ένα tab όσο και ένα επιπλέον τελικό κενό. Αν το έργο έχει αυστηρούς ελέγχους, εκτελέστε τους τοπικά πριν από την κυκλοφορία.

3. Ελέγξτε την ίδια τη δοκιμή

   Ο σημαντικότερος από τους 5 ελέγχους. Κάνω μια μικρή «ζημιά» στον κώδικα (αλλάζω το return true σε return false). Η δοκιμή πρέπει να αποτύχει. Αν η δοκιμή δεν αποτύχει, η AI την έγραψε μόνο για τα μάτια του κόσμου και είναι άχρηστη. Διαγράφω τη δοκιμή και ζητώ από την AI να την ξαναγράψει με υποχρεωτική προϋπόθεση: η δοκιμή πρέπει να αποτυγχάνει στην προβληματική έκδοση.

4. Ελέγξτε ποια αρχεία άγγιξε η AI

   Η εντολή git diff --stat δείχνει ποια αρχεία άλλαξαν και πόσες γραμμές. Αν η AI άγγιξε 12 αρχεία έπειτα από το αίτημα «διόρθωσε τη φόρμα επικοινωνίας», ξεπέρασε το πεδίο της εργασίας. Επαναφέρω τα επιπλέον αρχεία με μία μόνο εντολή για το αρχείο.

5. Εκτελέστε έλεγχο ασφάλειας με έτοιμο skill

   Οι δοκιμές δεν εντοπίζουν SQL injection ή ενσωματωμένους κωδικούς πρόσβασης. Χρησιμοποιώ ένα έτοιμο skill ασφάλειας για το Claude Code (βλ. 754 έτοιμα skills ασφάλειας). Τουλάχιστον, αναζητήστε χειροκίνητα στο έργο τις λέξεις «password», «secret» και «key» στον κώδικα και ελέγξτε ότι το .env.example είναι πλήρες.

Και τα 5 βήματα καλύπτουν τους 5 από τους 6 άξονες του FrontierCode (1–5). Ο έκτος άξονας—η ποιότητα κώδικα—ελέγχεται αυτόματα μέσω του lint και ενός ανθρώπινου ελέγχου.

Τι βελτιώνει στην πράξη τις πιθανότητες για κώδικα κατάλληλο για merge;#

Ένας AI agent σε ένα απροετοίμαστο έργο βλέπει μόνο το αρχείο που έχετε ανοίξει για αυτόν. Δεν έχει το ιστορικό των αποφάσεών σας, ούτε τις συμβάσεις σας, ούτε έναν χάρτη των μονάδων σας. Αυτό δεν είναι μεγάλο πρόβλημα για απλές αλλαγές. Για δύσκολες αλλαγές, η έλλειψη πλαισίου έργου είναι κίνδυνος που αξίζει να αντιμετωπιστεί. Το 13.4% του benchmark δεν απομονώνει την ποιότητα πλαισίου ως αιτία του.

Τι χρειάζεται να κάνετε για να μετατρέψετε αυτό το 13% σε κάτι που μπορείτε πράγματι να προωθήσετε στην παραγωγή:

1. Κανόνες έργου — ώστε η AI να αναπαράγει τον τρόπο σκέψης σας αντί για τον μέσο όρο του διαδικτύου.

Πρόκειται για ένα σύνολο έτοιμων λύσεων, συνηθειών και κανόνων που έχετε μάθει, σε μορφή που ο AI agent διαβάζει με κάθε αίτημα. Όταν υπάρχουν 30+ κανόνες, η AI σταματά να επινοεί τον «μέσο όρο του κλάδου» και αρχίζει να κάνει προτάσεις στο δικό σας στυλ. Η υπέρβαση του πεδίου της εργασίας μπορεί να αντιμετωπιστεί με μία γραμμή στους κανόνες: “don't touch files outside those explicitly named in the request.”

2. Χάρτης έργου — ένας φάκελος που περιγράφει το έργο.

Εδώ βάζετε προϊόντα, κοινό, οικονομικά στοιχεία, μετρικές και ρυθμίσεις. Πριν από κάθε αίτημα, ο AI agent διαβάζει τον πίνακα περιεχομένων και καταλαβαίνει σε ποιο μέρος της επιχείρησης εργάζεται. Αυτό αντιμετωπίζει αυτόματα δύο από τους λόγους απόρριψης που αναφέρθηκαν παραπάνω: το στυλ και τη βλάβη άλλου κώδικα.

3. Context Engineering — διαχείριση όσων βλέπει η AI πριν από το αίτημα.

Δεν είναι «πώς να διατυπώσετε μια προτροπή», αλλά «τι να βάλετε στο παράθυρο συμφραζομένων ΠΡΙΝ από την προτροπή». CLAUDE.md, προαπαιτούμενα και στοχευμένοι σύνδεσμοι προς αρχεία. Αυτό αντιμετωπίζει τις αστοχίες συμπεριφορικής ορθότητας και ποιότητας κώδικα.

Χρησιμοποιήστε τον συνδυασμό ως προετοιμασία για τους ελέγχους, όχι ως απόδειξη ότι πέντε άξονες έχουν ήδη περάσει. Επαληθεύστε συμπεριφορά, παλινδρομήσεις, δοκιμές, εύρος και ποιότητα κώδικα στο πραγματικό patch πριν το αποδεχτείτε.

Ένα επιπλέον επίπεδο είναι οι agents ελέγχου:

• Cursor Bugbot — εκτελεί έλεγχο σε κάθε PR. Σύμφωνα με την Cursor, το εργαλείο επεξεργάζεται περίπου 2 εκατομμύρια PR τον μήνα.
• Ενσωματωμένοι subagents στο Claude Code v2.1.172 — ένας agent γράφει τον κώδικα, ένας δεύτερος τον ελέγχει και ένας τρίτος εκτελεί δοκιμές. Είναι η ίδια ιδέα με το FrontierCode: διαχωρισμός των ρόλων του «συγγραφέα» και του «tech lead».

Δείτε επίσης: Ασφάλεια στο vibe coding, Πώς να ρυθμίσετε το Claude Code ώστε να μην χαλάει το έργο σας τη νύχτα και το Context Engineering ως έννοια.

Για πρόσθετο υλικό σχετικά με την εργασία με εργαλεία, δείτε την τεκμηρίωση του Ailoot.