Έφτιαξα ένα προϊόν με AI—πώς να κάνετε βελτιώσεις χωρίς να χαλάσετε ό,τι λειτουργεί

Μάθετε περισσότερα για την εργασία με μοντέλα στην τεκμηρίωση του Ailoot.

Γιατί αρχίζουν οι πιο δαπανηρές εργασίες μετά την κυκλοφορία;#

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

Και εδώ προκύπτει το βασικό ερώτημα: τι κάνεις μετά την κυκλοφορία ενός προϊόντος, όταν έχει περάσει ο ενθουσιασμός του πρώτου λειτουργικού πρωτοτύπου και πρέπει με κάποιον τρόπο να το συντηρήσεις; Θα μπορούσες να το πεις vibe coding για ενηλίκους. Η δημιουργία είναι ενθουσιασμός και ταχύτητα. Η συντήρηση απαιτεί ψυχραιμία: καταλαβαίνεις τι αλλάζεις και το διατηρείς υπό έλεγχο. Οι περισσότεροι αποτυγχάνουν σε αυτό το δεύτερο μέρος, επειδή κανείς δεν τους προετοιμάζει γι’ αυτό.

Μια μελέτη του κλάδου ανέλυσε πάνω από ένα εκατομμύριο αλλαγές κώδικα από 2.444 ομάδες και υπολόγισε πού πηγαίνουν στην πραγματικότητα τα χρήματα που δαπανώνται για ανάπτυξη με AI. Αυτή είναι η εικόνα:

Ο οδηγός «Το κρυφό κόστος του vibe coding» εξηγεί αυτά τα στοιχεία λεπτομερέστερα. Εκεί, το ερώτημα ήταν για τι πληρώνετε. Εδώ το ερώτημα είναι διαφορετικό: 44 σεντ από κάθε δολάριο πηγαίνουν στη διόρθωση σφαλμάτων—και ολόκληρο αυτό το άρθρο αφορά το πώς θα εμποδίσετε αυτό το μερίδιο να αυξηθεί. Η εργασία για να το κρατήσετε υπό έλεγχο λέγεται συντήρηση.

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

Τι χαλάει στην πράξη: 5 καταστροφές μετά την κυκλοφορία#

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

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

Το πρόβλημα δεν είναι ότι ο κώδικας δεν γράφεται με το χέρι—πολλοί εργάζονται έτσι. Το πρόβλημα είναι ότι δεν τίθεται η ερώτηση: «Είναι ασφαλής η βάση δεδομένων;» Στη συνέχεια θα σας δείξω μια προτροπή που θέτει αυτό το ερώτημα για εσάς.

Το πρώτο δίχτυ ασφαλείας είναι το git και η επαναφορά στο «όπως ήταν χθες»#

Όταν ο Claude χαλάει κάτι, χρειάζεστε ένα κουμπί «επανάφερέ το όπως ήταν χθες». Τεχνικά, αυτό το κουμπί λέγεται git και είναι πιο απλό απ’ όσο ακούγεται.

Τρεις όροι που χρειάζεται να καταλάβει κάποιος που δεν είναι προγραμματιστής:

1. Αποθετήριο — ο φάκελος του έργου σας αποθηκευμένος στο cloud (συνήθως στο GitHub). Ένα αντίγραφο όλου του κώδικά σας, που δεν βρίσκεται μόνο στον υπολογιστή σας.
2. Commit — ένα σημείο επαναφοράς. Στην ουσία λέτε στον κώδικα: «αποθήκευσε σε αυτήν την κατάσταση». Κάθε commit είναι ένα σημάδι στο οποίο μπορείτε να επιστρέψετε.
3. Deploy — μια μεταφορά. Ο κώδικας ήταν τοπικός, στον υπολογιστή σας, και λειτουργούσε μόνο για εσάς. Το deploy τον στέλνει σε έναν εξωτερικό διακομιστή, ώστε να λειτουργεί για όλους.

