Η ΤΝ δεν μειώνει την ανάγκη κατανόησης. Την αυξάνει

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

Στον παραδοσιακό προγραμματισμό υπάρχει ένα φυσικό όριο ασφαλείας. Αν ένας προγραμματιστής δεν κατανοεί τον κώδικα, δύσκολα μπορεί να τον αλλάξει με ουσιαστικό τρόπο. Θα κολλήσει, θα χρειαστεί να διαβάσει την αρχιτεκτονική, να τρέξει δοκιμές, να ρωτήσει συναδέλφους, να ξαναχτίσει στο μυαλό του το μοντέλο του συστήματος. Η ίδια η δυσκολία της εργασίας τον αναγκάζει να καταλάβει πριν παρέμβει. Με την ΤΝ αυτό το όριο χαλαρώνει. Ένας βοηθός μπορεί να παραγάγει μια αλλαγή που περνά τις αυτόματες δοκιμές, φαίνεται καθαρή, χρησιμοποιεί σωστά ονόματα μεταβλητών και ακολουθεί το ύφος του έργου. Ο άνθρωπος τότε δεν κρίνει μόνο τον κώδικα. Κρίνει και την ίδια του την κατανόηση για τον κώδικα.

Εδώ μπαίνει η ικανότητα να ξέρουμε τι ξέρουμε και τι δεν ξέρουμε. Στην ανασκόπηση κώδικα δεν αρκεί να διαβάζουμε μια αλλαγή. Πρέπει να μπορούμε να απαντήσουμε: καταλαβαίνω πραγματικά τη ροή δεδομένων; Καταλαβαίνω τις συνέπειες για την ασφάλεια; Έχω ελέγξει τις οριακές περιπτώσεις; Ξέρω τι δε δοκιμάστηκε; Μπορώ να εξηγήσω γιατί αυτή η λύση είναι σωστή και όχι απλώς γιατί φαίνεται καλογραμμένη;

Οι γνωστικές παγίδες του AI-assisted coding

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

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

Η τρίτη παγίδα είναι η προκατάληψη υπέρ του αυτοματισμού. Όταν ένα εργαλείο παράγει απάντηση με αυτοπεποίθηση, οι άνθρωποι τείνουν να μειώνουν τη δική τους προσπάθεια επαλήθευσης. Στον προγραμματισμό αυτό σημαίνει ότι ο αναγνώστης ενός αιτήματος αλλαγής μπορεί να κοιτάξει την επιτυχία των δοκιμών, το καθαρό ύφος και τη φαινομενική συνέπεια του κώδικα και να πατήσει «έγκριση» χωρίς να έχει ελέγξει την πραγματική συμπεριφορά.

Συγκεκριμένα παραδείγματα κινδύνου

Σε μια εφαρμογή ηλεκτρονικών υπηρεσιών, η ΤΝ μπορεί να προτείνει έναν νέο μηχανισμό προσωρινής αποθήκευσης για να επιταχύνει τα αιτήματα. Ο κώδικας περνά τις δοκιμές απόδοσης, αλλά αποθηκεύει απαντήσεις χωρίς να λαμβάνει υπόψη τον ρόλο του χρήστη. Το αποτέλεσμα μπορεί να είναι διαρροή προσωπικών δεδομένων από έναν χρήστη σε άλλον.

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

Σε μια δημόσια εφαρμογή αιτήσεων, η ΤΝ μπορεί να δημιουργήσει δοκιμές που ελέγχουν αυτό που κάνει ο κώδικας και όχι αυτό που απαιτεί η προδιαγραφή. Έτσι οι δοκιμές δεν λειτουργούν ως ανεξάρτητος έλεγχος. Λειτουργούν ως επιβεβαίωση της ίδιας λανθασμένης υπόθεσης.

Καλές πρακτικές για ασφαλή χρήση

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

Δεύτερον, οι αλλαγές πρέπει να είναι μικρές. Όσο μεγαλύτερο είναι το αίτημα αλλαγής, τόσο δυσκολότερη η ανασκόπηση. Καλύτερα δέκα μικρές αλλαγές με σαφή σκοπό παρά ένα μεγάλο πακέτο που τροποποιεί αρχιτεκτονική, δοκιμές, εξαρτήσεις και τεκμηρίωση ταυτόχρονα.

Τρίτον, η ομάδα πρέπει να απαιτεί εξήγηση πριν από την έγκριση. Κάθε AI-assisted αλλαγή πρέπει να συνοδεύεται από σύντομη τεκμηρίωση: ποιο πρόβλημα λύνει, ποιες παραδοχές κάνει, ποια αρχεία επηρεάζει, ποιες οριακές περιπτώσεις ελέγχθηκαν, ποιοι κίνδυνοι παραμένουν.

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

