Το Κρυφό Πρόβλημα του Vibe Coding

Ας είμαστε ειλικρινείς: το vibe coding είναι game-changer. Περιγράφεις τι θες, βλέπεις τον agent να το χτίζει, τους tests να γίνονται πράσινοι, και shipping. Μοιάζει με μαγεία — μέχρι να σταματήσει να είναι.

Εκείνο το "μέχρι" συνήθως εμφανίζεται στις 3 το πρωί. Η εφαρμογή ξεκινάει μια χαρά, διαχειρίζεται μερικά requests όμορφα, και μετά την σκοτώνει ένας OOM reaper. Ή ανοίγει δέκα χιλιάδες file descriptors και καταρρέει. Ή τρέχει άψογα με το δοκιμαστικό σου dataset και λιώνει όταν εμφανιστούν πραγματικοί χρήστες.

Ο κώδικας ήταν σωστός. Έλυνε ακριβώς το πρόβλημα όπως είχε οριστεί. einfach υποθέτει άπειρη μνήμη και άπειρα file handles — επειδή τίποτα στο prompt σου δεν έλεγε το αντίθετο.

Ο Σιωπηλός Δολοφόνος: Οι Ανέφικτες Παραδοχές

Αυτό είναι το πονηρό κομμάτι του vibe coding που κανείς δεν συζητάει στα conferences. Όταν γράφεις κώδικα μόνος σου, κουβαλάς νοητικά μοντέλα περιορισμών παντού. Ξέρεις ότι τρέχεις σε laptop με 16GB RAM. Ξέρεις ότι ο production server έχει όρια στα file descriptors. Ξέρεις ότι εκείνο το CSV 400GB δεν γίνεται να το φορτώσεις όλο στη μνήμη.

Αλλά όταν ένα AI γράφει τον κώδικά σου, αυτοί οι περιορισμοί δεν υπάρχουν. Το AI βλέπει "φόρτωσε το αρχείο, ταξινόμησέ το, γράψε το αποτέλεσμα" και σκέφτεται: τέλεια, θα φορτώσω όλο. Δουλεύει άψογα στα tests. Το test αρχείο είναι 50KB.

Οι code reviews δεν θα πιάσουν αυτό. Οι επίμαχες γραμμές φαίνονται απόλυτα λογικές. Τίποτα δεν χτυπάει κόκκινο όταν ψάχνεις για λογικά σφάλματα — επειδή δεν υπάρχουν. Το bug δεν είναι στη λογική· είναι στο αόρατο κουτί που η λογική σχεδιάστηκε να χωρέσει.

Τι Γίνεται αν ο Compiler Ήξερε;

Εδώ τα πράγματα γίνονται ενδιαφέροντα. Ένας developer ονόματι Nicolas Grislain πειραματίζεται με μια προκλητική ιδέα: τι αν οι περιορισμοί πόρων ήταν types, όχι comments;

Αντί να ελπίζεις ότι ο AI-generated κώδικας σέβεται τα όρια μνήμης, τι γίνεται αν ο compiler literally αρνούνταν να κάνει compile κώδικα που τα παραβίαζε; Τι γίνεται αν "αυτή η συνάρτηση δεν κρατάει ποτέ πάνω από 100 records στη μνήμη" και "αυτό το πρόγραμμα δεν έχει ποτέ πάνω από 3 ανοιχτά αρχεία ταυτόχρονα" ήταν facts που ο compiler επαλήθευε, όχι prayers που ψιθυρίζεις στο code review;

Δεν είναι απλά θεωρητικό χάσιμο χρόνου. Το πείραμα χρησιμοποιεί Lean 4 — ναι, αυτό το Lean που κάνει θραύση στα μαθηματικά — για να κωδικοποιήσει resource budgets απευθείας στα function types. Ο compiler γίνεται resource auditor, ελέγχοντας αυτόματα ότι ο κώδικάς σου μένει εντός ορίων πριν καν τρέξει.

Κάνοντας τους Πόρους να Μετράνε

Το core trick είναι εκπληκτικά κομψό: περνάς resource counts μέσα από το type system. Αντί να παρακολουθείς "πόσα αρχεία είναι ανοιχτά" ως runtime variable που μπορεί να αγνοηθεί, το type system το παρακολουθεί ως phantom parameter που πρέπει να ισοφαριστεί.

Όταν ανοίγεις ένα αρχείο, το type signature αντικατοπτρίζει την αλλαγή: μπαίνεις στη συνάρτηση με N αρχεία ανοιχτά και βγαίνεις με N+1. Όταν το κλείνεις, πας από N+1 πίσω στο N. Ο compiler παρακολουθεί αυτό σε κάθε βήμα, και literally δεν μπορείς να κάνεις compile κώδικα που ανοίγει αρχείο χωρίς να το κλείσει, ή που ανοίγει αρχεία πάνω από ένα cap.

