Το παγόβουνο του AI πρωτοτύπου: έτοιμο για παραγωγή;

Ένα prompt γίνεται οθόνη. Άλλα δύο τρία γίνονται ροή εργασίας. Μέχρι το τέλος του απογεύματος η εφαρμογή πατιέται, επιδεικνύεται, και κάποιος το λέει: το λογισμικό είναι σχεδόν έτοιμο.

Αυτό που υπάρχει είναι ένα πρωτότυπο. Δεν είναι κριτική — τα πρωτότυπα επικυρώνουν ιδέες και κοστίζουν ένα κλάσμα του παλιού κόστους. Το πρόβλημα ξεκινά όταν το demo μπερδεύεται με το σύστημα. Το AI άλλαξε το πόσο γρήγορα υλοποιείται ένα σύστημα. Δεν κατάργησε τη μηχανική που πρέπει να κάθεται από κάτω.

Το demo είναι το πρώτο από πέντε βήματα

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

Για ένα τοπικό εργαλείο που λύνει το πρόβλημα ενός ανθρώπου, αυτό αρκεί. Από τη στιγμή που το λογισμικό γίνεται υπηρεσία — λογαριασμοί πελατών, προσωπικά δεδομένα, πληρωμές, επιχειρησιακές διαδικασίες — το «δουλεύει;» παύει να είναι το ερώτημα. Δουλεύει υπό φόρτο, αποτυγχάνει ελεγχόμενα, ανακάμπτει από απώλεια δεδομένων, φτάνει ο κάθε χρήστης μόνο στα δικά του δεδομένα, γυρίζει πίσω μια ελαττωματική έκδοση, και ποιος έχει την ευθύνη όταν σπάσει. Το demo δεν απαντά σε κανένα από αυτά.

1. Εύρος: το πρωτότυπο χτίζει μόνο την ιδανική διαδρομή

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

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

Αυτό που παράγει η φάση είναι ένα γραπτό εύρος με όριο γύρω του. Το παραδίδουμε στο πρώτο milestone, πριν γραφτεί γραμμή παραγωγικού κώδικα, επειδή ένα κείμενο είναι το φθηνότερο παραδοτέο για να διαφωνήσει κανείς μαζί του.

2. Αρχιτεκτονική: ο κανόνας πρόσβασης ανήκει στη βάση

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

Το CVE-2025-48757, που δημοσιεύτηκε στις 29 Μαΐου 2025 με βαθμολογία CVSS 9,3, περιγράφει «ανεπαρκή πολιτική Row-Level Security στο Lovable έως τις 2025-04-15» που «επιτρέπει σε απομακρυσμένους, μη πιστοποιημένους επιτιθέμενους να διαβάσουν ή να γράψουν σε αυθαίρετους πίνακες βάσης δεδομένων των παραγόμενων ιστότοπων». Ο ερευνητής που το ανέφερε βρήκε 303 εκτεθειμένα endpoints σε 170 παραγόμενα έργα — διευθύνσεις email, τηλέφωνα, στοιχεία πληρωμών, κλειδιά API.

Στις codebases που έχουν φτιαχτεί με AI και αξιολογούμε, αυτό είναι το πρώτο που κοιτάμε, και η αστοχία έχει πάντα την ίδια μορφή: η εξουσιοδότηση υπάρχει στη διεπαφή και πουθενά αλλού. Το κουμπί είναι κρυμμένο, η διαδρομή προστατεύεται, το ερώτημα στο frontend φιλτράρει με το user id — και ο πίνακας από κάτω απαντά σε όποιον τον ρωτήσει απευθείας.

Η κρυπτογράφηση ανήκει στην ίδια απόφαση, όχι σε μεταγενέστερη φάση θωράκισης. Αν ψάξατε για Supabase field encryption περιμένοντας έναν διακόπτη ανά στήλη, δεν υπάρχει πια: το Transparent Column Encryption που βασιζόταν στο pgsodium δεν συνιστάται πλέον, αφαιρέθηκε από τον table editor του dashboard και οδεύει προς κατάργηση. Το Vault παραμένει, αλλά το Vault αφορά μυστικά — κλειδιά API, tokens για webhooks — όχι τις στήλες των χρηστών σας. Η κρυπτογράφηση σε επίπεδο πεδίου είναι επομένως απόφαση της εφαρμογής, και οι κρυπτογραφημένες στήλες χάνουν το κανονικό ερώτημα: ούτε LIKE, ούτε ευρετήριο, ούτε ταξινόμηση. Φθηνό αν σχεδιαστεί από την αρχή, οδυνηρό αν μπει εκ των υστέρων.

3. Υλοποίηση: ο κώδικας έρχεται γρήγορα, δύο πράγματα λείπουν

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

Γρήγορο δεν σημαίνει σωστό. Δύο παραλείψεις εμφανίζονται σχεδόν σε κάθε codebase που αξιολογούμε αργότερα:

• Καμία αυτοματοποιημένη δοκιμή. Το «χάλασε κάτι αυτό;» απαντιέται στην παραγωγή, και κάθε αλλαγή γίνεται στοίχημα που ο ιδρυτής κάποια στιγμή σταματά να παίζει.
• Μυστικά στο repository ή στο client bundle. Ένα κλειδί service_role σε ένα frontend build παρακάμπτει εξ ορισμού κάθε κανόνα πρόσβασης από πάνω του.

