Vibe Coding vs. Πραγματικό Engineering: Πού Σταματάει η Δημιουργία και Πού Αρχίζει η Μηχανική

Πριν λίγες μέρες, μια ιδρύτρια μου έδειξε μια web εφαρμογή που έφτιαξε σε ένα Σαββατοκύριακο χρησιμοποιώντας AI εργαλεία. Χωρίς πτυχίο πληροφορικής, χωρίς bootcamp, μόνο μια ξεκάθαρη ιδέα και καλά prompts. Εντυπωσιάστηκα πραγματικά. Login σύστημα, dashboard, persistence - όλα δούλευαν σε λιγότερο από 72 ώρες.

Μετά μου ζήτησε να την βοηθήσω να την παραδώσει σε πραγματικούς χρήστες.

Εκεί άρχισαν τα ενδιαφέροντα.

Το prototype δούλευε επειδή ήταν ο μόνος χρήστης. Μόλις προσπαθήσαμε να προσθέσουμε ένα δεύτερο άτομο, βγήκαν στην επιφάνεια concurrency bugs. Η βάση δεν είχε migrations, οπότε ένα rollback θα σήμαινε απώλεια δεδομένων. Δεν υπήρχαν tests, που σήμαινε ότι οποιαδήποτε αλλαγή έμοιαζε με αποναρκοθέτηση με δεμένα μάτια. Και το deployment ήταν μια χειροκίνητη διαδικασία χωρίς καμία τεκμηρίωση.

Το Σαββατοκύριακο project της ήταν ένα εξαιρετικό proof of concept. Δεν ήταν production-ready software.

Αυτό είναι το κενό που η συζήτηση περί "vibe coding" δεν πιάνει. Τα εργαλεία είναι αληθινά, η ταχύτητα είναι αληθινή, και η δημοκρατικοποίηση της δημιουργίας λογισμικού είναι πραγματικά συναρπαστική. Αλλά υπάρχει διαφορά ανάμεσα στο να παράγεις κώδικα και στο να κάνεις engineering λογισμικό. Και αυτή η διαφορά έχει μεγαλύτερη σημασία απ' ό,τι καταλαβαίνουν οι περισσότεροι - μέχρι να βρεθούν μπροστά σε ένα incident στις 3 τα ξημερώματα.

Η Μετρική που Πραγματικά Μετράει

Αυτή είναι η ερώτηση που κάνω συνέχεια όταν βλέπω AI-generated κώδικα: μπορεί αυτό να γίνει safely merged σε ένα shared codebase;

Όχι "τρέχει." Όχι "το demo δούλεψε." Safely merged. Αυτή η λέξη "safe" κουβαλάει πολύ βάρος. Σημαίνει ότι ο κώδικας μπορεί να ελεγχθεί από κάποιον που δεν τον έγραψε. Σημαίνει ότι τα tests επαληθεύουν συμπεριφορά, όχι απλά ότι ο κώδικας δεν κρασάρει. Σημαίνει ότι το rollback είναι δυνατό χωρίς απώλεια δεδομένων. Σημαίνει ότι η αλλαγή είναι αρκετά narrow ώστε να κατανοηθεί και να εξηγηθεί.

Όταν ένας vibe coder μετράει επιτυχία, συνήθως μετράει time to first working version. Αυτή είναι μια χρήσιμη μετρική για discovery και prototyping. Αλλά μόλις το software μπει σε shared environment, αυτή η μετρική παύει να είναι χρήσιμη. Τώρα μετράς time to safe merge, και αυτό περιλαμβάνει review cost, test quality, deployment risk, coordination overhead, και μελλοντικό maintenance burden.

Ένας software engineer σκέφτεται όλο αυτό τον κύκλο ζωής από την αρχή. Ένας vibe coder συχνά ανακαλύπτει αυτές τις ανησυχίες αργότερα, όταν κοστίζουν περισσότερο να τις αντιμετωπίσεις.

Code Generation vs. Code Ownership

Υπάρχει μια λεπτή αλλά κρίσιμη μετατόπιση που συμβαίνει όταν το AI γεννάει τον κώδικά σου. Η έξοδος δεν είναι ακόμα δική σου δουλειά. Είναι ένα starting point που χρειάζεται να μεταμορφωθεί σε κάτι που πραγματικά ανήκει σε σένα.

Ownership σημαίνει πολλά πράγματα. Μπορείς να εξηγήσεις κάθε σημαντική απόφαση στην αλλαγή. Καταλαβαίνεις γιατί υπάρχει κάθε αρχείο και τι κάνει. Έχεις περιορίσει την αλλαγή ακριβώς σε αυτό που χρειαζόταν, χωρίς επιπλέον boilerplate ή unrelated cleanup. Έχεις γράψει ή επαληθεύσει tests που ελέγχουν συμπεριφορά, όχι απλά coverage metrics. Έχεις σκεφτεί το rollback path.

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

Όταν κοιτάω AI-generated κώδικα που δεν έχει αναληφθεί σωστά, βλέπω συχνά τα ίδια προβλήματα. Αλλαγές που είναι πολύ μεγάλες επειδή το μοντέλο γέννησε περισσότερα απ' όσα χρειαζόταν. Packages που προστέθηκαν χωρίς ξεκάθαρη αιτιολόγηση. Tests που μοιάζουν γραμμένα για να ικανοποιήσουν ένα coverage tool παρά να πιάσουν real bugs. Boilerplate που υπάρχει επειδή το μοντέλο κάνει default σε scaffolding αντί για simplicity.

Τίποτα από αυτά δεν είναι φταίξιμο του AI. Είναι αποτέλεσμα ενός συγγραφέα που αντιμετώπισε το generated output ως progress αντί για raw material.

Το Review Problem που Κανείς δεν Συζητάει

