Στις απαρχές της μηχανικής, πολύ πριν κατασκευάσω τα φτερά για μένα και τον γιο μου, η δημιουργία ήταν συχνά ζήτημα δοκιμής και σφάλματος. Αλλά το σφάλμα στους αιθέρες είναι μοιραίο. Σήμερα, βρισκόμαστε σε μια παρόμοια «στιγμή Ικάρου» με τους AI agents. Χτίζουμε πολύπλοκα συστήματα που μπορούν να σκεφτούν και να δράσουν, κι όμως, το μεγαλύτερο μέρος της ανάπτυξής τους βασίζεται σε αυτό που ο Steven Willmott αποκαλεί εύστοχα «vibes» (διαίσθηση). Αλλάζουμε λίγο το prompt, βλέπουμε αν το αποτέλεσμα φαίνεται «κάπως σωστό» και το κυκλοφορούμε. Ως τεχνίτης, αυτό με τρομάζει.

Η Αρχιτεκτονική της Αβεβαιότητας

Η θεμελιώδης πρόκληση με τα Μεγάλα Γλωσσικά Μοντέλα (LLMs) είναι η μη ντετερμινιστική φύση τους. Σε αντίθεση με το παραδοσιακό λογισμικό όπου η είσοδος Α δίνει πάντα την έξοδο Β, ένας AI agent μπορεί τη μια στιγμή να σου δώσει μια ευφυή λύση και την επόμενη ένα συνονθύλευμα παραισθήσεων. Για να περάσουμε από τα παιχνίδια στα εργαλεία, πρέπει να εφαρμόσουμε την ίδια αυστηρότητα που χρησιμοποιούμε στη γεφυροποιία ή την αεροναυπηγική.

Οι δοκιμές βάσει προδιαγραφών (Spec-driven testing) είναι το προσχέδιο για αυτή τη μετάβαση. Αντί να δοκιμάζουμε την «αίσθηση» μιας απάντησης, ορίζουμε αυστηρές προδιαγραφές για το τι πρέπει και τι δεν πρέπει να κάνει ένας agent. Αυτό περιλαμβάνει τη δημιουργία μιας σουίτας αξιολογήσεων που μετρούν την ακρίβεια, την ασφάλεια και τη λειτουργική ορθότητα σε χιλιάδες επαναλήψεις πριν εκτεθεί έστω και μια γραμμή κώδικα στον χρήστη.

Χτίζοντας τον Λαβύρινθο: Πλαίσια Προδιαγραφών

Πώς το εφαρμόζουμε αυτό; Ξεκινάμε απομακρυνόμενοι από τον χειροκίνητο έλεγχο. Δοκιμάζω αρχιτεκτονικές «LLM-as-a-Judge», όπου ένα μοντέλο υψηλών δυνατοτήτων (όπως το GPT-4o ή το Claude 3.5 Sonnet) λειτουργεί ως επόπτης για έναν μικρότερο, ταχύτερο agent. Αλλά ακόμα και ο κριτής χρειάζεται κανόνες. Μια σωστή τεχνική προδιαγραφή για έναν AI agent πρέπει να περιλαμβάνει:

  • Ντετερμινιστικούς Ελέγχους: Επαλήθευση συγκεκριμένων λέξεων-κλειδιών, σχημάτων JSON ή μορφών δεδομένων.
  • Σημασιολογική Ομοιότητα: Χρήση embeddings για να διασφαλιστεί ότι η έξοδος παραμένει εντός των εννοιολογικών ορίων της επιθυμητής απάντησης.
  • Αρνητικούς Περιορισμούς: Ρητή δοκιμή ότι ο agent δεν εκτελεί απαγορευμένες ενέργειες, όπως η διαρροή συστημικών οδηγιών.

Δείτε μια απλοποιημένη δομή δοκιμής για έναν αυτόνομο κώδικα:

{
  "test_case": "Refactor Python function",
  "input": "def add(a,b): return a+b",
  "assertions": [
    { "type": "valid_syntax", "language": "python" },
    { "type": "function_present", "name": "add" },
    { "type": "no_external_imports" }
  ]
}

Η Βάση του Υλικού: Nvidia εναντίον Cerebras

Δεν μπορούμε να μιλάμε για μηχανική αυστηρότητα χωρίς να αναφέρουμε το καμίνι όπου σφυρηλατούνται αυτά τα εργαλεία. Η μάχη μεταξύ Nvidia και Cerebras δεν αφορά μόνο την ταχύτητα, αλλά την προβλεψιμότητα του inference. Καθώς προχωράμε προς τις δοκιμές βάσει προδιαγραφών, η ζήτηση για μαζικό inference χαμηλής καθυστέρησης αυξάνεται. Αν πρόκειται να τρέχουμε 10.000 δοκιμές για κάθε μικρή αλλαγή στο prompt, η αποδοτικότητα της υποκείμενης αρχιτεκτονικής γίνεται το στενό πέρασμα της καινοτομίας.

Πρακτική Σοφία για τον Σύγχρονο Δημιουργό

Η συμβουλή μου προς τους συναδέλφους προγραμματιστές είναι απλή: σταματήστε να πετάτε προς τον ήλιο με κέρινα φτερά. Αν δεν μπορείτε να μετρήσετε την απόδοση του AI agent σας ποσοτικά, δεν έχετε χτίσει ένα σύστημα· έχετε χτίσει ένα πρωτότυπο. Υιοθετήστε τη νοοτροπία των προδιαγραφών. Αντιμετωπίστε τα prompts σας ως κώδικα, τις αξιολογήσεις σας ως unit tests και τα μοντέλα σας ως εξαρτήματα με γνωστά ποσοστά αστοχίας. Μόνο τότε θα χτίσουμε κάτι που αντέχει στον χρόνο.