Πέμπτον, δεν πρέπει να δίνονται στην ΤΝ μυστικά, κλειδιά, προσωπικά δεδομένα ή μη δημοσιευμένος κώδικας χωρίς σαφές νομικό και τεχνικό πλαίσιο. Σε ευαίσθητα έργα, ειδικά στον δημόσιο τομέα, η χρήση τοπικών, ελεγχόμενων και κατά προτίμηση ανοιχτών μοντέλων μειώνει τον κίνδυνο διαρροής και ενισχύει τη δυνατότητα ελέγχου.

Τέλος, η χρήση ΤΝ πρέπει να καταγράφεται. Όχι, για να τιμωρείται ο προγραμματιστής, αλλά για να υπάρχει ιχνηλασιμότητα. Ποιο εργαλείο χρησιμοποιήθηκε; Σε ποιο σημείο; Για ποια αλλαγή; Με ποια ανθρώπινη ανασκόπηση; Το παράδειγμα των μεγάλων έργων ανοιχτού κώδικα είναι καθαρό: η ΤΝ μπορεί να βοηθά, αλλά ο άνθρωπος υπογράφει.

Η ΤΝ μπορεί να αυξήσει την παραγωγικότητα των ομάδων λογισμικού. Μπορεί να βοηθήσει στην κατανόηση παλιού κώδικα, στη δημιουργία δοκιμών, στον εντοπισμό επαναλήψεων και στη συγγραφή τεκμηρίωσης. Αλλά δεν αντικαθιστά την κρίση. Όσο πιο πειστικός γίνεται ο παραγόμενος κώδικας, τόσο πιο αυστηρή πρέπει να γίνεται η ανασκόπηση. Η ασφαλής χρήση της ΤΝ στον προγραμματισμό δεν είναι θέμα ταχύτητας. Είναι θέμα πειθαρχίας, διαφάνειας και ευθύνης.

Πηγές άρθρου:

Diomidis Spinellis, “Why reviewing AI-generated code is devilishly hard”: Το άρθρο τεκμηριώνει γιατί ο κώδικας που παράγεται από ΤΝ απαιτεί αυξημένη προσοχή, συνδέοντας το πρόβλημα με την ψευδαίσθηση κατανόησης, την υπερβολική αυτοπεποίθηση και την προκατάληψη υπέρ του αυτοματισμού: https://www.spinellis.gr/blog/20260523/index.html,

NIST, “Secure Software Development Framework, SP 800-218”: Το πλαίσιο του NIST συγκεντρώνει θεμελιώδεις πρακτικές ασφαλούς ανάπτυξης λογισμικού και είναι χρήσιμο ως βάση για διαδικασίες ελέγχου, επαλήθευσης και ασφαλούς ενσωμάτωσης κώδικα, ανεξάρτητα από το αν ο κώδικας γράφτηκε από άνθρωπο ή με υποβοήθηση ΤΝ: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf,

OWASP, “Top 10 for Large Language Model Applications 2025”: Η OWASP καταγράφει κρίσιμους κινδύνους για εφαρμογές που βασίζονται σε μεγάλα γλωσσικά μοντέλα, όπως prompt injection, insecure output handling και supply-chain vulnerabilities, που πρέπει να λαμβάνονται υπόψη και στα εργαλεία προγραμματισμού με ΤΝ: https://owasp.org/www-project-top-10-for-large-language-model-applications/,

GitHub Docs, “Responsible use of GitHub Copilot Chat in GitHub”: Η τεκμηρίωση της GitHub επισημαίνει ότι οι χρήστες πρέπει να είναι ιδιαίτερα προσεκτικοί όταν χρησιμοποιούν το Copilot Chat για παραγωγή κώδικα σε εφαρμογές με απαιτήσεις ασφάλειας και να ελέγχουν και να δοκιμάζουν διεξοδικά τον παραγόμενο κώδικα: https://docs.github.com/en/copilot/responsible-use/chat-in-github,

Pearce, Ahmad, Tan, Dolan-Gavitt, Karri, “Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions”: Η εμπειρική μελέτη εξετάζει περιπτώσεις όπου το GitHub Copilot μπορεί να προτείνει μη ασφαλή κώδικα σε σενάρια υψηλού κινδύνου, ενισχύοντας την ανάγκη για ανεξάρτητο έλεγχο ασφαλείας: https://arxiv.org/abs/2108.09293,

Linux Kernel Documentation, “AI Coding Assistants”: Οι οδηγίες του Linux kernel διατυπώνουν μια ώριμη αρχή διακυβέρνησης: τα εργαλεία ΤΝ μπορούν να βοηθούν, αλλά μόνο άνθρωποι μπορούν να αναλάβουν την ευθύνη, να ελέγξουν τον κώδικα, να διασφαλίσουν τη συμμόρφωση με τις άδειες και να υπογράψουν τη συνεισφορά: https://docs.kernel.org/process/coding-assistants.html .