Ο Luca Mezzalira σχολιάζει τη συζήτηση των Neal Ford και Sam Newman για τα agentic AI στη software architecture. Το βασικό πρόβλημα είναι ότι οι agents εκτελούν εντολές χωρίς να καταλαβαίνουν ποια λύση είναι σωστή.
Στη συζήτηση των Neal Ford και Sam Newman στο O’Reilly Software Architecture Superstream, το θέμα δεν ήταν τι μπορούν να φτιάξουν οι πράκτορες τεχνητής νοημοσύνης, αλλά τι σημαίνει αυτό για τον σχεδιασμό συστημάτων. Με βάση το μοντέλο Dreyfus, ο Ford τοποθετεί τα σημερινά agentic AI κάπου ανάμεσα στον αρχάριο και τον προχωρημένο αρχάριο: μπορούν να ακολουθούν συνταγές, όχι όμως να καταλαβαίνουν γιατί δουλεύουν. Ένα failing test μπορεί να «λυθεί» με ένα απλό assert True, ή μια αποτυχημένη διεργασία να κρυφτεί αντί να διορθωθεί. Το αποτέλεσμα είναι επιτυχία στο αποτέλεσμα, όχι στην πρόθεση.
Από εκεί προκύπτει η διάκριση ανάμεσα σε behavioral και capability verification. Το πρώτο ελέγχει αν ο κώδικας κάνει αυτό που ορίζει το spec, κάτι που οι agents χειρίζονται ήδη αρκετά καλά. Το δεύτερο εξετάζει αν το σύστημα αντέχει στην πράξη: αν κλιμακώνεται, αν είναι ασφαλές, αν μένει αποσυνδεδεμένο σωστά, αν αντέχει υψηλό φορτίο. Εκεί το χάσμα είναι μεγαλύτερο, ειδικά σε enterprise περιβάλλοντα όπου οι απαιτήσεις είναι ασαφείς, η γνώση είναι άτυπη και τα test suites συχνά δεν καλύπτουν το πραγματικό σύστημα. Η ιδέα να φορτώνεις όλο και περισσότερο context σε έναν agent δεν λύνει το πρόβλημα· σε αρκετές περιπτώσεις το χειροτερεύει. Γι’ αυτό η ανάγκη μετατοπίζεται σε deterministic guardrails και architectural fitness functions, δηλαδή σε κανόνες που ελέγχουν το σύστημα και όχι μόνο το παραγόμενο code.
Το ίδιο πρόβλημα εμφανίζεται και στο επίπεδο της αρχιτεκτονικής. Τα microservices μοιάζουν φυσικό πεδίο για agentic ανάπτυξη, επειδή έχουν σαφή όρια, API και ξεχωριστές ευθύνες. Στην πράξη όμως οι agents μαθαίνουν από ένα corpus ανθρώπινου κώδικα, όπου τα περισσότερα microservices δεν είναι πραγματικά απομονωμένα ούτε σωστά σχεδιασμένα για αντοχή και κλιμάκωση. Ακόμη κι αν ένα service φαίνεται σωστά δομημένο, η πραγματική δυσκολία συχνά μεταφέρεται στο transactional coupling, στα sagas, στη choreography των events και στη λογική αποζημίωσης όταν κάτι αποτύχει. Εκεί η πολυπλοκότητα δεν εξαφανίζεται, απλώς μετακινείται.
Η συζήτηση δεν σταματά στον κώδικα. Η παραγωγή ενός σωστά δομημένου συστήματος δεν σημαίνει ότι ο οργανισμός που θα το διαχειριστεί είναι έτοιμος να το σηκώσει. Η σταδιακή μετάβαση, όπως το incremental strangler approach, δεν μειώνει μόνο τον κίνδυνο· χτίζει και γνώση μέσα στην ομάδα. Όταν η μετάβαση γίνεται πολύ γρήγορα, η τεχνική πολυπλοκότητα μπορεί να ξεπεράσει την επιχειρησιακή ικανότητα. Αυτό είναι ακόμη πιο κρίσιμο στα παλιά συστήματα που στηρίζουν χρηματοοικονομικές υπηρεσίες, υγεία και logistics. Η ύπαρξη ενός MCP server ή ενός νέου wrapper δεν αλλάζει το γεγονός ότι το interface δεν είναι η αρχιτεκτονική, ούτε εξαφανίζει τα ρίσκα ασφάλειας, δεδομένων και εξάρτησης από προμηθευτές.