Όσο έχετε πρόσφατα σημεία commit, μπορείτε να επαναφέρετε οποιαδήποτε ζημιά με μία πρόταση. Κυριολεκτικά.

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

Δύο κανόνες που πρέπει να εφαρμόσετε αμέσως, πριν δουν το προϊόν άλλοι:

• Το αποθετήριο πρέπει να είναι ιδιωτικό. Όχι δημόσιο. Διαφορετικά, οποιοσδήποτε μπορεί να διαβάσει τον κώδικά σας και όλα όσα περιέχει.
• Βάλτε το αρχείο μυστικών στη λίστα αγνόησης. Τα κλειδιά, οι κωδικοί πρόσβασης και τα διαπιστευτήρια πρόσβασης στη βάση δεδομένων βρίσκονται σε ξεχωριστό αρχείο (συνήθως .env), το οποίο δεν μπαίνει ποτέ στο αποθετήριο. Προσθέστε μια γραμμή για το .env στο .gitignore και τα μυστικά παραμένουν δικά σας.

Υπάρχει ξεχωριστός οδηγός για την ασφαλή επαναφορά αλλαγών στο Claude Code: Πώς να επαναφέρετε αλλαγές στο Claude Code. Χωρίς σημεία επαναφοράς, περπατάτε σε τεντωμένο σχοινί χωρίς δίχτυ ασφαλείας και αργά ή γρήγορα θα πέσετε.

Τι επαναφέρει το /rewind και τι δεν επαναφέρει;#

Το Claude Code δημιουργεί ένα στιγμιότυπο της κατάστασης πριν από κάθε αλλαγή που κάνει. Η εντολή /rewind (ή δύο πατήματα του Esc) επαναφέρει τόσο τα αρχεία όσο και τη συνομιλία σε ένα επιλεγμένο σημείο. Είναι χρήσιμη: αν χαλάσατε μια λειτουργία πριν από πέντε λεπτά, μπορείτε να γυρίσετε πέντε λεπτά πίσω.

Υπάρχει όμως μια παγίδα που κάνει τους αρχάριους να χάνουν δεδομένα. Το /rewind δεν επαναφέρει τα πάντα:

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

Το πρακτικό συμπέρασμα για κάποιον που δεν είναι προγραμματιστής: το /rewind θα σας σώσει από το «ο Claude μόλις χάλασε μια λειτουργία». Αν όμως κατάφερε να διαγράψει μια γραμμή της βάσης δεδομένων ή να ανεβάσει κώδικα στο cloud, μόνο το git και ένα αντίγραφο ασφαλείας της βάσης δεδομένων μπορούν να τα επαναφέρουν. Γι’ αυτό κρατήστε και τα δύο επίπεδα: στιγμιότυπα για γρήγορες επαναφορές, commits για το μόνιμο ιστορικό του έργου.

Πώς κάνετε βελτιώσεις χωρίς να χαλάσετε ό,τι ήδη λειτουργεί;#

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

Ο κύκλος συμβαίνει επειδή το vibe coding είναι μη ντετερμινιστικό. Η ίδια προτροπή δίνει διαφορετικό κώδικα δύο φορές. Έτσι, κάθε επεξεργασία μπορεί να μετατοπίσει αθόρυβα τη γύρω λογική: το όριο έκπτωσης αλλάζει από 10 σε 12 τοις εκατό ή ένας κανόνας επικύρωσης αλλάζει συμπεριφορά—χωρίς δικούς σας ελέγχους και χωρίς ούτε μία προειδοποίηση. Αυτό λέγεται λογική απόκλιση και βλάπτει αθόρυβα ακριβώς όσα φέρνουν έσοδα: τιμές, πρόσβαση και πληρωμές.

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

Στην πράξη, αυτό γίνεται ένα έτοιμο πλαίσιο που χρησιμοποιείτε πριν από οποιαδήποτε αλλαγή στον λειτουργικό κώδικα. Κάνει την AI να προχωρά με μικρά βήματα και να σας δείχνει ακριβώς τι άλλαξε.

