Yuri Gubin, CTO στην DataArt – Σειρά Συνεντεύξεων

Yuri Gubin, CTO στην DataArt είναι ένας έμπειρος τεχνολογικός εκτελεστικός διευθυντής και αρχιτέκτονας λογισμικού που έχει περάσει πάνω από 18 χρόνια στη DataArt, προοδεύοντας μέσα από ρόλους που καλύπτουν την αρχιτεκτονική λογισμικού, την αρχιτεκτονική λύσεων, την τεχνολογία cloud, την καινοτομία και την εκτελεστική ηγεσία, πριν γίνει Chief Technology Officer τον Μάρτιο του 2026. Η δουλειά του έχει επικεντρωθεί στην επίλυση σύνθετων τεχνολογικών προκλήσεων σε βιομηχανίες όπως οι χρηματοοικονομικές υπηρεσίες, η υγειονομική περίθαλψη, ο τουρισμός και το IoT, με ιδιαίτερη εξειδίκευση στο cloud computing, την AI, τις πλατφόρμες δεδομένων και την αρχιτεκτονική επιχειρησιακού λογισμικού. Πριν γίνει CTO, ο Gubin υπηρέτησε για πάνω από πέντε χρόνια ως Chief Innovation Officer της DataArt και είναι μέλος του Διοικητικού Συμβουλίου Συνεργατών της εταιρείας από το 2021. Είναι επίσης επαγγελματικό μέλος του Forbes Technology Council, συμμετέχοντας στις ομάδες ειδικών AI και Cloud Computing, και λειτουργεί ως Technology Advisor για το Girls Who Code, όπου συμβουλεύει σχετικά με την αρχιτεκτονική, την προστασία δεδομένων, τη διακυβέρνηση πλατφόρμας και την τεχνολογική πολιτική. Η DataArt τον καταγράφει επί του παρόντος ως Chief Technology Officer με έδρα τη Νέα Υόρκη.

DataArt είναι μια παγκόσμια εταιρεία μηχανικής λογισμικού και μετασχηματισμού δεδομένων και AI, που ιδρύθηκε στη Νέα Υόρκη το 1997. Η εταιρεία έχει αναπτυχθεί σε πάνω από 6.000 τεχνολογικούς επαγγελματίες που δραστηριοποιούνται σε περισσότερες από 20 χώρες και συνεργάζεται με πάνω από 400 πελάτες, παρέχοντας υπηρεσίες σε τομείς όπως η τεχνητή νοημοσύνη και η μηχανική μάθηση, τα δεδομένα και η ανάλυση, η μετατροπή σε cloud, η προσαρμοσμένη μηχανική λογισμικού, η κυβερνοασφάλεια και η εκσυγχρονισμός παλαιών συστημάτων. Η DataArt δραστηριοποιείται σε τομείς όπως οι χρηματοοικονομικές υπηρεσίες, η υγειονομική περίθαλψη και οι επιστήμες της ζωής, ο τουρισμός, τα μέσα μαζικής ενημέρωσης και ψυχαγωγίας, και το λιανικό εμπόριο, και διατηρεί τεχνολογικές συνεργασίες με πλατφόρμες όπως AWS, Google Cloud, Microsoft Azure, Snowflake και Databricks. Το 2025, η εταιρεία ανακοίνωσε επένδυση $100 million τριετούς διάρκειας στις δυνατότητες δεδομένων και AI, ενώ το 2026 λανσάρισε το Artisyn, ένα λειτουργικό μοντέλο με δυνατότητα AI που έχει σχεδιαστεί για να ενσωματώνει AI agents, επαναχρησιμοποιήσιμους επιταχυντές, διακυβέρνηση, ασφάλεια και συμμόρφωση στην ανάπτυξη επιχειρησιακού λογισμικού.

Έχετε περάσει σχεδόν δύο δεκαετίες στη DataArt, προοδεύοντας από αρχιτέκτονα λογισμικού και αρχιτέκτονα λύσεων σε Chief Innovation Officer και τώρα CTO. Πώς έχει διαμορφώσει αυτό το ταξίδι τον τρόπο που διακρίνετε πραγματικά μετασχηματιστικές τεχνολογίες από κύκλους υπερβολής, και πώς επηρεάζει το “skeptical optimism” σας προς την AI σήμερα;

Έχουμε παρατηρήσει πολλές διαφορετικές κυματισμούς τα χρόνια, συμπεριλαμβανομένης της άνοδος του cloud και του mobile, διαφορετικών γενεών AI, αυτοματοποίησης, DevOps και SRE, και έχω προγραμματίσει, σχεδιάσει και συμβουλεύσει τους πελάτες μας σε πολλά από αυτά τα θέματα κατά τη διάρκεια αυτής της περιόδου. Αυτό που συνειδητοποίησα είναι ότι, ναι, μπορείτε να κάνετε σχεδόν οτιδήποτε με την τεχνολογία, και η τεχνολογία είναι αρκετά ισχυρή, αλλά το κακό βρίσκεται στις λεπτομέρειες και πρέπει να ξέρετε τι κάνετε για να έχει νόημα και να λειτουργεί.

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