Η μνήμη δουλεύει παρόμοια, αλλά με twist. Τα records δεν επιπλέουν ελεύθερα στη μνήμη — ζουν σε ένα bounded pool με συγκεκριμένο αριθμό slots. Δεν κρατάς ένα Event object· κρατάς μια αναφορά σε εκείνο το pool. Το type παρακολουθεί πόσες live references υπάρχουν σε κάθε στιγμή, και η allocation απαιτεί proof ότι υπάρχει χώρος.

Η μαγεία συμβαίνει στο entry point: το πρόγραμμα πρέπει να ξεκινάει με μηδέν resources σε χρήση και να τελειώνει με μηδέν. Δεν μπορείς να κάνεις leak handles ή refs. Δεν μπορείς να ξεπεράσεις caps. Ο compiler simply δεν σε αφήνει.

Γιατί Έχει Σημασία για το Vibe Coding

Αυτή η προσέγγιση μεταμορφώνει το πώς σκεφτόμαστε τα prompts σε AI assistants. Σήμερα, μπορεί να προσθέσεις ένα note όπως "πρόσεξε με τη χρήση μνήμης" ή "κλείσε όλα τα file handles" — ελπίζοντας ότι το AI δίνει σημασία. Με resource-aware types, ορίζεις τους περιορισμούς formally, και η υλοποίηση πρέπει να αναδιοργανωθεί για να τους ικανοποιήσει.

Το AI παίρνει πρώτα την unconstrained version. Τα tests περνάνε. Μετά ενεργοποιείς τα limits. Ο compiler απορρίπτει αμέσως την υλοποίηση. Το AI πρέπει να αναδομήσει την προσέγγισή του — ίσως να επεξεργάζεται το αρχείο σε chunks αντί να το φορτώνει όλο μονομιάς, ή να χρησιμοποιεί connection pool αντί να ανοίγει αρχεία απευθείας.

Η υλοποίηση δεν einfach τυχαίνει να δουλεύει· provably δουλεύει εντός budget.

Η Πρακτική Πραγματικότητα

Ας είμαστε ξεκάθαροι: αυτό δεν είναι ακόμα production-ready tooling για τις περισσότερες ομάδες. Η Lean 4 προσέγγιση απαιτεί σημαντικό setup, και υπάρχει overhead στο να σκέφτεσαι με όρους indexed types. Αλλά η υποκείμενη ιδέα έχει αξία ανεξάρτητα από την υλοποίηση.

Όταν κάνεις vibe coding, κάνεις outsource όχι μόνο το γράψιμο του κώδικα αλλά και το mental model του συστήματός σου. Ο AI assistant σου δεν ξέρει το production environment σου. Δεν ξέρει ότι το container σου έχει 512MB RAM. Δεν ξέρει ότι το Linux kernel σου capάρει τα file descriptors στα 1024.

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

1. Να είσαι explicit στα prompts — "Το input αρχείο μπορεί να περιέχει μέχρι 10 εκατομμύρια rows" είναι καλύτερο από "χειρίσου τα μεγάλα αρχεία efficiently"

2. Κάνε test με production-scale δεδομένα — Αν το training data σου είναι μικρό, το AI σου δεν θα μάθει resource patterns

3. Χρησιμοποίησε bounded APIs — Architecture που naturally περιορίζει τη χρήση πόρων (connection pools, streaming αντί για loading) είναι πιο δύσκολο να τα χρησιμοποιήσεις λάθος

4. Πρόσεξε το resource-aware tooling — Η βιομηχανία αρχίζει να εξερευνά τρόπους να κάνει τους περιορισμούς explicit στον AI-generated κώδικα

Το Συμπέρασμα

Το dirty secret του vibe coding δεν είναι ότι γράφει buggy κώδικα — είναι ότι γράφει κώδικα που είναι correct εντός ενός invisible constraint space. Εκείνος ο χώρος περιλαμβάνει το laptop σου, το test environment σου, και ίσως τους πρώτους χιλίους χρήστες σου. Σίγουρα δεν περιλαμβάνει "production at scale."

Resource-aware type systems όπως αυτό το Lean 4 experiment δείχνουν προς ένα μέλλον όπου το "correct" σημαίνει περισσότερα από "logically right." Σημαίνει "proven να μένει εντός των bounds που actually υπάρχουν."

Αυτό είναι ένα μέλλον που αξίζει να δουλέψουμε προς αυτό. Μέχρι τότε, κράτα τα test δεδομένα σου κοντά στο production size, και ίσως πρόσθεσε ένα extra note στα prompts σου για εκείνα τα file descriptor limits.

Ο μελλοντικός σου εαυτός on-call θα σε ευχαριστήσει.