Πριν αλλάξεις τον κώδικα, κάνε τα εξής:

Αποθήκευσε την τρέχουσα λειτουργική κατάσταση ως ξεχωριστό σημείο επαναφοράς (commit).

Περιέγραψε με λόγια ακριβώς τι σχεδιάζεις να αλλάξεις και σε ποια αρχεία.

Κάνε την όσο το δυνατόν μικρότερη αλλαγή—μόνο ό,τι λύνει την εργασία μου, τίποτα επιπλέον.

Δείξε μου τι άλλαξε και εξήγησε κάθε αλλαγή, ώστε να μπορώ να την εξηγήσω σε κάποιον άλλο.
Μην αγγίξεις τη λογική τιμολόγησης, πρόσβασης ή πληρωμών, εκτός αν σου το ζητήσω.

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

Όλα όσα περιγράφω βασίζονται σε ένα πράγμα: τη διαχείριση του πλαισίου. Για να εμποδίσετε την AI να χαλάσει τη γειτονική λογική, πρέπει να θυμάται τους κανόνες του έργου σας.

Πώς ελέγχετε μια αλλαγή πριν τη δημοσιεύσετε;#

Ανάμεσα στο «λειτουργεί στον υπολογιστή μου» και στο «λειτουργεί για όλους» υπάρχει ένα ενδιάμεσο βήμα που παραλείπουν οι αρχάριοι: ένα δοκιμαστικό αντίγραφο. Είναι ένα ξεχωριστό στιγμιότυπο του περιβάλλοντος παραγωγής σας, όπου ελέγχετε μια αλλαγή προτού τη δουν πραγματικοί άνθρωποι. Ο κύκλος εργασίας είναι ο εξής:

1. Δημιουργήστε και ελέγξτε μόνοι σας την αλλαγή (περιβάλλον ανάπτυξης).
2. Κάντε deploy στο staging—ένα αντίγραφο της παραγωγής, αλλά χωρίς πραγματικούς χρήστες.
3. Εκτελέστε τα βασικά σενάρια και βεβαιωθείτε ότι τίποτα δεν έχει αλλάξει.
4. Μόνο τώρα κάντε deploy στην παραγωγή.

Γιατί έχει σημασία μετά την κυκλοφορία: κάθε έκδοση ενέχει κίνδυνο. Μια μικρή αλλαγή κώδικα μπορεί να χαλάσει τη σύνδεση σε λογαριασμό. Μια ρύθμιση που λείπει μπορεί να ρίξει ολόκληρο το προϊόν. Το staging εντοπίζει αυτά τα προβλήματα χωρίς συνέπειες· στην παραγωγή χάνετε πελάτες.

Για να μη χρειάζεται να ελέγχετε τα πάντα χειροκίνητα κάθε φορά, δώστε στην AI μια προτροπή να συγκρίνει τη συμπεριφορά της νέας έκδοσης με την παλιά στους κρίσιμους τομείς.

Πρόκειται να κάνω deploy μια αλλαγή. Έλεγξε διαδοχικά τα βασικά σενάρια του προϊόντος και βεβαιώσου ότι το καθένα εξακολουθεί να λειτουργεί όπως πριν:

Εγγραφή και σύνδεση νέου χρήστη.

Πληρωμή και παραχώρηση πρόσβασης μετά την πληρωμή.

Δικαιώματα πρόσβασης—ένας απλός χρήστης δεν μπορεί να δει τα δεδομένα κάποιου άλλου ή την περιοχή διαχείρισης.

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

Πού βρίσκονται τα μυστικά σας; Το μεγαλύτερο κενό για έναν αρχάριο#

Θα εξηγήσω λεπτομερώς τη μεγαλύτερη νάρκη, επειδή καταστρέφει περισσότερα προϊόντα από οποιαδήποτε άλλη. Όταν η AI γράφει κώδικα, το πιο εύκολο είναι να βάλει ένα κλειδί εκεί όπου θα λειτουργήσει αμέσως—απευθείας στον κώδικα της σελίδας που ανοίγει στο πρόγραμμα περιήγησης. Δεν θα παρατηρήσετε τη διαφορά κατά την ανάπτυξη. Όμως οποιοσδήποτε μπορεί να διαβάσει οτιδήποτε φτάνει στο πρόγραμμα περιήγησης, ανοίγοντας τα εργαλεία προγραμματιστή.