Αποκτάτε καλή κατανόηση μιας τεχνολογίας μέσω της R&D και, κυρίως, μέσω πραγματικών έργων, επειδή έτσι μαθαίνετε τι είναι δυνατό, τι δεν είναι και πού μπορούν να προκύψουν προβλήματα. Παίρνετε αυτά τα μαθήματα από κάθε συνεργασία, μιλάτε με τους συναδέλφους σας, άλλους αρχιτέκτονες και αναλυτές, και προσπαθείτε να καταλάβετε αν υπάρχουν μοτίβα και αν μπορείτε να δημιουργήσετε κάποιο σύστημα γύρω από αυτά. Τελικά, αυτό γίνεται οδηγός, και τότε βλέπετε αν οι αποφάσεις που θεωρούσατε καλές αποδίδουν πραγματικά θετικά αποτελέσματα.

Από εδώ προέρχεται το skeptical optimism. Ό,τι και να υπόσχεται η τεχνολογία, εξακολουθείτε να χρειάζεται να ξέρετε τι κάνετε, και αυτή η γνώση προέρχεται από την εμπειρία, τη συνεργασία και μια συνεχόμενη προσπάθεια να μαθαίνετε, να βελτιώνεστε και να δημιουργείτε κάποιο σύστημα πίσω από το hype.

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

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

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

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

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

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

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

Γι’ αυτό η πρώτη ομάδα που αξιολογεί ένα νέο μοντέλο δεν πρέπει να είναι όλοι στον οργανισμό. Θα πρέπει να είναι μια ομάδα Ε&Α που εργάζεται στενά με τις σχετικές ομάδες, καθώς και με το νομικό τμήμα και την ασφάλεια. Αξιολογούμε το μοντέλο συνολικά, κάνουμε μια γρήγορη εκτίμηση και στη συνέχεια το παρουσιάζουμε σε ευρύτερο κοινό με κάποιες παρατηρήσεις και οδηγίες σχετικά με την ασφάλεια, τη συμμόρφωση και την τεχνολογία. Με τα νέα μοντέλα και τις σημαντικές ενημερώσεις που έρχονται συνεχώς, χρειάζεται να έχετε αυτό το μοντέλο και τη νοοτροπία σε ισχύ. Δεν είναι πραγματικά μια εφάπαξ ή μοναδική άσκηση.

Η DataArt δημιούργησε μια διατομεακή «AI SWAT» που περιλαμβάνει τεχνολογία, νομική, συμμόρφωση, InfoSec και άλλες ομάδες. Πώς λειτουργεί αυτή η ομάδα στην πράξη και τι είδους κίνδυνοι ή ερωτήματα πρέπει να επιλυθούν πριν εγκριθεί ένα νέο εργαλείο AI για ευρύτερη χρήση;

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

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

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

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

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

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

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

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

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

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

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

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

Η κατανάλωση token και τα κόστη εκτέλεσης μπορεί να φαίνονται σχετικά μικρά κατά τη διάρκεια ενός πιλοτικού προγράμματος, αλλά γίνονται σημαντικά όταν τα συστήματα AI αναπτύσσονται σε χιλιάδες υπαλλήλους ή αυτόνομους πράκτορες. Πώς πρέπει οι επιχειρήσεις να σκέφτονται τη διαχείριση κόστους AI, και αναμένετε κάτι παρόμοιο με το FinOps να εμφανιστεί ειδικά για φορτία εργασίας AI;

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

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

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

Πολλές εταιρείες καλούνται να αποδείξουν ROI από το AI, παρόλο που ποτέ δεν καθόρισαν αξιόπιστη βάση για το πόσο παραγωγικές ήταν οι ομάδες τους πριν εισαχθεί το AI. Τι πρέπει πραγματικά να μετράνε οι οργανισμοί αν θέλουν να καθορίσουν εάν το AI δημιουργεί ουσιαστική επιχειρηματική αξία;

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

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

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

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

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

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

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

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

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

Έχω δει προγραμματιστές .NET να εκπαιδεύονται ξανά ως προγραμματιστές Java πολύ γρήγορα, και πέντε ή δέκα χρόνια πριν θα έλεγα ότι η κλιμακωτή μετάβαση ήταν σχεδόν αδύνατη. Σήμερα, μπορείτε. Ένας ισχυρός senior προγραμματιστής μπορεί όλο και περισσότερο να μετακινείται μεταξύ γλωσσών, επειδή αυτό που πραγματικά μετράει είναι η κατανόησή του για την τεχνολογία, την αρχιτεκτονική, τις βέλτιστες πρακτικές λύσεων, το SDLC και το ADLC.

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

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

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

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

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

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

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