Κάτι που με απασχολεί σοβαρά: ο AI-generated κώδικας αλλάζει την review εξίσωση.

Όταν ένας ανθρώπινος μηχανικός γράφει κώδικα, υπάρχει συνήθως ένα decision trail. Μπορεί να διαφωνείς με τις επιλογές του, αλλά τουλάχιστον υπάρχουν επιλογές. Μπορείς να ρωτήσεις γιατί χρησιμοποίησε εκείνο το abstraction, γιατί η validation βρίσκεται εκεί, γιατί διάλεξε εκείνη τη βιβλιοθήκη. Οι απαντήσεις μπορεί να είναι "δεν το σκέφτηκα" ή "φαινόταν λογικό τότε," αλλά τουλάχιστον υπάρχει άνθρωπος να ρωτήσεις.

Με AI-generated κώδικα, κάποιες από αυτές τις "αποφάσεις" δεν είναι καθόλου αποφάσεις. Είναι completions. Το μοντέλο διάλεξε ένα pattern επειδή era statistically likely, όχι επειδή ήταν η σωστή εφαρμογή για το πρόβλημά σου. Και αν ο συγγραφέας δεν έχει μετατρέψει εκείνη την completion σε owned work, το review γίνεται πολύ πιο δύσκολο πρόβλημα.

Δεν μπορείς να ρωτήσεις το μοντέλο γιατί διάλεξε αυτή την προσέγγιση. Δεν μπορείς να ρωτήσεις τον συγγραφέα γιατί έκανε εκείνη την απόφαση αν ο ίδιος δεν ξέρει στ' αλήθεια. Οπότε το review είτε φέρνει προβλήματα στην επιφάνεια μέσα από επώδυνη trial and error, είτε δεν γίνεται καθόλου.

Γι' αυτό πιστεύω ότι η πιο σημαντική δεξιότητα στην εποχή του AI-assisted development δεν είναι το prompting. Είναι η ικανότητα να παίρνεις generated output και να το μετατρέπεις σε κώδικα που κατανοείς αρκετά βαθιά ώστε να τον αναλάβεις, να τον εξηγήσεις, και να τον συντηρήσεις.

Τι Σημαίνει Αυτό για την Ομάδα Σου

Αν χτίζεις ένα prototype για να δοκιμάσεις μια ιδέα, το vibe coding είναι μια νόμιμη προσέγγιση. Η ταχύτητα μάθησης έχει σημασία όταν ακόμα validate-άρεις assumptions. Χρησιμοποίησε τα εργαλεία, κινήσου γρήγορα, και φτιάξε κάτι να δείξεις στον κόσμο.

Αλλά αν εκείνο το prototype πρόκειται να γίνει πραγματικό προϊόν, κάποια στιγμή ο generated κώδικας πρέπει να περάσει από το φίλτρο κάποιου που σκέφτεται σαν μηχανικός. Όχι για να κάνει gatekeep. Όχι για να επιβραδύνει τα πράγματα. Αλλά για να διασφαλίσει ότι αυτό που θα shipαρει είναι κώδικας που μπορεί να κατανοηθεί, να συντηρηθεί, και να τον εμπιστευτεί μια ομάδα.

Στην NameOcean βλέπουμε αυτό το pattern συνέχεια. Startups που κινούνται γρήγορα με AI εργαλεία για να validate-άρουν τις ιδέες τους, και μετά χτυπούν σε τοίχο όταν πρέπει να κλιμακωθούν. Οι καλές φέρνουν engineering help σε εκείνο το σημείο. Οι κακές συνεχίζουν να προσθέτουν features σε ένα codebase που κανείς δεν καταλαβαίνει πραγματικά.

Ο στόχος δεν είναι να αποφύγεις το AI-assisted development. Ο στόχος είναι να είσαι ειλικρινής για το πού αρχίζει η δουλειά και πού τελειώνει. Το AI μπορεί να γεννήσει κώδικα. Εσύ πρέπει να κάνεις engineering.

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

Το vibe coding είναι ένα φανταστικό starting point. Είναι ένας τρόπος να δοκιμάσεις ιδέες γρήγορα, να μάθεις τι είναι δυνατό, και να πας από concept σε κάτι tangible χωρίς μήνες παραδοσιακής ανάπτυξης.

Αλλά το software engineering αφορά τον πλήρη κύκλο ζωής. Αφορά κώδικα που η ομάδα σου μπορεί να ελέγξει, να συντηρήσει, και να εμπιστευτεί όταν κάτι πάει στραβά στις 2 το βράδυ. Αφορά αλλαγές που είναι αρκετά narrow ώστε να κατανοηθούν και να γίνουν rollback αν χρειαστεί. Αφορά το να αναλαμβάνεις ευθύνη για αποφάσεις, ακόμα και όταν αυτές οι αποφάσεις ενημερώθηκαν από AI suggestions.

Οι καλύτεροι developers που ξέρω χρησιμοποιούν AI εργαλεία εκτενώς. Απλά το κάνουν με τα μάτια ανοιχτά. Ξέρουν ότι generated code είναι raw material, όχι finished product. Και ξέρουν ότι κάποια στιγμή, κάποιος πρέπει να κάνει το engineering work που κάνει τη διαφορά ανάμεσα σε ένα cool demo και σε software που μπορείς πραγματικά να ship-άρεις.

Οπότε ναι, κάνε vibe coding. Χτίσε γρήγορα, πειραματίσου ελεύθερα, και χρησιμοποίησε κάθε εργαλείο που έχεις στη διάθεσή σου. Απλά να ξέρεις πότε είναι η ώρα να αλλάξεις από vibe σε engineering. Ο μελλοντικός σου εαυτός, και η μελλοντική σου ομάδα, θα σε ευχαριστήσουν.