Ο κώδικας είναι το μοναδικό εγχειρίδιο
Η γνώση βρίσκεται σκόρπια σε αρχεία, σχόλια, ονόματα πεδίων, εξαιρέσεις, scripts και ανθρώπινες αναμνήσεις.
Μην το πειράξεις.
Ο πραγματικός λόγος που ο κόσμος χρειάζεται τόσο ισχυρό AI
Το φτιάχνουν για να ξαναδιαβάσουν, να καταλάβουν και να εκμοντερνίσουν τον παλιό κώδικα που κρατά ακόμη τον σύγχρονο κόσμο σε λειτουργία.
Η μεγάλη ανάγκη της εποχής δεν είναι απλώς να παραγάγουμε περισσότερο περιεχόμενο. Είναι να καταλάβουμε ξανά τις παλιές υποδομές πάνω στις οποίες στηρίζονται οι τράπεζες, οι πληρωμές, οι κυβερνήσεις, οι μεταφορές, οι τηλεπικοινωνίες και ένα τεράστιο μέρος της πραγματικής οικονομίας.
Όταν κάποιος ακούει ότι οι μεγαλύτερες εταιρείες του κόσμου ξοδεύουν δισεκατομμύρια για όλο και ισχυρότερα μοντέλα AI, η πρώτη σκέψη είναι συνήθως απλή:
Θέλουν να αντικαταστήσουν τον άνθρωπο.
Δεν είναι παράλογο να υπάρχει αυτός ο φόβος.
Πολλές δουλειές θα αλλάξουν. Πολλές διαδικασίες θα αυτοματοποιηθούν. Κάποια επαγγέλματα θα πιεστούν και ορισμένες εργασίες θα εξαφανιστούν.
Αλλά αυτή δεν είναι όλη η εικόνα.
Υπάρχει ένας πολύ μεγαλύτερος, πολύ πιο αθόρυβος και πολύ πιο επικίνδυνος λόγος για τον οποίο ο κόσμος χρειάζεται ισχυρό AI.
Οι σημαντικότερες υποδομές μας δεν γράφτηκαν χθες. Χτίστηκαν σταδιακά, για δεκαετίες, από ανθρώπους, ομάδες και οργανισμούς που πολλές φορές δεν υπάρχουν πλέον με την αρχική τους μορφή.
Το AI δεν κατασκευάζεται μόνο για να γράφει email, να δημιουργεί εικόνες, να απαντά σε πελάτες ή να φτιάχνει παρουσιάσεις.
Κατασκευάζεται και για να διαβάσει, να χαρτογραφήσει και να βοηθήσει στην ανακατασκευή της ψηφιακής μηχανής πάνω στην οποία λειτουργεί ολόκληρη η σύγχρονη κοινωνία.
Όχι σε ένα ξεχασμένο πρόγραμμα που βρίσκεται σε έναν παλιό υπολογιστή και κανένας δεν χρησιμοποιεί.
Μιλάμε για λογισμικό που κρατά σε λειτουργία τράπεζες, ασφαλιστικές εταιρείες, πληρωμές, κρατικές υπηρεσίες, εφοδιαστικές αλυσίδες, αεροπορικές εταιρείες, τηλεπικοινωνίες, εργοστάσια και τεράστια εταιρικά συστήματα.
Κώδικας γραμμένος σε COBOL, Assembly, PL/I, παλιές εκδόσεις Java, mainframes, ιδιόκτητα συστήματα και βάσεις δεδομένων που δημιουργήθηκαν πριν το Internet αποκτήσει τη μορφή που γνωρίζουμε σήμερα.
Και το πραγματικό πρόβλημα δεν είναι ότι ο κώδικας είναι παλιός.
Ένας παλιός κώδικας μπορεί να λειτουργεί εξαιρετικά, να είναι γρήγορος, σταθερός και δοκιμασμένος μέσα σε πραγματικές συνθήκες για δεκαετίες.
Το πραγματικό πρόβλημα είναι ότι πολλές φορές κανένας δεν γνωρίζει πλέον ολόκληρο το σύστημα.
Η γνώση σπάνια εξαφανίζεται ολόκληρη μέσα σε μία ημέρα.
Συνήθως διαλύεται σε μικρά κομμάτια.
Γνωρίζει γιατί μία παράξενη γραμμή κώδικα υπάρχει ακόμη, αλλά η εξήγηση δεν γράφτηκε ποτέ σε κανένα επίσημο έγγραφο.
Ένα αρχείο που κανένας δεν θεωρεί σημαντικό, αλλά περιέχει αντιστοιχίσεις, εξαιρέσεις και κανόνες χωρίς τους οποίους μία διαδικασία δεν μπορεί να επαναληφθεί σωστά.
Η πραγματική επιχειρησιακή λογική δεν βρίσκεται σε ένα καθαρό διάγραμμα. Έχει χτιστεί σταδιακά μέσα από διορθώσεις, εξαιρέσεις και αποφάσεις δεκαετιών.
«Μην το πειράξεις. Κάτι σημαντικό συνδέεται εκεί μέσα.»
Αυτός είναι ο πραγματικός εφιάλτης των μεγάλων οργανισμών.
Δεν φοβούνται απλώς ότι το λογισμικό είναι παλιό, αργό ή άσχημο.
Φοβούνται ότι αν το αλλάξουν χωρίς να το καταλάβουν πλήρως, μπορούν να σταματήσουν πληρωμές, να αλλοιώσουν λογιστικές εγγραφές, να διακόψουν κρίσιμες υπηρεσίες, να δημιουργήσουν κανονιστικές παραβάσεις ή να καταστρέψουν επιχειρησιακή γνώση δεκαετιών.
Ο παλιός κώδικας δεν είναι πάντα το πρόβλημα. Το πρόβλημα είναι ο κώδικας που κανένας δεν τολμά να αγγίξει.
Ένα παλιό σύστημα δεν αντικαθίσταται απλώς με ένα νέο interface, ένα σύγχρονο dashboard ή μία εφαρμογή στο cloud.
Πρέπει πρώτα να γίνει αρχαιολογία.
Πρέπει κάποιος να βρει τι κάνει κάθε κομμάτι κώδικα.
Πρέπει να καταλάβει ποιες βάσεις δεδομένων συνδέονται μεταξύ τους.
Πρέπει να ανακαλύψει ποιοι κανόνες είναι τεχνικοί και ποιοι είναι επιχειρησιακοί.
Πρέπει να ξεχωρίσει το άχρηστο από το κρίσιμο.
Πρέπει να βεβαιωθεί ότι το νέο σύστημα θα δίνει το ίδιο σωστό αποτέλεσμα με το παλιό, ακόμη και στις εξαιρέσεις που κανένας δεν θυμάται πλέον ότι υπάρχουν.
Ξαναχτίζεις πρώτα την κατανόηση του συστήματος. Χωρίς αυτήν, το rewrite δεν είναι εκσυγχρονισμός. Είναι ένα μεγάλο στοίχημα πάνω σε άγνωστες συνέπειες.
Εδώ αρχίζει να φαίνεται ο πραγματικός ρόλος του AI.
Το AI δεν είναι μόνο ένα εργαλείο που γράφει κείμενα, απαντά σε ερωτήσεις ή δημιουργεί εικόνες.
Μπορεί να διαβάζει τεράστιους όγκους παλιού κώδικα.
Μπορεί να χαρτογραφεί εξαρτήσεις.
Μπορεί να δημιουργεί τεκμηρίωση εκεί όπου δεν υπάρχει.
Μπορεί να εξηγεί έναν παλιό κώδικα σε μία νέα ομάδα developers.
Μπορεί να βοηθά στη μετατροπή εφαρμογών σε σύγχρονες γλώσσες και αρχιτεκτονικές.
Μπορεί να δημιουργεί tests, να συγκρίνει αποτελέσματα και να επισημαίνει σημεία που απαιτούν ανθρώπινο έλεγχο.
Η γνώση βρίσκεται σκόρπια σε αρχεία, σχόλια, ονόματα πεδίων, εξαιρέσεις, scripts και ανθρώπινες αναμνήσεις.
Μην το πειράξεις.
Οι εξαρτήσεις, οι ροές, οι κανόνες και τα σημεία υψηλού ρίσκου αρχίζουν να γίνονται ορατά και ελέγξιμα.
Τώρα ξέρουμε τι αγγίζουμε.
Το AI καλείται να βοηθήσει τον κόσμο να ξαναδιαβάσει τον ίδιο του τον εαυτό.
Και αυτή η ανάγκη δεν εμφανίστηκε απλώς επειδή οι άνθρωποι έγιναν ξαφνικά λιγότερο έξυπνοι.
Εμφανίστηκε επειδή χτίσαμε συστήματα τόσο μεγάλα, τόσο παλιά και τόσο κρίσιμα, ώστε η συνολική τους γνώση δεν χωρά πλέον στο μυαλό ενός ανθρώπου ή μιας μικρής ομάδας.
Για δεκαετίες, η εκπαίδευση και η εργασία επιβράβευαν κυρίως την εκτέλεση.
Έτσι γεννιούνται οργανισμοί που ξέρουν να χρησιμοποιούν εργαλεία, αλλά δεν γνωρίζουν πάντα την υποδομή πάνω στην οποία στηρίζονται.
Κάθε εργαζόμενος γνωρίζει ένα μικρό τμήμα.
Κάθε ομάδα προστατεύει ένα μικρό subsystem.
Κάθε προμηθευτής γνωρίζει μία συγκεκριμένη διασύνδεση.
Και όταν αποχωρήσουν οι άνθρωποι που δημιούργησαν το αρχικό σύστημα, μένει πίσω ένα τεράστιο κτίριο χωρίς ολοκληρωμένα αρχιτεκτονικά σχέδια.
Η μεγαλύτερη απειλή δεν είναι πάντοτε η άμεση αστοχία. Είναι η σταδιακή απώλεια της ικανότητας να εξελίξεις, να διορθώσεις και να ξαναχτίσεις αυτό που ήδη έχεις.
Το AI δεν έρχεται να αντικαταστήσει μαγικά αυτή τη χαμένη ανθρώπινη κατανόηση.
Έρχεται να λειτουργήσει ως επιταχυντής ανάκτησης, σύνδεσης και τεκμηρίωσης της γνώσης, πριν η απόσταση ανάμεσα στο σύστημα και στους ανθρώπους που το συντηρούν γίνει αδύνατον να γεφυρωθεί.
Υπάρχει μία ιστορία που συχνά λέγεται με λάθος τρόπο:
Πήγαμε στο φεγγάρι τη δεκαετία του ’60 και μετά χάσαμε την τεχνολογία.
Η πραγματικότητα είναι πιο ενδιαφέρουσα.
Δεν χάθηκαν όλα τα σχέδια.
Δεν ξεχάστηκε η φυσική.
Δεν εξαφανίστηκε η τεχνολογία μέσα σε μία νύχτα.
Χάθηκε όμως κάτι εξίσου σημαντικό.
Ένα σχέδιο μπορεί να σου πει τι πρέπει να κατασκευάσεις.
Δεν μπορεί πάντα να σου εξηγήσει όλα όσα έμαθε μία ομάδα μέσα από χιλιάδες ώρες δοκιμών, αποτυχιών, διορθώσεων και αλλαγών.
Ο κινητήρας F-1 του Saturn V δεν ήταν ένα μαγικό αντικείμενο που απλώς ξεχάσαμε πώς λειτουργεί.
Ήταν το αποτέλεσμα τεράστιας ανάπτυξης, συνεχών δοκιμών και επίλυσης προβλημάτων καύσης που απαιτούσαν πραγματική πειραματική μηχανική.
Ακόμη και η μνήμη των υπολογιστών Apollo αντιπροσώπευε μία διαφορετική φιλοσοφία τεχνολογίας: σύρματα, μαγνητικοί πυρήνες, φυσικά υφασμένος κώδικας, ακραία βελτιστοποίηση και σχεδόν μηδενικό περιθώριο λάθους.
Δεν χάθηκε η δυνατότητα να τα μελετήσουμε.
Χάθηκε η καθημερινή, ζωντανή ικανότητα να τα ξαναπαράγουμε άμεσα, με την ίδια αλυσίδα ανθρώπων, εργαλείων και εμπειρίας.
Ο source code μπορεί να υπάρχει. Η ζωντανή όμως κατανόηση του γιατί γράφτηκε έτσι, ποιες εξαιρέσεις προστατεύει και τι θα σπάσει αν αλλάξει, μπορεί να έχει ήδη απομακρυνθεί από τον οργανισμό.
Ένας παλιός κώδικας που είναι τεκμηριωμένος, ελεγμένος και κατανοητός μπορεί να συνεχίσει να λειτουργεί για πολλά χρόνια.
Ένας ολοκαίνουργιος κώδικας που κανένας δεν καταλαβαίνει μπορεί να γίνει καταστροφή μέσα σε έξι μήνες.
Έχει πολλά επίπεδα abstraction, dependencies και αυτοματισμούς, αλλά κανένας δεν μπορεί να εξηγήσει ολόκληρη τη συμπεριφορά του όταν κάτι αποτύχει.
Δουλεύει. Μην ρωτάς πώς.
Οι είσοδοι, οι έξοδοι, οι κανόνες, οι εξαιρέσεις και οι ασφαλείς καταστάσεις του είναι γνωστές και μπορούν να επαληθευτούν.
Ξέρουμε τι κάνει και γιατί.
Γι’ αυτό το ζητούμενο δεν είναι να πάρει κάποιος ένα AI και να του πει:
Ξαναγράψε μου την τράπεζα.
Αυτό θα ήταν ανεύθυνο.
Το σωστό μοντέλο είναι διαφορετικό.
Το AI χαρτογραφεί. Ο άνθρωπος ελέγχει. Το AI δημιουργεί tests. Η ομάδα επιβεβαιώνει. Το νέο σύστημα τρέχει παράλληλα με το παλιό. Τα αποτελέσματα συγκρίνονται. Υπάρχει rollback. Υπάρχει απόδειξη. Υπάρχει ανθρώπινη ευθύνη.
Το AI δεν πρέπει να γίνει ο αυτόματος πιλότος μίας κρίσιμης υποδομής.
Πρέπει να γίνει ο γρηγορότερος βοηθός μηχανικού που είχαμε ποτέ.
Ένας βοηθός που δεν κουράζεται να διαβάζει τεράστιους όγκους κώδικα.
Που μπορεί να κρατήσει ορατές περισσότερες εξαρτήσεις από όσες μπορεί να διαχειριστεί ένας άνθρωπος.
Που μπορεί να εξηγήσει παλιές λειτουργίες σε νέες ομάδες.
Που μπορεί να βοηθήσει στη μεταφορά γνώσης πριν χαθεί ολοκληρωτικά.
Που μπορεί να επιταχύνει την εργασία, χωρίς να αποκτήσει την ευθύνη του αποτελέσματος.
Το AI μπορεί να μας βοηθήσει να ξαναβρούμε τη γνώση. Δεν μπορεί να αναλάβει την ευθύνη για το τι θα κάνουμε με αυτήν.
Όταν μία αλλαγή πολιτικής, μία λάθος ρύθμιση ή ένα απρόβλεπτο αρχείο επηρεάζει υπηρεσίες παγκόσμιας κλίμακας, δεν σημαίνει ότι ένας developer είναι άχρηστος.
Σημαίνει ότι ο κόσμος έχει γίνει υπερβολικά συγκεντρωμένος και υπερβολικά εξαρτημένος από αλυσίδες συστημάτων που ελάχιστοι άνθρωποι μπορούν να δουν ολόκληρες.
Μία αλλαγή σε ένα κεντρικό quota-management σύστημα μπορεί να επηρεάσει υπηρεσίες σε ολόκληρο τον κόσμο.
Ένα configuration file που μεγαλώνει περισσότερο από όσο προβλέπει το σύστημα μπορεί να προκαλέσει αλυσιδωτή αποτυχία σε υποδομές που εξυπηρετούν τεράστιο μέρος του Internet.
Δεν χρειάζεται ένας κακόβουλος hacker.
Δεν χρειάζεται μία κινηματογραφική επίθεση.
Αρκεί μία αλληλουχία εξαρτήσεων που κανένας δεν είχε δει να συγκρούεται με αυτόν ακριβώς τον τρόπο.
Όσο περισσότερο ψηφιοποιείται η κοινωνία, τόσο πιο πολύτιμο γίνεται κάθε εργαλείο που μπορεί να βοηθήσει να καταλάβουμε, να ελέγξουμε και να ξαναχτίσουμε αυτή την υποδομή χωρίς να τη διαλύσουμε.
Κάποιες δουλειές θα αλλάξουν.
Κάποιες θα μειωθούν.
Κάποιες θα γίνουν πολύ γρηγορότερες.
Κάποιες εργασίες που σήμερα απαιτούν μεγάλες ομάδες θα μπορούν να ολοκληρώνονται από πολύ λιγότερους ανθρώπους.
Αλλά το μεγάλο παιχνίδι δεν είναι μόνο αυτό.
Το AI δεν χτίζεται μόνο για να γράψει διαφημίσεις, να απαντήσει σε πελάτες ή να κάνει έναν junior developer γρηγορότερο.
Χτίζεται και επειδή ο κόσμος έχει μπροστά του ένα τεράστιο τεχνικό χρέος.
Το AI δεν είναι εδώ μόνο για να αντικαταστήσει εργασίες.
Είναι εδώ για να βοηθήσει να ξανακάνουμε εργασίες που ο κόσμος άφησε πίσω του για δεκαετίες.
Να διαβάσουμε τον παλιό κόσμο.
Να καταλάβουμε πώς λειτουργεί.
Να κρατήσουμε ό,τι αξίζει.
Να αντικαταστήσουμε ό,τι είναι επικίνδυνο.
Να ξαναγράψουμε ό,τι πλέον δεν μπορεί να συντηρηθεί.
Ο βασικός λόγος για τον οποίο αναπτύσσεται το AI δεν είναι μόνο για να κάνει τη δουλειά σου. Είναι και για να κάνει τη δουλειά που ο κόσμος δεν μπορεί πλέον να εκτελέσει στην απαιτούμενη κλίμακα.
Το AI μπορεί να γράψει κώδικα.
Μπορεί να εξηγήσει κώδικα.
Μπορεί να προτείνει αρχιτεκτονική.
Μπορεί να δημιουργήσει tests.
Μπορεί να συγκρίνει αποτελέσματα.
Μπορεί να εντοπίσει μοτίβα που ένας άνθρωπος ίσως δεν προλάβαινε ποτέ να δει.
Δεν μπορεί όμως να αναλάβει την ευθύνη του αποτελέσματος.
Η κρίση, η ευθύνη, η έγκριση, η αποδοχή του ρίσκου και η απόφαση να περάσει μία αλλαγή σε πραγματική παραγωγή παραμένουν ανθρώπινη δουλειά.
Ίσως αυτή να είναι η σημαντικότερη δουλειά της επόμενης δεκαετίας.
Όχι να ανταγωνιστούμε το AI στην ταχύτητα.
Αλλά να μάθουμε να το χρησιμοποιούμε για να επαναφέρουμε την κατανόηση, χωρίς να του παραδώσουμε την ευθύνη.
Αφού είδαμε γιατί ο κόσμος χρειάζεται τόσο πολύ AI, πρέπει τώρα να δούμε την οικονομική παγίδα, το χάσμα ανάμεσα στο chat και το API και το ρίσκο μιας επιχείρησης που δεν μπορεί πλέον να λειτουργήσει χωρίς τον provider της.
Οι αναφορές σε legacy συστήματα δεν αποτελούν θεωρητική υπερβολή. Δημόσιοι οργανισμοί, τράπεζες και μεγάλες επιχειρήσεις εξακολουθούν να διαχειρίζονται κρίσιμες εφαρμογές δεκαετιών, των οποίων η αντικατάσταση απαιτεί μακροχρόνιο σχεδιασμό, τεκμηρίωση και έλεγχο.
Η GAO έχει καταγράψει κρίσιμα legacy συστήματα στις ομοσπονδιακές υπηρεσίες των ΗΠΑ, μαζί με δυσκολίες που αφορούν παλιές γλώσσες, κυβερνοασφάλεια, κόστος, εξάρτηση από εξειδικευμένο προσωπικό και ελλιπή σχέδια εκσυγχρονισμού.
Η Τράπεζα της Αγγλίας έχει επίσης αναγνωρίσει ότι χρηματοοικονομικές εταιρείες μπορεί να χρειαστεί να επανασχεδιάσουν ή να αντικαταστήσουν κρίσιμα legacy συστήματα, παρά το ρίσκο και την πολυπλοκότητα αυτής της μετάβασης.
Google Cloud, AWS και IBM προσφέρουν ήδη εργαλεία για ανάλυση mainframe και COBOL εφαρμογών, χαρτογράφηση εξαρτήσεων, παραγωγή τεκμηρίωσης, δημιουργία migration plans και υποστήριξη μετασχηματισμού κώδικα.
Στην ιστορία του Apollo, η ακριβέστερη διατύπωση δεν είναι ότι «χάθηκε όλη η τεχνολογία». Χάθηκε η ενεργή παραγωγική αλυσίδα, μεγάλο μέρος της άρρητης γνώσης, οι ομάδες, οι προμηθευτές, τα εργαλεία και η καθημερινή δυνατότητα άμεσης αναπαραγωγής του ίδιου συστήματος.
Τα περιστατικά μεγάλης κλίμακας σε Google Cloud και Cloudflare δείχνουν επίσης ότι μία φαινομενικά περιορισμένη αλλαγή σε κεντρικό subsystem μπορεί να προκαλέσει εκτεταμένες αλυσιδωτές επιπτώσεις. Αυτό δεν αποδεικνύει ότι «ένας junior έριξε το Internet». Αποδεικνύει πόσο βαθιές και δύσκολα ορατές έχουν γίνει οι εξαρτήσεις.
Το AI δεν είναι ο αυτόματος αντικαταστάτης της ανθρώπινης τεχνικής ευθύνης. Είναι το εργαλείο που μπορεί να επιταχύνει την ανάκτηση γνώσης, τη χαρτογράφηση και τον ασφαλή εκσυγχρονισμό υποδομών που κανένας άνθρωπος ή μικρή ομάδα δεν μπορεί πλέον να κατανοήσει μόνος του σε ολόκληρη την κλίμακά τους.
Η οικονομία, η εξάρτηση και το πραγματικό κόστος της νοικιασμένης νοημοσύνης
Το AI μπορεί να γίνει η ισχυρότερη δυνατότητα μιας επιχείρησης. Μπορεί όμως να γίνει και το εξωτερικό σύστημα χωρίς το οποίο η επιχείρηση δεν έχει πλέον προϊόν.
Η μεγάλη παγίδα δεν είναι ότι το AI κοστίζει. Είναι ότι μία φθηνή και βολική λειτουργία μπορεί σταδιακά να μετατραπεί στο μοναδικό σημείο από το οποίο περνά η λειτουργία, η γνώση και η ίδια η ύπαρξη του προϊόντος.
Στην πρώτη καρτέλα της σειράς είδαμε για ποιον λόγο ο κόσμος χρειάζεται τόσο πολύ AI.
Είδαμε ότι ο πλανήτης λειτουργεί πάνω σε τεράστιες ποσότητες παλιού, ακατανόητου και σχεδόν αδύνατον να αντικατασταθεί λογισμικού.
Είδαμε ότι το AI δεν κατασκευάζεται μόνο για να γράφει email, να δημιουργεί εικόνες ή να αντικαθιστά έναν υπάλληλο.
Κατασκευάζεται για να βοηθήσει τον άνθρωπο να ξαναδιαβάσει, να κατανοήσει και τελικά να ξαναγράψει την ψηφιακή υποδομή πάνω στην οποία στηρίζεται ολόκληρος ο σύγχρονος κόσμος.
Αυτό όμως δημιουργεί μια δεύτερη, πολύ πιο ύπουλη ερώτηση:
Τι θα συμβεί όταν οι επιχειρήσεις χτίσουν ολόκληρη τη λειτουργία τους πάνω σε μία νοημοσύνη που δεν τους ανήκει;
Τι θα συμβεί όταν το προϊόν, η εξυπηρέτηση, η παραγωγή, η εκπαίδευση, η λογιστική ανάλυση, ο προγραμματισμός, η λήψη αποφάσεων και η καθημερινή λειτουργία μιας εταιρείας εξαρτώνται από ένα API;
Τι θα συμβεί όταν το API αυτό αλλάξει τιμή;
Όταν αλλάξει μοντέλο;
Όταν αλλάξει όρια;
Όταν αλλάξει πολιτική;
Όταν σταματήσει να υποστηρίζει τη λειτουργία πάνω στην οποία χτίστηκε ολόκληρη η επιχείρηση;
Ή όταν, πολύ απλά, πάψει να υπάρχει;
Καλώς ήρθατε στην παγίδα του πολύ AI.
Για πολλά χρόνια, το οικονομικό μοντέλο του λογισμικού ήταν σχετικά απλό.
Μια εταιρεία ξόδευε χρήματα για να κατασκευάσει ένα πρόγραμμα.
Έγραφε τον κώδικα μία φορά.
Έφτιαχνε τη βάση δεδομένων μία φορά.
Σχεδίαζε το περιβάλλον μία φορά.
Και στη συνέχεια μπορούσε να πουλήσει το ίδιο προϊόν σε εκατό, χίλιους ή ένα εκατομμύριο ανθρώπους.
Φυσικά υπήρχαν έξοδα.
Servers. Υποστήριξη. Αποθήκευση δεδομένων. Ανάπτυξη. Ασφάλεια. Προσωπικό.
Το επιπλέον κόστος όμως για μία ακόμη απλή ενέργεια ενός χρήστη ήταν συνήθως πολύ μικρό.
Το ίδιο κουμπί μπορούσαν να το πατήσουν δέκα άνθρωποι ή δέκα εκατομμύρια άνθρωποι.
Αν η υποδομή ήταν σωστά σχεδιασμένη, τα έσοδα μπορούσαν να αυξάνονται πολύ πιο γρήγορα από το κόστος.
Με το σύγχρονο AI η εξίσωση αλλάζει.
Το AI δεν είναι ένα κουμπί που απλώς εκτελεί πάντα τον ίδιο έτοιμο κώδικα.
Κάθε αίτημα απαιτεί υπολογισμό.
Κάθε μεγάλη συνομιλία απαιτεί να διαβαστεί context.
Κάθε απάντηση απαιτεί παραγωγή νέων tokens.
Κάθε εικόνα, βίντεο, φωνητική συνομιλία, ανάλυση αρχείου ή αυτοματοποιημένη διαδικασία καταναλώνει πραγματική υπολογιστική ισχύ.
Και όσο περισσότερη σκέψη ζητάμε από το μοντέλο, τόσο περισσότερο αυξάνονται οι απαιτήσεις.
Δεν σημαίνει ότι κάθε prompt είναι αναγκαστικά ζημιογόνο.
Σημαίνει όμως ότι κάθε prompt έχει πραγματικό μεταβλητό κόστος.
Αυτό είναι το στοιχείο που διαφοροποιεί το AI από μεγάλο μέρος του λογισμικού που γνωρίζαμε μέχρι σήμερα.
Η εταιρεία δεν πληρώνει μόνο για να εκπαιδεύσει το μοντέλο.
Πληρώνει για να το λειτουργεί.
Πληρώνει για τα chips.
Πληρώνει για τα data centers.
Πληρώνει για την ενέργεια.
Πληρώνει για τα δίκτυα.
Πληρώνει για την ψύξη.
Πληρώνει για την αποθήκευση.
Πληρώνει για την έρευνα του επόμενου μοντέλου, ενώ ταυτόχρονα συνεχίζει να λειτουργεί το προηγούμενο.
Και καθώς ο ανταγωνισμός απαιτεί όλο και μεγαλύτερα, γρηγορότερα και ικανότερα μοντέλα, δημιουργείται ένας τεράστιος βρόχος:
Περισσότερες δυνατότητες φέρνουν περισσότερους χρήστες. Περισσότεροι χρήστες απαιτούν περισσότερη υπολογιστική ισχύ. Περισσότερη υπολογιστική ισχύς απαιτεί μεγαλύτερες επενδύσεις. Μεγαλύτερες επενδύσεις απαιτούν περισσότερα έσοδα. Περισσότερα έσοδα απαιτούν βαθύτερη ενσωμάτωση του AI στις επιχειρήσεις.
Αυτός είναι ο πραγματικός οικονομικός αγώνας που βρίσκεται πίσω από τη σημερινή έκρηξη του AI.
Η εύκολη απάντηση θα ήταν:
«Όχι. Καμία εταιρεία AI δεν είναι βιώσιμη.»
Αυτή όμως θα ήταν μία βολική υπερβολή.
Ορισμένες εταιρείες παρουσιάζουν τεράστια αύξηση εσόδων.
Ορισμένες μπορεί να εμφανίζουν θετικά αποτελέσματα σε συγκεκριμένες δραστηριότητες ή με συγκεκριμένους λογιστικούς υπολογισμούς.
Οι μεγάλες εταιρείες cloud διαθέτουν ήδη κερδοφόρες δραστηριότητες από τις οποίες μπορούν να χρηματοδοτούν την ανάπτυξη του AI.
Το πραγματικό ερώτημα δεν είναι αν κάποια εταιρεία παρουσίασε κέρδος σε ένα τρίμηνο.
Το πραγματικό ερώτημα είναι:
Μπορεί το σημερινό μοντέλο frontier AI να χρηματοδοτεί για πάντα μόνο του την εκπαίδευση, την υποδομή, τη λειτουργία και τη συνεχή αντικατάσταση των μοντέλων του;
Αυτό δεν έχει ακόμη αποδειχθεί.
Τα έσοδα αυξάνονται εντυπωσιακά.
Ταυτόχρονα όμως αυξάνονται και οι δεσμεύσεις για data centers, chips, ενέργεια και υπολογιστική ισχύ.
Δεν βρισκόμαστε μπροστά σε ένα ώριμο οικονομικό μοντέλο που έχει ήδη σταθεροποιηθεί.
Βρισκόμαστε μέσα σε έναν παγκόσμιο αγώνα κατάκτησης της αγοράς.
Οι σημερινές τιμές δεν πρέπει να αντιμετωπίζονται ως φυσικός νόμος.
Είναι τιμές μιας μεταβατικής περιόδου.
Μπορεί να αποτελούν συνδυασμό:
Το γεγονός ότι σήμερα μπορούμε να χρησιμοποιούμε ένα εξαιρετικά ισχυρό μοντέλο με μία συνδρομή είκοσι ή διακοσίων ευρώ δεν αποδεικνύει ότι αυτή θα είναι και η τελική οικονομική του αξία.
Αποδεικνύει μόνο ότι αυτή είναι η τιμή με την οποία η εταιρεία επέλεξε να μας βάλει μέσα στο οικοσύστημά της σήμερα.
Ο provider ελέγχει μοντέλο, όρια, διαθέσιμη σκέψη, διάρκεια, αρχεία και τη συνολική εμπειρία.
Αγοράζεις πρόσβαση.
Input, output, context, εργαλεία, εικόνες, φωνή, reasoning και agent calls περνούν από μετρητή.
Αγοράζεις compute.
Εδώ εμφανίζεται μία από τις μεγαλύτερες παρεξηγήσεις γύρω από το AI.
Ο ίδιος άνθρωπος μπορεί να χρησιμοποιεί ένα μοντέλο μέσα από δύο τελείως διαφορετικές πόρτες.
Η πρώτη πόρτα είναι το chat.
ChatGPT. Claude. Gemini. Ή οποιοδήποτε αντίστοιχο ιδιωτικό περιβάλλον.
Ο χρήστης πληρώνει μία σταθερή μηνιαία συνδρομή και αποκτά πρόσβαση σε ένα σύνολο εργαλείων.
Γράφει κείμενα.
Ανεβάζει αρχεία.
Δημιουργεί εικόνες.
Αναλύει δεδομένα.
Γράφει κώδικα.
Μπορεί να αισθάνεται ότι έχει σχεδόν απεριόριστη χρήση με ένα πολύ μικρό ποσό.
Αυτό όμως δεν είναι πραγματικά απεριόριστο AI.
Είναι ένα διαχειριζόμενο προϊόν.
Η εταιρεία ελέγχει:
Ο χρήστης αγοράζει μία εμπειρία.
Δεν αγοράζει ανεξέλεγκτη υπολογιστική ισχύ.
Η δεύτερη πόρτα είναι το API.
Εδώ τα πράγματα αλλάζουν.
Η επιχείρηση δεν αγοράζει απλώς πρόσβαση σε ένα chat.
Αγοράζει κατανάλωση.
Κάθε input μετριέται.
Κάθε output μετριέται.
Το context μετριέται.
Τα εργαλεία μετριούνται.
Η φωνή μετριέται.
Οι εικόνες μετριούνται.
Η αναζήτηση, η αποθήκευση, το reasoning και οι ειδικές λειτουργίες μπορούν να τιμολογούνται ξεχωριστά.
Όταν ένας άνθρωπος συνομιλεί με το AI, μπορεί να κάνει είκοσι ή εκατό αιτήματα μέσα σε μία ημέρα.
Όταν όμως μία εφαρμογή συνδεθεί με το API, μπορεί να κάνει εκατοντάδες χιλιάδες αιτήματα.
Μπορεί να στέλνει ξανά ολόκληρο το ιστορικό κάθε χρήστη.
Μπορεί να αναλύει κάθε εισερχόμενο μήνυμα.
Μπορεί να δημιουργεί αυτόματα περιλήψεις, ταξινομήσεις, μεταφράσεις, ελέγχους, προτάσεις και αναφορές.
Μπορεί να ενεργοποιεί agents που καλούν άλλους agents.
Και ξαφνικά, μία λειτουργία που μέσα στο chat έμοιαζε να κοστίζει είκοσι ευρώ τον μήνα, γίνεται ένας λογαριασμός εκατοντάδων ή χιλιάδων ευρώ όταν μεταφερθεί σε παραγωγική κλίμακα.
Δεν υπάρχει κάποια αντίφαση.
Η συνδρομή και το API δεν είναι το ίδιο προϊόν.
Η συνδρομή είναι μια ελεγχόμενη ανθρώπινη εμπειρία.
Το API είναι βιομηχανική κατανάλωση.
Ένα AI chat είναι ο ιδανικός τρόπος για να γνωρίσει ο κόσμος την τεχνολογία.
Ο χρήστης μαθαίνει να σκέφτεται μαζί του.
Μαθαίνει να γράφει μαζί του.
Μαθαίνει να προγραμματίζει μαζί του.
Μαθαίνει να του δίνει έγγραφα, πληροφορίες και προβλήματα.
Σταδιακά, σταματά να το αντιμετωπίζει ως ένα εντυπωσιακό εργαλείο.
Αρχίζει να το αντιμετωπίζει ως απαραίτητο συνεργάτη.
Το επόμενο βήμα είναι σχεδόν αναπόφευκτο.
«Αφού το χρησιμοποιώ εγώ κάθε μέρα, γιατί να μην το βάλουμε και μέσα στην επιχείρηση;»
Κάπου εκεί ανοίγει η δεύτερη πόρτα.
Η επιχείρηση συνδέει το API.
Στην αρχή για μία μικρή λειτουργία.
Μετά για μία δεύτερη.
Μετά για την εξυπηρέτηση.
Μετά για την παραγωγή περιεχομένου.
Μετά για την ταξινόμηση δεδομένων.
Μετά για τη διαχείριση αιτημάτων.
Μετά για τη λήψη αποφάσεων.
Μετά για τη συγγραφή κώδικα.
Και τελικά δημιουργείται ένα σύστημα στο οποίο σχεδόν καμία διαδικασία δεν ολοκληρώνεται χωρίς να περάσει πρώτα από το AI.
Δεν χρειάζεται να υπάρχει κάποια μυστική συνωμοσία για να συμβεί αυτό.
Τα οικονομικά κίνητρα αρκούν.
Μία εταιρεία AI έχει πολύ μεγαλύτερη αξία όταν δεν είναι απλώς ένα site που επισκέπτεται ένας χρήστης.
Έχει πολύ μεγαλύτερη αξία όταν βρίσκεται μέσα:
Όσο βαθύτερα ενσωματώνεται, τόσο δυσκολότερα αφαιρείται.
Όσο δυσκολότερα αφαιρείται, τόσο μεγαλύτερη τιμολογιακή δύναμη αποκτά ο provider.
Το API από μόνο του δεν είναι η παγίδα.
Η παγίδα είναι ο τρόπος με τον οποίο θα σχεδιάσουμε το σύστημα γύρω του.
Μπορούμε να χρησιμοποιήσουμε AI για να βελτιώσουμε μία διαδικασία.
Μπορούμε όμως και να χρησιμοποιήσουμε AI για να αντικαταστήσουμε ολοκληρωτικά τη διαδικασία.
Αυτά τα δύο πράγματα δεν είναι ίδια.
Στην πρώτη περίπτωση, το AI αποτελεί επιτάχυνση.
Στη δεύτερη περίπτωση, το AI αποτελεί προϋπόθεση λειτουργίας.
Ας πάρουμε ένα απλό παράδειγμα.
Μία εφαρμογή διαχείρισης εργασιών μπορεί να αποθηκεύει κανονικά:
Το AI μπορεί στη συνέχεια να προτείνει καλύτερο τίτλο, να δημιουργήσει περίληψη, να εντοπίσει κινδύνους ή να προτείνει το επόμενο βήμα.
Αν το AI σταματήσει, η εφαρμογή εξακολουθεί να λειτουργεί.
Οι εργασίες υπάρχουν.
Τα δεδομένα υπάρχουν.
Οι χρήστες μπορούν να συνεχίσουν.
Απλώς χάνουν την έξυπνη βοήθεια.
Αυτό είναι ένα ανθεκτικό σύστημα.
Τώρα ας σχεδιάσουμε την ίδια εφαρμογή διαφορετικά.
Ο χρήστης γράφει ένα ελεύθερο κείμενο.
Το AI αποφασίζει τι είναι εργασία.
Το AI αποφασίζει ποιος είναι υπεύθυνος.
Το AI αποφασίζει την προθεσμία.
Το AI κρατά την περίληψη.
Το AI δημιουργεί τη μοναδική δομή με την οποία εμφανίζεται η πληροφορία.
Χωρίς το AI, η εφαρμογή δεν μπορεί ούτε να καταλάβει ούτε να παρουσιάσει τα δεδομένα της.
Αυτό δεν είναι πλέον ένα λογισμικό που χρησιμοποιεί AI.
Είναι ένα κέλυφος γύρω από το API μιας άλλης εταιρείας.
Και αυτή είναι η AI Trap.
Αν τα δεδομένα, οι καταστάσεις και οι κανόνες παραμένουν μέσα στο προϊόν, η απώλεια του AI αφαιρεί την έξυπνη βοήθεια. Αν όλα υπάρχουν μόνο μέσα στο prompt, η απώλεια του AI αφαιρεί το ίδιο το προϊόν.
Όταν χρησιμοποιούμε έναν εξωτερικό AI provider, δεν αγοράζουμε το μοντέλο.
Νοικιάζουμε προσωρινά την πρόσβαση στη συμπεριφορά του.
Δεν ελέγχουμε:
Ακόμη και όταν η νέα έκδοση είναι τεχνικά καλύτερη, μπορεί να μην είναι λειτουργικά ίδια.
Μπορεί να ακολουθεί διαφορετικά τις οδηγίες.
Μπορεί να παράγει διαφορετικό JSON.
Μπορεί να χρησιμοποιεί περισσότερα tokens για το ίδιο αποτέλεσμα.
Μπορεί να είναι αυστηρότερη σε συγκεκριμένα αιτήματα.
Μπορεί να αλλάζει τον τρόπο με τον οποίο καλεί εργαλεία.
Μπορεί να χρειάζεται διαφορετικά prompts.
Μπορεί να καταστρέψει μία αυτοματοποίηση που λειτουργούσε άψογα με το προηγούμενο μοντέλο.
Όταν λοιπόν μια επιχείρηση γράφει ολόκληρη τη λειτουργία της γύρω από ένα συγκεκριμένο μοντέλο, δεν αποκτά απλώς μία τεχνολογική εξάρτηση.
Κληρονομεί και όλα τα επιχειρηματικά ρίσκα της εταιρείας που βρίσκεται πίσω από το μοντέλο.
Κληρονομεί:
Η επιχείρηση μπορεί να είναι οικονομικά υγιής.
Το προϊόν της μπορεί να έχει πραγματικούς πελάτες.
Οι διαδικασίες της μπορεί να λειτουργούν σωστά.
Και παρ’ όλα αυτά να βρεθεί ξαφνικά σε κίνδυνο, επειδή άλλαξε μία τιμή σε έναν ξένο τιμοκατάλογο.
Όταν μία επιχείρηση ξεκινήσει να χρησιμοποιεί AI, το αρχικό κόστος μπορεί να φαίνεται αμελητέο.
Δέκα ευρώ.
Εκατό ευρώ.
Πεντακόσια ευρώ.
Η χρήση αυξάνεται σταδιακά.
Οι εργαζόμενοι συνηθίζουν το σύστημα.
Οι διαδικασίες σχεδιάζονται γύρω του.
Τα δεδομένα αρχίζουν να παίρνουν τη μορφή που καταλαβαίνει το συγκεκριμένο μοντέλο.
Τα prompts μετατρέπονται σε επιχειρησιακή λογική.
Τα αποτελέσματα του AI περνούν αυτόματα στο επόμενο στάδιο.
Κάποια στιγμή η εταιρεία διαπιστώνει ότι δεν μπορεί απλώς να κλείσει το API.
Δεν μπορεί να επιστρέψει στην προηγούμενη διαδικασία, επειδή η προηγούμενη διαδικασία καταργήθηκε.
Δεν μπορεί να αλλάξει provider εύκολα, επειδή οι απαντήσεις, τα εργαλεία, τα schemas και η συμπεριφορά του νέου μοντέλου είναι διαφορετικά.
Δεν μπορεί να λειτουργήσει χειροκίνητα, επειδή κανένας εργαζόμενος δεν εκπαιδεύτηκε για να εκτελεί πια τη διαδικασία χωρίς AI.
Από εκείνη τη στιγμή, η εταιρεία δεν διαπραγματεύεται πραγματικά την τιμή.
Απλώς πληρώνει.
Η ακριβότερη τεχνολογία δεν είναι εκείνη που κοστίζει πολλά χρήματα.
Είναι εκείνη που δεν μπορείς πλέον να αφαιρέσεις.
Δεν είναι κάθε χρήση AI επικίνδυνη.
Η εξάρτηση δημιουργείται σταδιακά.
Το AI διορθώνει ένα κείμενο ή προτείνει μία ιδέα.
Αν σταματήσει, η εργασία συνεχίζεται κανονικά.
Το AI δημιουργεί περιλήψεις, κατηγοριοποιήσεις ή πρώτα προσχέδια.
Αν σταματήσει, η εργασία γίνεται πιο αργή, αλλά συνεχίζεται.
Το AI εκτελεί μέρος της καθημερινής ροής.
Αν σταματήσει, χρειάζεται χειροκίνητη διαδικασία ή προσωρινή αναμονή.
Το AI είναι απαραίτητο για να ολοκληρωθεί μία βασική υπηρεσία.
Αν σταματήσει, σταματά και ένα τμήμα της επιχείρησης.
Το προϊόν δεν έχει καμία ουσιαστική λειτουργία χωρίς το AI.
Αν ο provider κλείσει την πρόσβαση, η επιχείρηση παύει να έχει προϊόν.
Οι περισσότερες επιχειρήσεις δεν θα φτάσουν στο πέμπτο επίπεδο επειδή το αποφάσισαν.
Θα φτάσουν επειδή πρόσθεσαν μία μικρή, βολική λειτουργία κάθε φορά.
Η σωστή ερώτηση λοιπόν δεν είναι:
«Πώς θα βάλουμε περισσότερο AI στην πλατφόρμα;»
Η σωστή ερώτηση είναι:
«Πόσο AI μπορούμε να αφαιρέσουμε χωρίς να σταματήσει να λειτουργεί η πλατφόρμα;»
Αυτή η ερώτηση αλλάζει ολόκληρη την αρχιτεκτονική.
Τα δεδομένα πρέπει να ανήκουν στην επιχείρηση.
Οι βασικές διαδικασίες πρέπει να είναι καταγεγραμμένες.
Οι καταστάσεις πρέπει να αποθηκεύονται με σαφή τρόπο.
Οι επιχειρησιακοί κανόνες δεν πρέπει να υπάρχουν μόνο μέσα σε ένα prompt.
Τα αποτελέσματα του AI πρέπει να μπορούν να ελεγχθούν.
Οι κρίσιμες αποφάσεις πρέπει να αφήνουν ίχνος.
Τα δεδομένα πρέπει να μπορούν να εξαχθούν.
Ο provider πρέπει να μπορεί να αντικατασταθεί.
Και η βασική λειτουργία πρέπει να μπορεί να συνεχιστεί ακόμη και όταν το AI είναι προσωρινά απενεργοποιημένο.
Το AI μπορεί να βελτιώνει τη διαδρομή.
Δεν πρέπει να είναι η μοναδική διαδρομή.
Μπορεί να διαβάζει τα δεδομένα.
Δεν πρέπει να είναι ο μοναδικός κάτοχος της σημασίας τους.
Μπορεί να προτείνει μία απόφαση.
Δεν πρέπει να είναι το μοναδικό σημείο στο οποίο υπάρχει η λογική της απόφασης.
Μπορεί να δημιουργεί το επόμενο βήμα.
Δεν πρέπει να εξαφανίζεται ολόκληρη η διαδικασία όταν δεν μπορεί να το δημιουργήσει.
Αυτή τη στιγμή βρισκόμαστε σε μία μοναδική περίοδο.
Τα μοντέλα βελτιώνονται με τεράστια ταχύτητα.
Ο ανταγωνισμός πιέζει τις τιμές.
Οι εταιρείες προσφέρουν μεγάλες δυνατότητες με σχετικά χαμηλές συνδρομές.
Νέα εργαλεία εμφανίζονται σχεδόν καθημερινά.
Αυτή είναι μία τεράστια ευκαιρία.
Μπορούμε να χρησιμοποιήσουμε το AI για να:
Αλλά πρέπει να χρησιμοποιήσουμε αυτή την περίοδο για να αποκτήσουμε δική μας υποδομή.
Όχι για να αντικαταστήσουμε τη δική μας υποδομή με μία μόνιμη σύνδεση σε έναν provider.
Αυτό είναι το παράδοξο.
Πρέπει να χρησιμοποιήσουμε όσο περισσότερο AI μπορούμε για να χτίσουμε ένα σύστημα που δεν θα χρειάζεται πάντα τόσο πολύ AI.
Πρέπει να αξιοποιήσουμε τη σημερινή, σχετικά φθηνή και εξαιρετικά ισχυρή νοημοσύνη για να δημιουργήσουμε:
Το AI πρέπει να μας βοηθήσει να γίνουμε δυνατότεροι.
Όχι περισσότερο εξαρτημένοι.
Υπάρχει μία πολύ απλή δοκιμή που μπορεί να κάνει κάθε επιχείρηση.
Πήγαινε στον κεντρικό διακόπτη του AI.
Κλείσ’ τον.
Τι παραμένει;
Μπορεί ο πελάτης να συνδεθεί;
Μπορεί να δει τα δεδομένα του;
Μπορεί να δημιουργήσει μία εργασία;
Μπορεί να ολοκληρώσει μία αγορά;
Μπορεί να στείλει ένα αίτημα;
Μπορεί ο εργαζόμενος να συνεχίσει τη δουλειά του;
Υπάρχουν τα δεδομένα σε κατανοητή μορφή;
Υπάρχει χειροκίνητη διαδικασία;
Υπάρχει άλλος provider;
Υπάρχει ασφαλής υποβάθμιση της υπηρεσίας;
Ή μήπως μένει μόνο μία λευκή οθόνη που γράφει:
«AI provider unavailable»;
Αν με το κλείσιμο του AI σταματά ολόκληρη η επιχείρηση, τότε η επιχείρηση δεν χρησιμοποιεί AI.
Το AI χρησιμοποιεί την επιχείρηση ως σημείο μεταπώλησης των δικών του υπηρεσιών.
Το AI δεν αποτελεί από μόνο του κίνδυνο.
Ο κίνδυνος εμφανίζεται όταν αντικαθιστούμε:
τη δομή με ένα prompt, τη γνώση με μία συνομιλία, τη διαδικασία με έναν agent, την τεκμηρίωση με το context, την ευθύνη με μία αυτόματη απόφαση, και το προϊόν με μία σύνδεση API.
Τότε δεν έχουμε δημιουργήσει μία νέα επιχείρηση.
Έχουμε δημιουργήσει ένα εξάρτημα της επιχείρησης κάποιου άλλου.
Το AI πρέπει να μπορεί να επιταχύνει την πλατφόρμα.
Να τη βελτιώσει.
Να τη βοηθήσει να καταλάβει περισσότερα.
Να προσφέρει καλύτερη εμπειρία.
Να μειώσει τον χρόνο.
Να αυξήσει την ποιότητα.
Αλλά όταν το AI απενεργοποιηθεί, η πλατφόρμα πρέπει να παραμένει ζωντανή.
Πιο αργή, ίσως.
Λιγότερο έξυπνη.
Λιγότερο εντυπωσιακή.
Αλλά λειτουργική.
Αυτό είναι το σημείο στο οποίο μία εφαρμογή σταματά να είναι ένα εντυπωσιακό AI demo και μετατρέπεται σε πραγματική υποδομή.
Στην επόμενη καρτέλα θα δούμε πώς σχεδιάζεται ένα τέτοιο σύστημα.
Ένα σύστημα που μπορεί να χρησιμοποιεί πολλούς providers, αλλά δεν ανήκει σε κανέναν από αυτούς.
Ένα σύστημα που εκμεταλλεύεται πλήρως το AI, αλλά δεν καταρρέει χωρίς αυτό.
Ένα σύστημα στο οποίο η απώλεια του AI δεν δημιουργεί ολοκληρωτική αστοχία.
Δημιουργεί μόνο ελεγχόμενη υποβάθμιση.
Το σύστημα αυτό ονομάζεται:
Και ξεκινά από μία μόνο αρχή: Μην χτίσεις μία επιχείρηση που χρειάζεται AI για να υπάρχει. Χτίσε μία επιχείρηση που λειτουργεί χωρίς αυτό — και γίνεται ασύγκριτα καλύτερη όταν το έχει.
Η πλατφόρμα πριν, μετά και ανεξάρτητα από οποιοδήποτε AI
Γιατί το Academy250 έχει import, export και JSON παντού, γιατί δεν χτίστηκε ως AI wrapper και γιατί η ελευθερία εξόδου είναι σημαντικότερη από ένα ακόμη μαγικό κουμπί.
Δεν κράτησα το AI έξω από τον πυρήνα επειδή δεν πιστεύω σε αυτό. Το κράτησα έξω επειδή πιστεύω αρκετά στη δύναμή του ώστε να μη θέλω να κλειδώσω τον χρήστη, το project και ολόκληρο το οικονομικό μοντέλο της πλατφόρμας πάνω στις αποφάσεις ενός μόνο provider.
Στην πρώτη καρτέλα είδαμε γιατί ο κόσμος χρειάζεται τόσο πολύ AI.
Στη δεύτερη είδαμε την παγίδα που δημιουργείται όταν μία επιχείρηση εξαρτήσει ολόκληρη τη λειτουργία της από ένα μοντέλο, ένα API ή έναν συγκεκριμένο πάροχο.
Τώρα έρχεται η αναπόφευκτη ερώτηση:
Αν το AI είναι τόσο χρήσιμο, γιατί το Academy250 δεν το έχει βάλει κατευθείαν στον πυρήνα του;
Γιατί υπάρχουν παντού αρχεία JSON;
Γιατί υπάρχουν import και export;
Γιατί ο χρήστης πρέπει να μπορεί να πάρει το project του, να το μεταφέρει σε ένα εξωτερικό AI και στη συνέχεια να φέρει πίσω το αποτέλεσμα;
Η απάντηση είναι απλή.
Δεν το έκανα επειδή δεν πιστεύω στο AI.
Το έκανα επειδή πιστεύω αρκετά στο AI ώστε να μη θέλω να κλειδώσω τον χρήστη, την πλατφόρμα και ολόκληρο το οικονομικό της μοντέλο πάνω σε έναν συγκεκριμένο πάροχο.
Δεν θέλω μία εφαρμογή που παίρνει ένα ξένο API, τοποθετεί από πάνω ένα όμορφο περιβάλλον και στη συνέχεια εξαρτάται πλήρως από το τι θα αποφασίσει αύριο μία άλλη εταιρεία.
Όταν χτίζεις ολόκληρο το προϊόν σου πάνω σε ένα συγκεκριμένο μοντέλο, δεν κληρονομείς μόνο τις δυνατότητές του.
Κληρονομείς και όλα τα προβλήματά του.
Αν η πρόσβαση επιτρέπεται μόνο σε συγκεκριμένες χώρες, λογαριασμούς ή επαγγελματικά πλάνα, ξαφνικά το δικό σου προϊόν αποκτά πρόβλημα χωρίς να έχεις κάνει εσύ κανένα λάθος.
Αν το μοντέλο αρχίσει να παράγει διαφορετικό JSON, αλλάζει και η εφαρμογή σου.
Αν το API σταματήσει να υποστηρίζει μία λειτουργία, σταματά και το δικό σου feature.
Αν αλλάξει το κόστος, αλλάζει ολόκληρο το οικονομικό μοντέλο της επιχείρησής σου.
Αυτό δεν είναι σταθερή αρχιτεκτονική. Είναι εξάρτηση.
Και εγώ δεν θέλω να χτίσω το Academy250 πάνω στην εξάρτηση.
Θέλω να το χτίσω πάνω στην ανεξαρτησία.
Η σημαντικότερη αρχή της πλατφόρμας είναι ότι το project ανήκει στον άνθρωπο που το δημιουργεί.
Δεν ανήκει στο Academy250.
Δεν ανήκει στο ChatGPT.
Δεν ανήκει στο Claude, στο Gemini, στο Grok ή σε οποιοδήποτε άλλο μοντέλο.
Δεν ανήκει στον πάροχο του API.
Δεν πρέπει να είναι εγκλωβισμένο μέσα σε μία συνομιλία, σε έναν λογαριασμό ή σε ένα ιδιωτικό format που αύριο μπορεί να πάψει να υποστηρίζεται.
Να μεταφερθεί. Να εξαχθεί. Να διαβαστεί. Να επεξεργαστεί. Να εμπλουτιστεί. Και να επιστρέψει ξανά στην πλατφόρμα χωρίς να χάσει τη δομή του.
Γι’ αυτό υπάρχουν import και export παντού.
Όχι επειδή αποτελούν μία τεχνική εμμονή.
Όχι επειδή θέλω να δυσκολέψω τον χρήστη.
Όχι επειδή δεν μπορώ να συνδέσω ένα AI API μέσα στην πλατφόρμα.
Αλλά επειδή θέλω ο χρήστης να έχει πραγματική ελευθερία.
Ένα project που δεν μπορεί να φύγει από το σύστημα δεν είναι πραγματικά δικό σου.
Ο χρήστης πρέπει να μπορεί να πάρει το project του και να το μεταφέρει στο εργαλείο που θεωρεί καλύτερο για τη συγκεκριμένη εργασία.
Ο χρήστης μπορεί να έχει πρόσβαση σε ένα μοντέλο δυνατότερο, εξειδικευμένο ή καταλληλότερο από οποιοδήποτε μοντέλο θα μπορούσα εγώ να ενσωματώσω στην πλατφόρμα.
Μπορεί να έχει δικό του local cluster.
Μπορεί να εργάζεται μέσα σε κλειστή εταιρική υποδομή.
Μπορεί να χρησιμοποιεί ένα ερευνητικό εργαλείο που δεν είναι διαθέσιμο στη δημόσια αγορά.
Μπορεί να έχει πρόσβαση σε υπολογιστική ισχύ που εγώ δεν μπορώ ούτε να προβλέψω.
Γιατί να τον περιορίσω;
Γιατί να αποφασίσω εγώ ποια νοημοσύνη δικαιούται να χρησιμοποιήσει;
Γιατί να τον κατεβάσω στο επίπεδο του provider που επέλεξα εγώ;
Δεν είναι αυτός ο ρόλος της πλατφόρμας.
Ο ρόλος της πλατφόρμας είναι να του δώσει μία καθαρή δομή ώστε να μπορεί να πάρει το αποτέλεσμα από οποιοδήποτε AI και να το μετατρέψει σε πραγματική εκτέλεση.
Το Academy250 δεν προσπαθεί να αντικαταστήσει το AI.
Προσπαθεί να οργανώσει τη σχέση του ανθρώπου με αυτό.
Ο χρήστης δημιουργεί δομή, καταγράφει τον στόχο, οργανώνει το υλικό, ξεχωρίζει δεδομένα από υποθέσεις και ορίζει όρια, budget και διαθέσιμα μέσα.
Το πρόβλημα αποκτά σχήμα.
Η απάντηση επιστρέφει ως tasks, αποφάσεις, plans, Logbook entries, Whiteboard objects, budget lines, έγγραφα και πραγματική εργασία.
Η απάντηση γίνεται σύστημα.
Ο χρήστης δεν μπαίνει στην πλατφόρμα για να πατήσει ένα μαγικό κουμπί και να περιμένει την τέλεια απάντηση.
Μπαίνει για να δημιουργήσει δομή.
Να στήσει ένα project.
Να οργανώσει το υλικό του.
Να καταγράψει τον στόχο.
Να ξεχωρίσει τα δεδομένα από τις υποθέσεις.
Να ορίσει τα όρια, τα διαθέσιμα μέσα, το budget και τις πραγματικές του ανάγκες.
Στη συνέχεια μπορεί να πάρει αυτή τη δομή και να τη μεταφέρει σε οποιοδήποτε AI.
Το AI μπορεί να αναλύσει, να προτείνει, να επεκτείνει, να εντοπίσει κενά, να δημιουργήσει επιλογές, να οργανώσει βήματα και να παράγει κώδικα, κείμενο, σχέδια, διαδικασίες ή νέες ιδέες.
Το αποτέλεσμα όμως δεν πρέπει να παραμείνει μέσα σε μία συνομιλία.
Σε JSON. Σε tasks. Σε αποφάσεις. Σε project plans. Σε entries του Logbook. Σε αντικείμενα του Whiteboard. Σε budget lines. Σε έγγραφα. Σε εκδόσεις. Σε πραγματική εργασία.
Ένα AI μπορεί να σου δώσει μία εξαιρετική απάντηση.
Μπορεί να σου γράψει δέκα σελίδες.
Να σου δώσει πενήντα ιδέες.
Να δημιουργήσει εκατό βήματα.
Να παρουσιάσει εναλλακτικές, κινδύνους, παραδοχές, προτάσεις και πιθανά σενάρια.
Και μετά;
Τι έχει ήδη ολοκληρωθεί;
Ποια απόφαση άλλαξε και για ποιον λόγο;
Τι πρέπει να μπει στο Whiteboard;
Τι πρέπει να καταγραφεί στο Notebook;
Τι πρέπει να περάσει στο Logbook;
Τι πρέπει να γίνει πραγματική εργασία;
Λείπει η διαχείριση της κατάστασης που δημιουργείται μετά την απάντηση. Το AI παράγει υλικό. Το project χρειάζεται μνήμη, εκδόσεις, ιδιοκτησία, αποφάσεις, evidence και καθαρή εικόνα του τι έγινε και τι απομένει.
Μία συνομιλία δεν είναι project management. Μία απάντηση δεν είναι εκτέλεση. Ένα prompt δεν είναι επιχειρησιακή διαδικασία. Και ένα chatbot δεν είναι λειτουργικό σύστημα.
Το JSON δεν είναι ο πρωταγωνιστής.
Είναι η γέφυρα.
Είναι μία καθαρή, δομημένη και φορητή μορφή με την οποία μία πληροφορία μπορεί να μετακινηθεί από σύστημα σε σύστημα χωρίς να χάσει τη σημασία της.
Ένα απλό κείμενο μπορεί να είναι εξαιρετικό για τον άνθρωπο.
Δεν είναι όμως πάντα αρκετό για ένα εργαλείο.
Το JSON επιτρέπει στο αποτέλεσμα να επιστρέψει οργανωμένο.
Όχι ως μία ακόμη τεράστια απάντηση που πρέπει να αντιγράψει και να ξεχωρίσει ο χρήστης με το χέρι.
Αλλά ως πραγματικό υλικό που μπορεί να μπει ξανά μέσα στο σύστημα.
Ο χρήστης πρέπει να διαβάσει, να αντιγράψει, να ξεχωρίσει και να ξαναπεράσει χειροκίνητα κάθε σημείο στα εργαλεία του.
Πολύ υλικό. Καμία κατάσταση.
Ένα task ως task, ένα budget item ως budget item, ένα ρίσκο ως ρίσκο, ένα milestone ως milestone και μία απόφαση ως απόφαση.
Η απάντηση γίνεται εισαγώγιμη.
Ένα πλήρες project μπορεί να επιστρέψει ως δομή που εισάγεται, τροποποιείται και εκτελείται.
Το JSON δεν υπάρχει επειδή η πλατφόρμα αγαπά τα αρχεία. Υπάρχει επειδή τα δεδομένα πρέπει να έχουν σχήμα.
Και όταν τα δεδομένα έχουν σχήμα, μπορούν να μετακινηθούν χωρίς να φυλακιστούν.
Ένα project που μπορεί να εξαχθεί είναι ένα project που μπορεί να επιβιώσει.
Μπορεί να φύγει από μία πλατφόρμα.
Να μεταφερθεί σε άλλη.
Να αναλυθεί από διαφορετικά μοντέλα.
Να αρχειοθετηθεί τοπικά.
Να αποθηκευτεί στην υποδομή μιας επιχείρησης.
Να συνεχίσει να υπάρχει ακόμη και αν ένα εξωτερικό εργαλείο σταματήσει να λειτουργεί.
Αντίθετα, ένα project που υπάρχει μόνο μέσα σε ένα κλειστό περιβάλλον δεν είναι πραγματικά φορητό.
Ο χρήστης μπορεί να το βλέπει.
Μπορεί να το χρησιμοποιεί.
Αλλά δεν έχει πλήρη έλεγχο επάνω του.
Αυτό είναι ένα από τα πιο σημαντικά προβλήματα των σύγχρονων ψηφιακών εργαλείων.
Ο χρήστης νομίζει ότι έχει δημιουργήσει κάτι δικό του.
Στην πραγματικότητα έχει αποκτήσει προσωρινή πρόσβαση σε κάτι που υπάρχει μέσα σε έναν λογαριασμό άλλης εταιρείας.
Αν χαθεί ο λογαριασμός, αλλάξουν οι όροι ή κλείσει η υπηρεσία, μπορεί να χαθεί και η πρόσβαση στο ίδιο του το έργο.
Δίνουν στον χρήστη έξοδο. Και ένα σύστημα που έχει πραγματική έξοδο δεν είναι φυλακή.
Σήμερα το καλύτερο μοντέλο μπορεί να είναι ένα.
Αύριο μπορεί να είναι ένα άλλο.
Μία εργασία μπορεί να γίνεται καλύτερα από ένα μεγάλο frontier model.
Μία άλλη από ένα μικρό local model.
Μία άλλη από ένα εργαλείο εξειδικευμένο στον κώδικα.
Μία άλλη από ένα μοντέλο για εικόνες, ήχο, video ή επιστημονικά δεδομένα.
Δεν υπάρχει λόγος μία πλατφόρμα project management και εκτέλεσης να προσπαθεί να προβλέψει ποιο μοντέλο θα κερδίσει.
Ούτε υπάρχει λόγος να περιμένει ο χρήστης κάθε φορά από την πλατφόρμα να ενσωματώσει το νέο εργαλείο που εμφανίστηκε.
Η πλατφόρμα δεν πρέπει να γνωρίζει ποιο AI χρησιμοποιήθηκε.
Πρέπει να γνωρίζει μόνο αν το αποτέλεσμα έχει τη σωστή δομή για να επιστρέψει στο project.
Ο provider μπορεί να αλλάζει. Το API μπορεί να αλλάζει. Η τιμή μπορεί να αλλάζει. Το project, τα δεδομένα, οι αποφάσεις και η ροή εκτέλεσης πρέπει να παραμένουν σταθερά και αναγνώσιμα.
Η εύκολη υπόσχεση της εποχής μας είναι η εξής:
Πάτησε ένα κουμπί και το AI θα τα κάνει όλα.
Είναι μία εξαιρετική υπόσχεση για διαφήμιση.
Είναι μία επικίνδυνη υπόσχεση για πραγματική εργασία.
Γιατί ακόμη και όταν το AI παράγει μία σωστή απάντηση, κάποιος πρέπει να αναλάβει να την εφαρμόσει.
Να την ελέγξει.
Να τη χωρίσει σε βήματα.
Να τη συνδέσει με πραγματικούς ανθρώπους, πραγματικό χρόνο, πραγματικό κόστος και πραγματικούς περιορισμούς.
Δεν είναι το prompt. Είναι το σύστημα που κρατά το prompt, την απάντηση, τα δεδομένα, τις αποφάσεις, τις εκδόσεις, τα tasks, το budget, τα evidence και το τελικό αποτέλεσμα μέσα σε μία οργανωμένη ροή.
Αυτό είναι το σημείο στο οποίο μία ιδέα παύει να είναι συζήτηση και γίνεται project.
Και αυτό είναι το σημείο στο οποίο ένα project παύει να είναι πρόθεση και γίνεται πραγματική εργασία.
Ένα AI wrapper συνήθως λειτουργεί ως εξής:
Παίρνει ένα API.
Προσθέτει ένα συγκεκριμένο prompt.
Δημιουργεί ένα όμορφο interface.
Και πουλά την απάντηση με διαφορετικό όνομα.
Αν αφαιρεθεί ο provider, πολλές φορές δεν παραμένει σχεδόν τίποτα.
Η εφαρμογή, το feature και η αξία υπάρχουν μόνο όσο απαντά ο εξωτερικός provider.
Κλείσε το API. Τελείωσε το προϊόν.
Τα δεδομένα, τα tasks, το budget, το Notebook, το Logbook και το Whiteboard λειτουργούν ακόμη και χωρίς συνδεδεμένο AI.
Το AI προστίθεται γύρω από τη λειτουργία.
Το Academy250 έχει σχεδιαστεί ανάποδα.
Η πλατφόρμα πρέπει να μπορεί να λειτουργεί ακόμη και όταν κανένα AI δεν είναι συνδεδεμένο.
Το AI προστίθεται γύρω από αυτή τη λειτουργία.
Δεν την αντικαθιστά.
Μπορεί να επιταχύνει την προετοιμασία.
Να ενισχύσει την ανάλυση.
Να δημιουργήσει νέες επιλογές.
Να βελτιώσει τη δομή.
Να βοηθήσει στη μετατροπή των δεδομένων.
Αλλά δεν αποτελεί προϋπόθεση για να υπάρχει το project.
Η πλατφόρμα μπορεί να γίνει λιγότερο γρήγορη, λιγότερο αυτόματη και ίσως λιγότερο εντυπωσιακή. Αλλά πρέπει να συνεχίσει να λειτουργεί. Αυτό δεν είναι έλλειψη AI. Είναι ανθεκτική αρχιτεκτονική.
Όταν συζητούσα με επενδυτές και υποψήφιους συνεργάτες για το πώς θα μπορούσε να αναπτυχθεί η πλατφόρμα, υπήρχε ένα σημείο που πολεμήθηκε περισσότερο από όλα.
Η εμμονή μου στο import και export.
Η απόφασή μου να μη μετατρέψω το Academy250 σε ακόμη ένα AI wrapper.
Η απόφασή μου να μη δημιουργήσω ένα προϊόν που θα κλειδώνει τον χρήστη μέσα σε ένα συγκεκριμένο μοντέλο και στη συνέχεια θα χρεώνει την πρόσβαση στα tokens.
Για κάποιους αυτό δεν έβγαζε νόημα.
Δεν χωρούσε εύκολα στο γνώριμο επιχειρηματικό μοντέλο.
Δεν μπορούσες να πεις απλώς: «Έχουμε το καλύτερο AI.»
Δεν μπορούσες να παρουσιάσεις ένα μαγικό κουμπί.
Δεν μπορούσες να δημιουργήσεις τεχνητό κλείδωμα και στη συνέχεια να το μετατρέψεις σε επαναλαμβανόμενο έσοδο.
Ίσως αυτή η επιλογή να μου έκλεισε πόρτες.
Ίσως να μου στέρησε υποδομές, χρηματοδότηση ή συνεργασίες που θα είχα αποκτήσει αν είχα δεχτεί να χωρέσω στο μοντέλο που ήθελαν οι άλλοι.
Σήμερα δεν χρειάζεται να περιμένω ποιο μοντέλο θα παραμείνει διαθέσιμο, να φοβάμαι κάθε αλλαγή τιμής ή να αναγκάζω τον χρήστη να χρησιμοποιήσει το AI που επέλεξα εγώ.
Δεν χρειάζεται να μετατρέπω κάθε νέα λειτουργία σε επιπλέον κατανάλωση ενός ξένου API.
Μπορώ να του πω κάτι πολύ πιο απλό:
Χρησιμοποίησε όποιο AI θέλεις. Πάρε το project σου. Πήγαινέ το εκεί όπου θεωρείς ότι θα πάρεις την καλύτερη απάντηση. Και έπειτα φέρε πίσω τη δομή.
Το Academy250 θα σε βοηθήσει να τη μετατρέψεις σε εκτέλεση.
Δεν ήθελα μόνο να παραμείνω εγώ ανεξάρτητος από έναν provider.
Ήθελα την ίδια ελευθερία για κάθε άνθρωπο που θα χρησιμοποιεί την πλατφόρμα.
Το project τους δεν πρέπει να ανήκει σε κανένα AI.
Δεν πρέπει να ανήκει σε κανένα API.
Δεν πρέπει να ανήκει σε κανέναν πάροχο.
Πρέπει να ανήκει στους ίδιους.
Και αν κάποτε αποφασίσουν ότι δεν θέλουν να χρησιμοποιούν πια το Academy250, πρέπει να μπορούν να πάρουν τη δουλειά τους και να φύγουν.
Αυτό μπορεί να ακούγεται παράξενο ως επιχειρηματική επιλογή.
Οι περισσότερες πλατφόρμες προσπαθούν να κάνουν την έξοδο δύσκολη.
Εγώ θέλω να κάνω την παραμονή χρήσιμη.
Δεν θέλω ο χρήστης να μένει επειδή είναι φυλακισμένος.
Θέλω να μένει επειδή η πλατφόρμα τον βοηθά πραγματικά να οργανώνει και να εκτελεί καλύτερα τη δουλειά του.
Η δυνατότητα να φύγει ο χρήστης με ολόκληρο το project του δεν αποδυναμώνει το προϊόν. Αποδεικνύει ότι το προϊόν δεν χρειάζεται να τον κρατήσει αιχμάλωτο για να έχει αξία.
Δεν έφτιαξα μία πλατφόρμα που λέει:
Έλα εδώ επειδή έχουμε το καλύτερο AI.
Έφτιαξα μία πλατφόρμα που λέει:
Εμείς θα σε βοηθήσουμε να προετοιμάσεις σωστά το project, να φέρεις πίσω το αποτέλεσμα και να το μετατρέψεις σε πραγματική εργασία.
Αυτό είναι πιο ανοιχτό.
Πιο τίμιο.
Πιο ασφαλές.
Πιο μακροπρόθεσμο.
Και πιο ανθεκτικό.
Γιατί το καλύτερο μοντέλο σήμερα μπορεί αύριο να μην είναι το καλύτερο.
Η ανάγκη όμως του ανθρώπου να οργανώσει τη σκέψη του, να διαχειριστεί ένα project και να εκτελέσει ένα σχέδιο δεν πρόκειται να εξαφανιστεί.
Το σταθερό σημείο δεν είναι το API, το chatbot ή το μοντέλο. Είναι το project, ο άνθρωπος και η εκτέλεση.
Γι’ αυτό το Academy250 έχει import και export παντού.
Γιατί δεν θέλω να φυλακίσω τον χρήστη μέσα στο δικό μου σύστημα.
Θέλω να του δώσω ένα σύστημα αρκετά δυνατό ώστε να μπορεί να συνεργάζεται με όλα τα υπόλοιπα.
Η πλατφόρμα δεν σχεδιάστηκε για να βρίσκεται μέσα σε ένα συγκεκριμένο AI.
Σχεδιάστηκε για να μπορεί να στέκεται γύρω από οποιοδήποτε AI.
Πριν από αυτό.
Μετά από αυτό.
Και ανεξάρτητα από αυτό.
Αυτό είναι αρχιτεκτονική επιλογή. Αυτό είναι το AI Independence Operating Model.
Και αυτός είναι ο λόγος που το import και το export δεν αποτελούν βοηθητικές λειτουργίες.
Δεν είναι κάτι που προστέθηκε αργότερα για ευκολία.
Δεν είναι ένα τεχνικό feature που κρύβεται στις ρυθμίσεις.
Είναι η καρδιά της αρχιτεκτονικής.
Είναι η εγγύηση ότι το project του χρήστη δεν θα ανήκει ποτέ σε κανένα AI. Θα ανήκει πάντα στον ίδιο.
Το import, το export και το JSON δημιουργούν την έξοδο.
Δεν αρκούν όμως από μόνα τους για να δημιουργήσουν ένα ανθεκτικό σύστημα.
Η πλατφόρμα πρέπει επίσης να γνωρίζει τι θα κάνει όταν μία βιβλιοθήκη δεν φορτώσει.
Όταν ένα API δεν απαντήσει.
Όταν το AI layer σταματήσει.
Όταν το storage καθυστερήσει.
Όταν ένα module πρέπει να μπει σε safe mode.
Όταν η εμπειρία πρέπει να υποβαθμιστεί για να προστατευτούν πρώτα τα δεδομένα.
Εδώ η συζήτηση περνά από την ανεξαρτησία στη συμπεριφορά της αποτυχίας.
Η επόμενη καρτέλα εξηγεί την προσωπική μου διαδρομή από Atmel και PIC στο web, τη σύγκρουσή μου με τον happy path κώδικα και την αρχιτεκτονική που σχεδιάζει από πριν τι θα κάνει όταν η χαρούμενη ημέρα τελειώσει.
Η προσωπική διαδρομή από τα πραγματικά συστήματα στο web
Δεν έμαθα να γράφω πρώτα web code. Έμαθα να γράφω κώδικα που συνδέεται με πραγματικά συστήματα, γνωρίζει ότι κάποτε θα αποτύχει και πρέπει να έχει ήδη αποφασίσει τι θα προστατεύσει.
Στην πρώτη καρτέλα είδαμε γιατί ο κόσμος χρειάζεται τόσο πολύ AI.
Στη δεύτερη είδαμε την παγίδα που δημιουργείται όταν μία επιχείρηση εξαρτά ολόκληρη τη λειτουργία της από μία νοημοσύνη που δεν της ανήκει.
Στην τρίτη είδαμε γιατί επέλεξα να κρατήσω το AI έξω από τον πυρήνα της πλατφόρμας και να χτίσω μία αρχιτεκτονική βασισμένη σε import, export, JSON και φορητά δεδομένα.
Τώρα πρέπει να απαντήσω σε μία ακόμη ερώτηση:
Πώς γράφεις μία πλατφόρμα που μπορεί να χρησιμοποιεί AI, APIs, βιβλιοθήκες και εξωτερικές υπηρεσίες, χωρίς να καταρρέει κάθε φορά που ένα από αυτά σταματά να λειτουργεί;
Για να απαντήσω, πρέπει να επιστρέψω αρκετά χρόνια πίσω.
Γιατί ο τρόπος με τον οποίο έγραψα το Academy250 δεν ξεκίνησε από το web.
Ξεκίνησε από μηχανήματα.
Από μικροεπεξεργαστές.
Από πραγματικά inputs και outputs.
Από συστήματα τα οποία δεν είχαν refresh button.
Είμαι αυτοδίδακτος web developer.
Δεν ξεκίνησα από frameworks, dashboards, component libraries, npm packages και deployment pipelines.
Η βασική μου εκπαίδευση ήταν αλλού.
Ήταν πάνω σε συστήματα που λειτουργούν αυτόνομα, μέσα σε πραγματικές επιχειρησιακές συνθήκες.
Συστήματα που παίρνουν πληροφορίες από αισθητήρες.
Που επεξεργάζονται δεδομένα μέσα σε ελάχιστο χρόνο.
Που ενεργοποιούν εξόδους.
Που κινούν μηχανισμούς.
Που ελέγχουν πραγματικές διαδικασίες.
Που δεν έχουν την πολυτέλεια να κολλήσουν και να περιμένουν τον χρήστη να ξαναδοκιμάσει αργότερα.
Εκεί έμαθα πρώτα.
Πάνω σε Atmel, PIC και μικροεπεξεργαστές με περιορισμένη μνήμη, περιορισμένους πόρους και μηδενική ανοχή στην αφέλεια.
Εκεί δεν γράφεις κώδικα για να δείχνει εντυπωσιακός.
Δεν σε ενδιαφέρει αν το interface είναι μοντέρνο.
Δεν σε ενδιαφέρει αν χρησιμοποιείς την τελευταία βιβλιοθήκη.
Σε ενδιαφέρει να αντέξει.
Και όταν δουλεύεις με τέτοια συστήματα, μαθαίνεις να κάνεις μία ερώτηση που αλλάζει ολόκληρο τον τρόπο με τον οποίο βλέπεις τον κώδικα.
Δεν ρωτάς μόνο:
«Δουλεύει;»
Ρωτάς:
«Τι θα κάνει όταν κάτι σταματήσει να δουλεύει;»
Τι θα γίνει αν χαθεί ένα σήμα;
Τι θα γίνει αν καθυστερήσει ένας αισθητήρας;
Τι θα γίνει αν κοπεί ένα καλώδιο;
Τι θα γίνει αν ένα subsystem δώσει λάθος ένδειξη;
Τι θα γίνει αν η μνήμη δεν φτάνει;
Τι θα γίνει αν το μηχάνημα βρεθεί σε μία κατάσταση που δεν είχες προβλέψει;
Τι θα προστατευτεί πρώτο;
Ποια λειτουργία πρέπει να σταματήσει;
Ποια μπορεί να συνεχίσει;
Ποια είναι η ασφαλής κατάσταση;
Εκεί δεν έχεις την πολυτέλεια να πεις:
«Εντάξει, θα το διορθώσουμε στο επόμενο update.»
Γιατί όταν ο κώδικας συνδέεται με μηχάνημα, κίνηση, ενέργεια, φρένα, αυτονομία ή πραγματική αποστολή, το λάθος δεν είναι απλώς bug.
Είναι συμβάν.
Και αυτό αλλάζει για πάντα τον τρόπο με τον οποίο σκέφτεσαι.
Κάποια στιγμή αποφάσισα ότι είχε έρθει η ώρα να μεταφερθώ από τα επιχειρησιακά μηχανήματα σε κάτι πιο ήρεμο.
Κάτι πιο απλό.
Κάτι πιο low pressure.
Κάτι που δεν θα έπρεπε να παίρνει κρίσιμες αποφάσεις στον πραγματικό κόσμο.
Το web.
Και εκεί ανακάλυψα το χάος.
Όχι επειδή το web είναι άχρηστο.
Όχι επειδή οι web developers δεν γνωρίζουν τη δουλειά τους.
Όχι επειδή θεωρώ ότι όποιος χρησιμοποιεί frameworks ή βιβλιοθήκες κάνει κάτι λάθος.
Ανακάλυψα το χάος επειδή το web είχε αναπτυχθεί μέσα σε ένα εντελώς διαφορετικό οικονομικό και ψυχολογικό περιβάλλον.
Γρήγορα.
Φθηνά.
Με deadlines.
Με founders που πιέζουν.
Με πελάτες που θέλουν να δουν κάτι στην οθόνη.
Με MVPs.
Με demos.
Με investors.
Με παρουσιάσεις.
Με screenshots.
Με τη λογική:
«Βάλ’ το να δουλεύει τώρα και το διορθώνουμε μετά.»
Και αυτό το «μετά» είναι η μεγάλη παγίδα.
Γιατί πολλές φορές δεν έρχεται ποτέ.
Το MVP γίνεται production.
Το προσωρινό workaround γίνεται μόνιμη διαδικασία.
Η βιβλιοθήκη που μπήκε για να κερδίσουμε δύο ημέρες παραμένει μέσα για οκτώ χρόνια.
Το πείραμα αποκτά πελάτες.
Το demo αρχίζει να κρατά πραγματικά δεδομένα.
Και ο κώδικας που γράφτηκε μόνο για την καλή ημέρα καλείται ξαφνικά να λειτουργήσει μέσα στην πραγματικότητα.
Κάπου εκεί άρχισα να χρησιμοποιώ έναν δικό μου όρο.
HappyCode.
HappyCode είναι ο κώδικας που λειτουργεί όταν όλα γύρω του είναι χαρούμενα.
Όταν η βιβλιοθήκη είναι διαθέσιμη.
Όταν το API απαντά.
Όταν το CSS φορτώνει.
Όταν το JavaScript τρέχει.
Όταν ο browser συμπεριφέρεται όπως χθες.
Όταν ο service worker δεν έχει κολλήσει.
Όταν η βάση δεδομένων είναι επάνω.
Όταν το storage απαντά.
Όταν το session είναι ενεργό.
Όταν το hosting λειτουργεί σωστά.
Όταν ο χρήστης ακολουθεί ακριβώς τη διαδρομή που είχαμε φανταστεί.
Όταν κανένας δεν πατά δύο φορές το ίδιο κουμπί.
Όταν κανένα request δεν αργεί.
Όταν κανένα εξωτερικό service δεν αλλάζει συμπεριφορά.
Όταν ολόκληρος ο κόσμος γύρω από τον κώδικα λειτουργεί ιδανικά.
Το HappyCode μπορεί να είναι όμορφο.
Μπορεί να είναι γρήγορο.
Μπορεί να εντυπωσιάζει σε ένα demo.
Μπορεί να περνά όλους τους ελέγχους της καλής διαδρομής.
Αλλά υπάρχει μόνο μέσα σε έναν κόσμο όπου όλα τα υπόλοιπα συμφωνούν να το βοηθήσουν.
Και ο πραγματικός κόσμος δεν υπογράφει ποτέ μια τέτοια συμφωνία.
Το API απαντά, η βάση είναι επάνω, το browser είναι προβλέψιμο και ο χρήστης ακολουθεί ακριβώς το σενάριο.
Δουλεύει όσο ο κόσμος είναι χαρούμενος.
Τα requests καθυστερούν, οι υπηρεσίες αλλάζουν, τα δεδομένα είναι άσχημα και οι εξαρτήσεις αποτυγχάνουν.
Η πραγματικότητα αρχίζει μετά το demo.
Απέναντι στο HappyCode υπάρχει αυτό που εγώ ονομάζω:
FieldCode.
FieldCode είναι ο κώδικας που έχει σχεδιαστεί γνωρίζοντας ότι κάποια στιγμή κάτι θα αποτύχει.
Δεν προσπαθεί να προβλέψει κάθε πιθανό πρόβλημα.
Αυτό είναι αδύνατο.
Προσπαθεί όμως να γνωρίζει πώς θα συμπεριφερθεί όταν πάψει να ισχύει η ιδανική κατάσταση.
Αν δεν απαντήσει το API, τι παραμένει διαθέσιμο;
Αν πέσει η βάση, ποια δεδομένα πρέπει να προστατευτούν;
Αν αποτύχει η εγγραφή, ενημερώνεται ο χρήστης ότι το save δεν ολοκληρώθηκε ή συνεχίζει να εργάζεται μέσα σε μία ψευδαίσθηση;
Αν ένα module δεν φορτώσει, πέφτει ολόκληρη η πλατφόρμα ή απομονώνεται η συγκεκριμένη λειτουργία;
Αν χαθεί το AI layer, συνεχίζει να υπάρχει το project;
Αν το storage καθυστερήσει, υπάρχει queue;
Αν ένα export αποτύχει, μπορεί να επαναληφθεί;
Αν χαλάσει το login, υπάρχει ασφαλής τρόπος ανάκτησης;
Αν ένα subsystem συμπεριφερθεί παράξενα, μπορεί το υπόλοιπο σύστημα να μεταβεί σε read-only κατάσταση;
Αν δεν μπορείς να προστατεύσεις ταυτόχρονα την εμπειρία και τα δεδομένα, ποιο από τα δύο προστατεύεις πρώτο;
FieldCode δεν σημαίνει ότι το σύστημα δεν θα αποτύχει ποτέ.
Σημαίνει ότι η αποτυχία έχει αντιμετωπιστεί ως μέρος της αρχιτεκτονικής.
Δεν εμφανίζεται ως έκπληξη.
Εμφανίζεται ως κατάσταση.
Και κάθε κατάσταση πρέπει να έχει μία προβλέψιμη συμπεριφορά.
Εμφανίζεται ως κατάσταση. Και κάθε κατάσταση πρέπει να έχει μία προβλέψιμη συμπεριφορά.
Στην αρχή προσπάθησα να συνεργαστώ με ανθρώπους που γνώριζαν το web πολύ καλύτερα από εμένα.
Και εκεί διαπίστωσα κάτι που για μένα ήταν σοκαριστικό.
Κάθε φορά που μιλούσα για fail-safe, safe mode, degradation, fallback, read-only λειτουργία, εξωτερικό monitoring, παράλληλο εγκέφαλο και προβλέψιμη αποτυχία, έβλεπα το ίδιο βλέμμα.
Σαν να μιλούσα άλλη γλώσσα.
Σαν να περιέγραφα περιττές πολυπλοκότητες.
Σαν να ζητούσα να χτίσουμε ένα αεροπλάνο, ενώ το μόνο που χρειαζόμασταν ήταν μία web εφαρμογή.
Και μπορώ να καταλάβω γιατί συνέβαινε αυτό.
Η αγορά δεν πληρώνει εύκολα για κάτι που δεν φαίνεται.
Το fallback δεν εμφανίζεται στο screenshot.
Το monitoring δεν εντυπωσιάζει τον επενδυτή.
Το safe mode δεν δημιουργεί ωραίο demo.
Η απομόνωση ενός module δεν φαίνεται όταν όλα λειτουργούν.
Η προστασία των δεδομένων δεν γίνεται αντιληπτή μέχρι τη στιγμή που τα δεδομένα κινδυνεύουν.
Η αντοχή είναι σχεδόν πάντα αόρατη.
Μέχρι να γίνει η ζημιά.
Τότε ξαφνικά γίνεται το σημαντικότερο feature της πλατφόρμας.
Όταν παραδόθηκε η πρώτη λειτουργική έκδοση της πλατφόρμας, έκανα αυτό που για μένα ήταν απολύτως φυσιολογικό.
Δεν πανηγύρισα επειδή άνοιγε η σελίδα.
Δεν είπα:
«Ωραία, δουλεύει.»
Πήγα και της έκοψα κομμάτια.
Έκλεισα δύο ή τρεις βιβλιοθήκες.
Αφαίρεσα resources.
Χάλασα επίτηδες κάποιες εξαρτήσεις.
Έκοψα πράγματα που θεωρούνταν δεδομένα.
Και φυσικά, το σύστημα κατέρρευσε μέσα σε λίγα δευτερόλεπτα.
Τότε άκουσα τις κλασικές απαντήσεις:
«Μα αυτό δεν πρόκειται να συμβεί.»
«Δεν είναι φτιαγμένο για να λειτουργεί έτσι.»
«Γιατί να κόψεις τη βιβλιοθήκη;»
«Γιατί να χαλάσεις κάτι που δουλεύει;»
Και εκεί κατάλαβα ότι το πρόβλημα δεν ήταν τεχνικό.
Δεν διαφωνούσαμε για ένα feature.
Δεν διαφωνούσαμε για το framework.
Δεν διαφωνούσαμε για το αν ένα κουμπί πρέπει να βρίσκεται δεξιά ή αριστερά.
Διαφωνούσαμε στη φιλοσοφία.
Ο άλλος έβλεπε το σύστημα όπως ήταν όταν όλα λειτουργούσαν.
Εγώ το έβλεπα όπως θα γινόταν όταν κάτι σταματούσε να λειτουργεί.
Αυτά είναι δύο διαφορετικά σύμπαντα.
Και κανένα framework δεν μπορεί να γεφυρώσει από μόνο του αυτή τη διαφορά.
Ο άλλος έβλεπε το σύστημα όπως ήταν όταν όλα λειτουργούσαν. Εγώ το έβλεπα όπως θα γινόταν όταν κάτι σταματούσε να λειτουργεί.
Κάπου εκεί κατάλαβα ότι δεν θα έβρισκα εύκολα κάποιον να γράψει την πλατφόρμα όπως ήθελα να γραφτεί.
Όχι επειδή δεν υπάρχουν εξαιρετικοί developers.
Υπάρχουν.
Όχι επειδή θεωρώ ότι είμαι καλύτερος από αυτούς.
Δεν είμαι.
Αλλά επειδή αυτό που ζητούσα δεν ήταν απλώς web development.
Ζητούσα επιχειρησιακή σκέψη μέσα σε web περιβάλλον.
Ζητούσα κώδικα που δεν θα κοιτάζει μόνο το happy path.
Ζητούσα μία πλατφόρμα που θα γνωρίζει τι πρέπει να κάνει όταν της λείψει ένα κομμάτι.
Ζητούσα ένα σύστημα που δεν θα χρειάζεται κάθε φορά τον ιδρυτή να τρέχει πανικόβλητος στον server.
Ζητούσα κώδικα με συνείδηση αποτυχίας.
Και επειδή δεν μπορούσα να αγοράσω εύκολα αυτό που ζητούσα, σταμάτησα να ψάχνω.
Και ξεκίνησα να γράφω.
Δεν ζητούσα απλώς web development. Ζητούσα επιχειρησιακή σκέψη μέσα σε web περιβάλλον και κώδικα με συνείδηση αποτυχίας.
Τους τελευταίους δώδεκα μήνες κάνω ακριβώς αυτό.
Γράφω.
Ξαναγράφω.
Σβήνω.
Ξαναχτίζω.
Πετάω.
Απλοποιώ.
Δοκιμάζω.
Χαλάω.
Ξαναδοκιμάζω.
Οι πρώτοι έξι μήνες ήταν οι δυσκολότεροι.
Η τελευταία σοβαρή προσπάθεια που είχα κάνει να γράψω λειτουργική web πλατφόρμα ήταν περίπου το 2017.
Από τότε μέχρι το 2026 είχαν περάσει σχεδόν εννέα χρόνια.
Πολλά είχαν αλλάξει.
Νέα frameworks.
Νέα εργαλεία.
Νέα build systems.
Νέα deployment μοντέλα.
Νέες frontend φιλοσοφίες.
Νέα επίπεδα αφαίρεσης.
Και ναι, πολλά από αυτά ήταν πραγματική πρόοδος.
Ανακάλυψα όμως και κάτι άλλο.
Πολλά από αυτά δεν τα χρειαζόμουν.
Κάποια ήταν θόρυβος.
Κάποια ήταν μόδα.
Κάποια έλυναν προβλήματα που εγώ δεν ήθελα καν να εισαγάγω στην πλατφόρμα μου.
Κάποια μου έδιναν ταχύτητα στην αρχή, αλλά μου αφαιρούσαν κατανόηση στη συνέχεια.
Κάποια έκρυβαν τόσο πολύ τη λειτουργία του συστήματος, ώστε όταν κάτι αποτύγχανε έπρεπε να περάσω από πολλαπλά επίπεδα μαγείας για να καταλάβω τι είχε συμβεί.
Έτσι, μετά από έναν μεγάλο κύκλο, επέστρεψα σε έναν τρόπο γραφής πιο κοντά σε αυτόν που μπορούσα να εμπιστευτώ.
Απλός κώδικας.
Καθαρή ροή.
Λιγότερη μαγεία.
Περισσότερος έλεγχος.
Επέλεξα απλή PHP.
Όχι επειδή είναι η πιο εντυπωσιακή επιλογή.
Όχι επειδή βρίσκεται στο κέντρο της τεχνολογικής μόδας.
Όχι επειδή θεωρώ ότι είναι η σωστή απάντηση για κάθε πλατφόρμα και κάθε developer.
Την επέλεξα επειδή για τον τρόπο με τον οποίο σκέφτομαι είναι άμεση, καθαρή και προβλέψιμη.
Γράφω κάτι.
Το εκτελώ.
Βλέπω το αποτέλεσμα.
Δεν θέλω για κάθε μικρή αλλαγή να περνάω από compile, build, pipeline, deployment, hydration και πολλαπλά επίπεδα configuration.
Δεν ήθελα η δυνατότητα να καταλάβω το ίδιο μου το σύστημα να εξαρτάται από το αν θυμάμαι πώς λειτουργούν δέκα διαφορετικά εργαλεία.
Ήθελα να παραμένω κοντά στη ροή.
Κοντά στο request.
Κοντά στη βάση.
Κοντά στα δεδομένα.
Κοντά στο σημείο της αποτυχίας.
Η επιλογή δεν ήταν ιδεολογική.
Ήταν επιχειρησιακή.
Δεν αναζητούσα το πιο μοντέρνο.
Αναζητούσα αυτό που μπορούσα να ελέγξω.
Αναζητούσα αυτό που μπορούσα να ελέγξω, να ακολουθήσω και να διορθώσω κοντά στο πραγματικό σημείο της αποτυχίας.
Στη συνέχεια ήρθε το HTMX.
Για μένα έφερε πίσω κάτι από την παλιά αίσθηση του jQuery, αλλά με έναν πιο καθαρό και σύγχρονο τρόπο.
Μου έδωσε τη δυνατότητα να δημιουργήσω interaction χωρίς να μετατρέψω ολόκληρη την πλατφόρμα σε ένα τεράστιο frontend σύστημα, το οποίο θα απαιτούσε τη δική του ανεξάρτητη αρχιτεκτονική, κατάσταση και μηχανισμό συγχρονισμού.
Δεν ήθελα να κατασκευάσω δύο εφαρμογές που προσπαθούν να συμφωνήσουν μεταξύ τους.
Ήθελα ένα σύστημα του οποίου τη ροή μπορούσα να ακολουθήσω από την αρχή μέχρι το τέλος.
Και από κάτω, PostgreSQL.
Μία δυνατή, ώριμη και σοβαρή βάση δεδομένων.
Όχι για να κάνω επίδειξη τεχνολογίας.
Αλλά για να έχω ένα αξιόπιστο σημείο στο οποίο η κατάσταση της πλατφόρμας αποθηκεύεται με σαφήνεια.
PHP.
HTMX.
PostgreSQL.
Δεν είναι η μοναδική σωστή αρχιτεκτονική.
Είναι η αρχιτεκτονική που ταίριαξε στον τρόπο με τον οποίο εγώ ήθελα να σκέφτομαι, να γράφω, να ελέγχω και να διορθώνω το σύστημα.
Μετά ήρθε το δεύτερο κύμα προβλημάτων.
APIs.
Services.
Libraries.
Browser συμπεριφορές.
Dependencies.
Εκδόσεις που βγαίνουν εκτός συγχρονισμού.
Πακέτα που αλλάζουν.
Updates που διορθώνουν ένα πρόβλημα και δημιουργούν τρία νέα.
Συστήματα που επικοινωνούν μεταξύ τους μέχρι τη στιγμή που μία μικρή αλλαγή σπάσει τη συμφωνία.
Και εκεί επέστρεψα στην ίδια απόφαση:
Θα γράψω όσο περισσότερα μπορώ μόνος μου.
Όχι επειδή είναι πάντα γρηγορότερο.
Στην αρχή είναι συνήθως πιο αργό.
Όχι επειδή είναι πάντα ευκολότερο.
Δεν είναι.
Όχι επειδή θεωρώ ότι ο κώδικας που γράφω εγώ είναι αυτομάτως καλύτερος από μία ώριμη βιβλιοθήκη.
Πολλές φορές δεν είναι.
Αλλά όταν το γράφεις εσύ, γνωρίζεις πού πονάει.
Γνωρίζεις τι κάνει.
Γνωρίζεις τι δεν κάνει.
Γνωρίζεις πώς να το κόψεις.
Γνωρίζεις πώς να το απομονώσεις.
Γνωρίζεις πώς να το βάλεις σε safe mode.
Γνωρίζεις πώς να το ξανασηκώσεις.
Και κυρίως, γνωρίζεις να μην του δίνεις περισσότερη εμπιστοσύνη από αυτή που πραγματικά αξίζει.
Εδώ επιστρέφουμε στο AI.
Το AI είναι εξαιρετικό στο να γράφει κώδικα.
Μπορεί να παράγει μέσα σε λίγα δευτερόλεπτα κάτι που παλιότερα θα απαιτούσε ώρες ή ημέρες.
Μπορεί να δημιουργήσει controllers.
Routes.
Database queries.
Components.
APIs.
Scripts.
Schemas.
Automations.
Ολόκληρες μικρές εφαρμογές.
Το πρόβλημα είναι ότι το AI γράφει πολύ εύκολα HappyCode.
Του λες:
«Φτιάξε μου μία λειτουργία που αποθηκεύει ένα project.»
Και τη φτιάχνει.
Υποθέτει ότι η βάση είναι διαθέσιμη.
Υποθέτει ότι το payload είναι σωστό.
Υποθέτει ότι ο χρήστης έχει άδεια.
Υποθέτει ότι το storage λειτουργεί.
Υποθέτει ότι το request δεν θα επαναληφθεί.
Υποθέτει ότι τίποτα δεν θα αποτύχει ανάμεσα στα ενδιάμεσα βήματα.
Υποθέτει ότι το save είτε θα γίνει ολόκληρο είτε δεν θα γίνει καθόλου.
Υποθέτει ότι η απάντηση του API είναι έγκυρη.
Υποθέτει ότι το μοντέλο θα επιστρέψει το JSON που του ζητήσαμε.
Υποθέτει ότι ο κόσμος είναι χαρούμενος.
Αυτό δεν σημαίνει ότι το AI είναι κακός προγραμματιστής.
Σημαίνει ότι απαντά στην ερώτηση που του κάναμε.
Και οι περισσότεροι άνθρωποι ρωτούν μόνο:
«Πώς θα το κάνουμε να δουλέψει;»
Δεν ρωτούν:
«Πώς θα συμπεριφερθεί όταν αρχίσει να μη δουλεύει;»
Το AI μπορεί να γράψει FieldCode.
Αλλά πρέπει πρώτα ο άνθρωπος να γνωρίζει ότι χρειάζεται FieldCode.
Πρέπει να ζητήσει failure states.
Πρέπει να ορίσει fallback.
Πρέπει να αποφασίσει ποια δεδομένα είναι κρίσιμα.
Πρέπει να περιγράψει τη διαδικασία υποβάθμισης.
Πρέπει να απαιτήσει idempotency, validation, isolation, monitoring, rollback και ασφαλείς καταστάσεις.
Το AI μπορεί να σε βοηθήσει να υλοποιήσεις την αρχιτεκτονική.
Δεν μπορεί να σου χαρίσει την αρχιτεκτονική ευθύνη.
Ρώτησε πώς θα συμπεριφερθεί όταν αρχίσει να μη δουλεύει. Το AI μπορεί να γράψει FieldCode, αλλά πρώτα ο άνθρωπος πρέπει να γνωρίζει ότι το χρειάζεται.
Κάπου εκεί ξεκίνησε σοβαρά μέσα στην πλατφόρμα το fail-safe management.
Τι θα γίνει αν χαλάσει το login;
Τι θα γίνει αν χαλάσει το session;
Τι θα γίνει αν πέσει η βάση;
Τι θα γίνει αν δεν μπορεί να ολοκληρωθεί το save;
Τι θα γίνει αν ένα module δεν φορτώσει;
Τι θα γίνει αν το export καθυστερήσει;
Τι θα γίνει αν το AI layer δεν απαντήσει;
Τι θα γίνει αν το storage δεν είναι διαθέσιμο;
Τι θα γίνει αν ο χρήστης βρίσκεται μέσα σε ένα project και μία λειτουργία υποβαθμιστεί;
Τι θα γίνει αν πρέπει να προστατεύσω τα δεδομένα πριν προστατεύσω την εμπειρία;
Εκεί αρχίζει η πραγματική δουλειά.
Όχι στη δημιουργία ενός ακόμη feature.
Αλλά στην απόφαση για το ποια θα είναι η ασφαλής επόμενη κατάσταση όταν το feature δεν μπορεί να λειτουργήσει κανονικά.
Μπορεί να συνεχίσει το υπόλοιπο σύστημα;
Μπορεί η λειτουργία να γίνει read-only;
Μπορούν τα δεδομένα να αποθηκευτούν προσωρινά;
Μπορεί ο χρήστης να εξαγάγει τη δουλειά του;
Μπορεί να ενημερωθεί καθαρά για το τι λειτουργεί και τι όχι;
Μπορεί να συνεχίσει χωρίς AI;
Μπορεί να αλλάξει provider;
Μπορεί να εκτελέσει χειροκίνητα το κρίσιμο βήμα;
Μπορεί να επιστρέψει στην προηγούμενη ασφαλή έκδοση;
Αυτό είναι το σημείο όπου ο κώδικας παύει να είναι απλώς κώδικας.
Γίνεται αρχιτεκτονική συμπεριφοράς.
Γίνεται η απόφαση για το ποια είναι η ασφαλής επόμενη κατάσταση όταν μία λειτουργία δεν μπορεί να συνεχίσει κανονικά.
Ένα από τα μεγαλύτερα λάθη που κάνουμε είναι ότι αντιμετωπίζουμε την αποτυχία σαν ένα ενιαίο πράγμα.
«Δουλεύει» ή «δεν δουλεύει».
Στην πραγματικότητα, ένα σοβαρό σύστημα πρέπει να έχει πολλά επίπεδα λειτουργίας.
Όλα τα υποσυστήματα είναι διαθέσιμα.
Το AI λειτουργεί.
Τα exports λειτουργούν.
Το storage λειτουργεί.
Οι αυτοματισμοί λειτουργούν.
Μία έξυπνη λειτουργία δεν είναι διαθέσιμη, αλλά τα δεδομένα και η βασική εργασία συνεχίζονται.
Οι αυτοματισμοί έχουν σταματήσει, αλλά ο χρήστης μπορεί να ολοκληρώσει τη διαδικασία χειροκίνητα.
Δεν επιτρέπονται νέες αλλαγές, αλλά ο χρήστης μπορεί να διαβάσει και να εξαγάγει τα δεδομένα του.
Διακόπτονται όλες οι μη απαραίτητες λειτουργίες και παραμένουν ενεργά μόνο όσα χρειάζονται για την προστασία και ανάκτηση των δεδομένων.
Αν η πλατφόρμα δεν μπορεί να προσφέρει πλήρη λειτουργία, πρέπει τουλάχιστον να επιτρέψει στον χρήστη να πάρει τη δουλειά του.
Αυτό είναι degradation.
Το σύστημα δεν περνά από τη ζωή στον θάνατο μέσα σε ένα δευτερόλεπτο.
Χάνει σταδιακά δυνατότητες, αλλά προσπαθεί να διατηρήσει τον πυρήνα του.
Για πολλά χρόνια, το web μπορούσε να συγχωρεί την αφέλεια.
Αν κάτι δεν λειτουργούσε, δεν εμφανιζόταν ένα τμήμα του interface.
Χανόταν ένα click.
Έσπαγε μία φόρμα.
Καθυστερούσε μία παραγγελία.
Έπεφτε ένα dashboard.
Ο χρήστης έκανε refresh.
Καθάριζε την cache.
Δοκίμαζε αργότερα.
Και έμενε η εντύπωση:
«Έλα μωρέ, web είναι.»
Αυτό όμως δεν μπορεί να αποτελεί βάση για τις πλατφόρμες της επόμενης ημέρας.
Όταν το web αρχίζει να κρατά πραγματική δουλειά, πραγματικά projects, πραγματικές οικονομικές κινήσεις, πραγματικές αποφάσεις, πραγματικά δεδομένα και πραγματική παραγωγή, παύει να είναι απλώς μία οθόνη.
Γίνεται υποδομή.
Και η υποδομή δεν μπορεί να γράφεται με ψυχολογία demo.
Γίνεται υποδομή. Και η υποδομή δεν μπορεί να γράφεται με ψυχολογία demo.
Το Academy250 είναι το εκπαιδευτικό περιβάλλον.
Εκεί δοκιμάζουμε.
Μαθαίνουμε.
Οργανώνουμε.
Χτίζουμε.
Κάνουμε project-based execution.
Μπορούμε να πειραματιστούμε.
Μπορούμε να αποτύχουμε με ελεγχόμενο τρόπο.
Μπορούμε να ξαναρχίσουμε.
Αλλά πίσω από αυτό υπάρχει κάτι πιο σοβαρό.
Το Logbook OS.
Το παραγωγικό περιβάλλον.
Το περιβάλλον στο οποίο κάποιος δεν θα φέρει απλώς μία ιδέα.
Θα φέρει πραγματικά δεδομένα.
Πραγματικά projects.
Πραγματικές διαδικασίες.
Πραγματική εργασία.
Εκεί αλλάζει η ευθύνη.
Εκεί δεν αρκεί να πεις:
«Δουλεύει όμορφα όταν όλα είναι διαθέσιμα.»
Πρέπει να μπορείς να πεις:
«Γνωρίζω τι θα κάνει όταν κάτι πέσει.»
«Γνωρίζω τι θα προστατεύσει πρώτο.»
«Γνωρίζω πώς θα υποβαθμιστεί.»
«Γνωρίζω πώς θα ενημερώσει τον χρήστη.»
«Γνωρίζω πώς θα κρατήσει τα δεδομένα.»
«Γνωρίζω τι μπορεί να συνεχίσει.»
«Γνωρίζω πώς θα επανέλθει.»
Αυτό είναι το επίπεδο που κυνηγάω.
Δεν λέω ότι το έχω πετύχει εκατό τοις εκατό.
Δεν λέω ότι είμαι ο καλύτερος developer.
Δεν λέω ότι έχω λύσει όλα τα προβλήματα.
Δεν λέω ότι η πλατφόρμα δεν θα παρουσιάσει ποτέ αστοχία.
Αν κάποιος σου πει ότι ένα πραγματικό σύστημα δεν πρόκειται να αποτύχει ποτέ, φύγε μακριά.
Η αποτυχία είναι βέβαιη.
Το μόνο άγνωστο είναι η μορφή και η στιγμή της.
Αυτό που λέω είναι κάτι διαφορετικό.
Λέω ότι προσπαθώ να χτίσω με άλλη λογική.
Με άλλη εκπαίδευση.
Με άλλο φόβο.
Με άλλο σεβασμό στην αποτυχία.
Με άλλη σχέση με τους διαθέσιμους πόρους.
Με άλλη σχέση με τις εξαρτήσεις.
Με άλλη σχέση με τη λέξη «δουλεύει».
Για μένα το «δουλεύει» δεν είναι το τέλος της ερώτησης.
Είναι η αρχή.
Η πραγματική ερώτηση είναι:
«Πώς θα συμπεριφερθεί όταν αρχίσει να μη δουλεύει;»
Το μόνο άγνωστο είναι η μορφή και η στιγμή της. Η δουλειά της αρχιτεκτονικής είναι να ορίσει τι προστατεύεται και πώς συνεχίζει το σύστημα.
Δεν προσπαθώ να φτιάξω απλώς μία ακόμη web πλατφόρμα.
Προσπαθώ να φέρω στο καθημερινό web τη λογική του επιχειρησιακού κώδικα.
Όχι με υπερβολές.
Όχι υποστηρίζοντας ότι μία εκπαιδευτική πλατφόρμα είναι αεροπλάνο.
Δεν είναι.
Όχι υποστηρίζοντας ότι το Academy250 είναι σύστημα ζωής και θανάτου.
Δεν είναι.
Αλλά λέγοντας κάτι πολύ πιο απλό:
Αν ο χρήστης εμπιστευτεί στην πλατφόρμα τη σκέψη του, τα projects του, τα δεδομένα του, τη δουλειά του, το Logbook του, την οργάνωση και την εκτέλεσή του, τότε η πλατφόρμα πρέπει να σεβαστεί αυτή την εμπιστοσύνη.
Και ο σεβασμός δεν φαίνεται μόνο στα όμορφα features.
Φαίνεται στο τι κάνεις όταν κάτι δεν πάει καλά.
Φαίνεται στο αν υπάρχει έξοδος.
Στο αν υπάρχει export.
Στο αν υπάρχει fallback.
Στο αν υπάρχει ασφαλής κατάσταση.
Στο αν προστατεύεις τα δεδομένα πριν προστατεύσεις την εικόνα σου.
Στο αν μπορείς να πεις την αλήθεια στον χρήστη:
«Αυτή η λειτουργία δεν είναι διαθέσιμη αυτή τη στιγμή, αλλά το project σου είναι ασφαλές και μπορείς να συνεχίσεις.»
Φαίνεται στο τι κάνεις όταν κάτι δεν πάει καλά, αν υπάρχει έξοδος, fallback, ασφαλής κατάσταση και ειλικρινής ενημέρωση προς τον χρήστη.
Το HappyCode γράφεται για την ημέρα της παρουσίασης.
Το FieldCode γράφεται για την ημέρα μετά την παρουσίαση.
Το HappyCode αποδεικνύει ότι μία ιδέα μπορεί να λειτουργήσει.
Το FieldCode αποδεικνύει ότι μπορεί να επιβιώσει όταν ο πραγματικός κόσμος αρχίσει να τη δοκιμάζει.
Το HappyCode χρειάζεται έναν χαρούμενο provider.
Το FieldCode γνωρίζει τι θα κάνει όταν ο provider πάψει να είναι χαρούμενος.
Το HappyCode θεωρεί το AI δεδομένο.
Το FieldCode θεωρεί το AI προαιρετική δυνατότητα.
Το HappyCode βλέπει την αποτυχία ως εξαίρεση.
Το FieldCode τη βλέπει ως αναμενόμενη κατάσταση.
Το HappyCode προσπαθεί να κρύψει ότι κάτι έσπασε.
Το FieldCode προσπαθεί να προστατεύσει πρώτα τον χρήστη και τα δεδομένα του.
Το HappyCode εντυπωσιάζει όταν όλα λειτουργούν.
Το FieldCode κερδίζει την εμπιστοσύνη όταν η χαρούμενη ημέρα τελειώσει.
Αυτή είναι η αρχιτεκτονική επιλογή πάνω στην οποία χτίζω την πλατφόρμα.
Όχι επειδή πιστεύω ότι μπορώ να προβλέψω τα πάντα.
Αλλά επειδή γνωρίζω ότι δεν μπορώ.
Όχι επειδή περιμένω να μην αποτύχει ποτέ.
Αλλά επειδή περιμένω ότι κάποια στιγμή θα αποτύχει.
Όχι επειδή φοβάμαι την τεχνολογία.
Αλλά επειδή τη σέβομαι αρκετά ώστε να μη θεωρώ τίποτα δεδομένο.
Από HappyCode γεμίσαμε.
Αυτό που χρειαζόμαστε τώρα είναι περισσότερα συστήματα που μπορούν να αντέξουν όταν η χαρούμενη ημέρα τελειώσει.
Και αυτή είναι η βάση του FieldCode:
Μη γράφεις μόνο τον κώδικα που κάνει το σύστημα να λειτουργεί.
Γράψε και τη συμπεριφορά που θα το κρατήσει ζωντανό όταν ένα κομμάτι του πάψει να λειτουργεί.
Θεωρεί το AI, τον provider, τα APIs και τις dependencies δεδομένα. Βλέπει την αποτυχία ως εξαίρεση.
Εντυπωσιάζει όταν όλα λειτουργούν.
Θεωρεί την αποτυχία αναμενόμενη κατάσταση και προστατεύει πρώτα τον χρήστη, τα δεδομένα και τη δυνατότητα συνέχειας.
Κερδίζει εμπιστοσύνη όταν όλα δεν λειτουργούν.