Ο ιδρυτής του οποίου οι πελάτες χρεώθηκαν $87,500 είπε αργότερα ότι μία προτροπή θα μπορούσε να το είχε αποτρέψει. Οι χρεώσεις τελικά αντιστράφηκαν, αλλά οι μη επιστρέψιμες προμήθειες και η χαμένη ηρεμία παρέμειναν. Αυτή είναι εκείνη η προτροπή.

Έλεγξε ολόκληρο το έργο και βεβαιώσου ότι κανένα μυστικό κλειδί δεν καταλήγει στο πρόγραμμα περιήγησης:

Βρες όλα τα κλειδιά για τη βάση δεδομένων, το σύστημα πληρωμών και τις εξωτερικές υπηρεσίες.

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

Έλεγξε το ιστορικό του έργου—μήπως κάποιο κλειδί μπήκε κατά λάθος εκεί παλαιότερα;
Δείξε μου μια λίστα με κάθε σημείο όπου βρήκες μυστικά και τι πρέπει να γίνει για το καθένα.

Η επόμενη κοντινή νάρκη είναι ο έλεγχος των δικαιωμάτων πρόσβασης μόνο από την πλευρά του προγράμματος περιήγησης. Αν το προϊόν αποφασίζει αν θα «εμφανίσει την περιοχή διαχείρισης» μέσα στον κώδικα της σελίδας, οποιοσδήποτε μπορεί να παρακάμψει αυτήν την απόφαση. Τα δικαιώματα πρόσβασης πρέπει πάντα να ελέγχονται στον διακομιστή. Η βάση δεδομένων πρέπει να επιστρέφει δεδομένα μόνο σε όσους δικαιούνται να τα λάβουν—γι’ αυτό υπάρχει η ασφάλεια σε επίπεδο γραμμής (RLS), και πρέπει να είναι ενεργοποιημένη σε κάθε πίνακα.

Πριν πουλήσετε πρόσβαση ή αφήσετε άλλους να μπουν, εκτελέστε έναν γενικό έλεγχο ασφαλείας του προϊόντος.

Έλεγξε το έργο σαν επιτιθέμενος και εντόπισε κενά ασφαλείας:

Υπάρχουν μυστικά κλειδιά αποθηκευμένα σε κώδικα που αποστέλλεται στο πρόγραμμα περιήγησης ή στο ιστορικό του έργου;

Είναι ενεργοποιημένη η ασφάλεια σε επίπεδο γραμμής (RLS) σε κάθε πίνακα της βάσης δεδομένων και ελέγχονται τα δικαιώματα πρόσβασης στον διακομιστή και όχι μόνο στο πρόγραμμα περιήγησης;

Έχει ρυθμιστεί αυτόματο αντίγραφο ασφαλείας της βάσης δεδομένων και έχω ελέγξει ποτέ ότι μπορώ να το επαναφέρω;

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

Υπάρχει ξεχωριστός, πλήρης οδηγός για την ασφάλεια του vibe coding: Πώς να ασφαλίσετε μια εφαρμογή φτιαγμένη με vibe coding. Ο κανόνας είναι απλός: αντιμετωπίζετε ως μη ασφαλές οτιδήποτε έκανε η AI από προεπιλογή, μέχρι να ελέγξετε το αντίθετο.

Πού να φιλοξενήσετε το προϊόν σας: η κλίμακα φιλοξενίας#

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