Αντιμετωπίζουμε την ανάπτυξη με AI ως υλοποίηση με μηχανικό στο τιμόνι: οι senior μηχανικοί ορίζουν το σύστημα, καθοδηγούν την υλοποίηση, ελέγχουν το αποτέλεσμα και παραμένουν υπεύθυνοι για αυτό. Το μοντέλο γράφει το μεγαλύτερο μέρος του κώδικα. Δεν φέρει καμία ευθύνη.

4. Λειτουργία: το deployment είναι η αρχή της δουλειάς

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

Τα όρια του hosting είναι μέρος αυτού. Το δωρεάν πλάνο της Supabase δίνει 500 MB βάσης, 1 GB αποθήκευσης αρχείων, 5 GB εξερχόμενης κίνησης και 50.000 μηνιαίους ενεργούς χρήστες σε δύο ενεργά έργα — και παγώνει ένα έργο μετά από μία εβδομάδα αδράνειας· το Pro ξεκινά στα 25 δολάρια τον μήνα με 8 GB δίσκου, μετά 0,125 δολάρια ανά GB. Διαβάστε τον κανόνα του παγώματος για αυτό που λέει: το δωρεάν πλάνο είναι πλάνο πρωτοτύπου. Ένα παγωμένο έργο είναι διακοπή λειτουργίας, και ο πρώτος που θα το προσέξει θα είναι πελάτης. Το ένα gigabyte αρχείων είναι μερικές εκατοντάδες φωτογραφίες κινητού.

Τα αντίγραφα δεν είναι ανάκτηση. Ένα αντίγραφο που δεν επαναφέρθηκε ποτέ είναι μια υπόθεση, και η στιγμή που το χρειάζεσαι είναι κακή στιγμή για να τη δοκιμάσεις. Κάντε τη δοκιμή πριν τη χρειαστείτε: επαναφέρετε ένα αντίγραφο σε ένα άδειο έργο, κρατήστε χρόνο και δείτε τι λείπει. Αυτός ο αριθμός είναι η πραγματική σας θέση ανάκτησης.

Η ίδια πειθαρχία ισχύει για τις αλλαγές. Στα έργα που έχουν φτιαχτεί με AI βρίσκουμε το αντίθετο — αλλαγές σχήματος κατευθείαν στην παραγωγή μέσα από ένα chat prompt, κανένα αναστρέψιμο migration, και η ανάπτυξη με την παραγωγή να αποκλίνουν σιωπηλά μέχρι να μην μπορεί κανείς να πει ποια από τις δύο είναι η σωστή.

Οι περισσότερες πλατφόρμες χρειάζονται επίσης εσωτερικά εργαλεία που κανένας πελάτης δεν βλέπει: έλεγχος λογαριασμού, αναστολή καταχρηστικού χρήστη, επανεκτέλεση αποτυχημένης εργασίας, ανάγνωση audit log. Χωρίς αυτά, κάθε περιστατικό καταλήγει σε χειροκίνητη επέμβαση στη βάση — αργή, επικίνδυνη και αδύνατη να ελεγχθεί εκ των υστέρων.

Πόσα από αυτά χρειάζεστε πραγματικά;

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

Πάρτε μια πληρωμή. Δεν αρκεί να φαίνεται επιτυχής στην οθόνη. Τι γίνεται όταν η πληρωμή περνά αλλά το αίτημα επιβεβαίωσης λήγει σε timeout; Όταν ο χρήστης πατήσει δύο φορές; Όταν ο πάροχος στείλει το ίδιο webhook δύο φορές; Οι επαναλήψεις, η ιδιομορφία (idempotency) και η συμφωνία των εγγραφών είναι ζητήματα μηχανικής παραγωγής, και καμία επιμέλεια στη διεπαφή δεν τα λύνει.

Στα ιατρικά και στα κρίσιμα για την ασφάλεια συστήματα ο πήχης ανεβαίνει κι άλλο. Το «το παρήγαγε επιτυχώς το AI» δεν είναι μοντέλο διασφάλισης.

Το AI δεν είναι το πρόβλημα

Τα εργαλεία είναι καλά και είναι ειλικρινή ως προς αυτό. Το Lovable παράγει React frontend, λογικό σχήμα σε Supabase, λειτουργική σύνδεση και ζωντανό deployment γρηγορότερα από κάθε ανθρώπινη ομάδα, και ο κώδικας είναι αρκετά ευανάγνωστος ώστε να τον παραλάβουν μηχανικοί. Αυτό που δεν μπορεί να κάνει είναι να αναλάβει το όριο ανάμεσα στο «δουλεύει όταν το χρησιμοποιώ εγώ» και στο «είναι ασφαλές όταν το χρησιμοποιεί ένας άγνωστος». Η απάντησή του στο παραπάνω CVE ήταν ένας σαρωτής ασφαλείας στην έκδοση 2.0, που δείχνει αν υπάρχει Row-Level Security και όχι αν είναι σωστή — μια ενεργοποιημένη πολιτική που δεν ταιριάζει ποτέ περνά τον έλεγχο. Το Lovable αμφισβητεί επίσης το CVE, με το σκεπτικό ότι οι πελάτες είναι υπεύθυνοι να προστατεύουν τα δεδομένα της εφαρμογής τους. Αξίζει δεύτερη ανάγνωση, γιατί περιγράφει με ακρίβεια πού βρίσκεται η ευθύνη.

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

Αν έχετε ήδη το πρωτότυπο και θέλετε μια ειλικρινή απάντηση για τα υπόλοιπα, η αξιολόγηση vibe-code rescue είναι δωρεάν και καταλήγει σε γραπτή ετυμηγορία που μπορείτε να αμφισβητήσετε.