1. Δωρεάν φιλοξενία (για παράδειγμα, Vercel)—για εσάς, δοκιμές και μικρά έργα. Λειτουργεί αν η πλατφόρμα είναι διαθέσιμη στο κοινό σας και δεν αποθηκεύετε προσωπικά δεδομένα ανθρώπων.
2. Πλατφόρμα με deploy με μία εντολή (Railway)—όταν έχετε backend και βάση δεδομένων. Κάνετε deploy με μία εντολή και δεν χρειάζεται να ρυθμίσετε διακομιστή. Το εμπόδιο εισόδου είναι ελάχιστο.
3. Δικός σας αποκλειστικός διακομιστής—όταν ο φόρτος είναι υψηλός και χρειάζεστε πλήρη έλεγχο. Μεταβείτε σε αυτόν αργότερα, όταν φτάσετε στο όριο της πλατφόρμας.

Για κάποιον που δεν είναι προγραμματιστής και μόλις κυκλοφόρησε το προϊόν του, η ευκολότερη επιλογή είναι μια πλατφόρμα με deploy με μία εντολή, χωρίς χειροκίνητη ρύθμιση διακομιστή. Μεταβείτε στον δικό σας διακομιστή αργότερα. Αν θέλετε να ακολουθήσετε αυτήν τη διαδρομή με ένα συγκεκριμένο παράδειγμα, δείτε τον οδηγό για deploy ενός έργου vibe coding στον δικό σας διακομιστή με Coolify.

Πότε πρέπει να διαχωρίσετε την εφαρμογή, τη βάση δεδομένων και τα αντίγραφα ασφαλείας;#

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

• Βάλτε την εφαρμογή και τη βάση δεδομένων σε διαφορετικά μηχανήματα. Το σημάδι: στον φόρτο αιχμής, η CPU και η μνήμη παραμένουν πάνω από 70–80 τοις εκατό, τα αιτήματα καθυστερούν και η εφαρμογή με τη βάση δεδομένων ανταγωνίζονται για τους ίδιους πόρους. Μετά τον διαχωρισμό, μπορείτε να ενισχύσετε τη βάση δεδομένων χωρίς να αγγίξετε την εφαρμογή και το αντίστροφο.
• Ακολουθήστε τον κανόνα αντιγράφων ασφαλείας 3-2-1. Τρία αντίγραφα των δεδομένων, σε δύο διαφορετικούς τύπους μέσων, με ένα εκτός εγκατάστασης. Αυτό προστατεύει από αστοχία υλικού και ransomware. Το βασικό είναι τα αντίγραφα ασφαλείας να είναι αυτόματα.

Η συχνότητα των αντιγράφων ασφαλείας εξαρτάται από το πόσο κοστίζει η απώλεια δεδομένων αρκετών ωρών. Για διαδικτυακή συνδρομητική υπηρεσία όπου η απώλεια μίας ώρας αρχείων πληρωμών είναι απαράδεκτη, το διάστημα backup πρέπει να είναι μικρότερο από ώρα ή χρειάζονται επαληθευμένα logs συναλλαγών και ανάκτηση συγκεκριμένης χρονικής στιγμής (PITR). Επιλέξτε διάστημα βάσει μέγιστης ανεκτής απώλειας δεδομένων και δοκιμάστε χωριστά τον χρόνο αποκατάστασης της υπηρεσίας. Για ένα ιστολόγιο, μία φορά την ημέρα αρκεί. Η λογική είναι απλή: αποφασίστε πόσα δεδομένα μπορείτε να αντέξετε να χάσετε και ρυθμίστε ανάλογα τα αντίγραφα ασφαλείας.

Βοήθησέ με να αποφασίσω αν ήρθε η ώρα το προϊόν μου να περάσει σε πιο σοβαρή υποδομή. Έλεγξε και ρώτησέ με για κάθε σημείο:

Πόσο φορτωμένες είναι η CPU και η μνήμη στις ώρες αιχμής—παραμένει η χρήση πάνω από 70–80 τοις εκατό ή όχι;

Βρίσκονται η βάση δεδομένων και η εφαρμογή στο ίδιο μηχάνημα ή σε διαφορετικά;

Έχει ρυθμιστεί αυτόματο αντίγραφο ασφαλείας της βάσης δεδομένων και έχω δοκιμάσει την επαναφορά από αυτό;

Υπάρχει ξεχωριστό αντίγραφο του περιβάλλοντος (staging) για έλεγχο πριν από το deploy;
Με βάση τα αποτελέσματα, δώσε μου σαφή σύσταση: τι να αφήσω ως έχει, τι να διαχωρίσω πρώτο και γιατί.

Υπάρχει και ένα ξεχωριστό ερώτημα: διαχειριζόμενη βάση δεδομένων ή δική σας. Για μια μικρή ομάδα, η διαχειριζόμενη είναι σχεδόν πάντα καλύτερη: η δική σας κοστίζει λιγότερο σε υλικό, αλλά καταναλώνει ώρες συντήρησης. Αν είστε μόνοι και το προϊόν σας δεν είναι υποδομή, αυτές οι ώρες κοστίζουν περισσότερο από τη διαφορά στην τιμή του διακομιστή.

Πώς βάζετε τη συντήρηση στον αυτόματο πιλότο;#

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

Η παρακολούθηση χρησιμοποιεί δύο διαφορετικά εργαλεία για δύο διαφορετικές εργασίες:

1. «Είναι ενεργός ο ιστότοπος;»—ένα εργαλείο παρακολούθησης διαθεσιμότητας (για παράδειγμα, UptimeRobot). Ελέγχει το προϊόν κάθε λίγα λεπτά και στέλνει ειδοποίηση αν πέσει. Υπάρχει δωρεάν πρόγραμμα.
2. «Τι ακριβώς χάλασε;»—ένα εργαλείο παρακολούθησης σφαλμάτων (για παράδειγμα, Sentry). Συλλέγει σφάλματα μέσα στην εφαρμογή και δείχνει πού και γιατί απέτυχε κάτι.

Το πρώτο εντοπίζει ότι το προϊόν έπεσε. Το δεύτερο δείχνει ποια λειτουργία απέτυχε και γιατί. Μαζί απαντούν στο ερώτημα: «Θα μάθω για μια βλάβη πριν γράψει πελάτης στην υποστήριξη;»

Το δεύτερο επίπεδο αυτοματοποίησης είναι ένας πράκτορας περιπολίας. Φανταστείτε ένα μεσιτικό γραφείο: στις επτά το πρωί, ένας πράκτορας AI διαβάζει τα ερωτήματα στον ιστότοπο, βλέπει ότι η φόρμα κράτησης δεν λειτουργεί, βρίσκει την αιτία στον κώδικα και σας φέρνει μια έτοιμη διόρθωση μαζί με εξήγηση. Την εξετάζετε και λέτε «ναι»—γίνεται deploy. Η σειρά έχει σημασία: πρώτα επιλύστε το πρόβλημα του χρήστη (παραχωρήστε πρόσβαση, ζητήστε συγγνώμη), έπειτα διερευνήστε την αιτία και τα χρήματα.

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

Πότε είναι ώρα να κλείσετε ένα προϊόν;#

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

Όρια που μπορείτε να χρησιμοποιήσετε για να πάρετε την απόφαση:

1. Δύο εβδομάδες—αρκετές για να δείτε αν λειτουργεί μια ιδέα. Αν επιστρέψουν οι πρώτοι πραγματικοί χρήστες, συνεχίστε. Η σιωπή είναι απάντηση.
2. Τρεις μήνες—το απόλυτο όριο. Αν δεν απογειώθηκε μέσα σε τρεις μήνες, κλείστε το. Με την ταχύτητα του vibe coding, έξι μήνες δοκιμών για μία ιδέα είναι υπερβολικά πολλοί.

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

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

Η δημιουργία ενός προϊόντος με AI μέσα σε ένα βράδυ είναι η μισή δουλειά. Το να το διατηρείτε ζωντανό και ασφαλές καθώς μεγαλώνει—αυτό σημαίνει vibe coding για ενηλίκους.

Για το επόμενο βήμα σας—Ailoot.