Jeremy Freeman, Συνιδρυτής και Τεχνικός Διευθυντής της Allstacks – Σειρά Συνεντεύξεων

Jeremy Freeman, Συνιδρυτής και Τεχνικός Διευθυντής της Allstacks, είναι ένας μηχανικός λογισμικού, αρχιτέκτονας τεχνολογίας και επιχειρηματίας με καριέρα που εκτείνεται στο λογισμικό, την μηχανική υλικού, τη μηχανική μάθηση και την καινοτομία προϊόντων. Από την συνίδρυση της Allstacks το 2017, έχει ηγηθεί της αρχιτεκτονικής και της ανάπτυξης της πυρήνα πλατφόρμας της εταιρείας, συμβάλλοντας στην μεταμόρφωση της διαχείρισης της παράδοσης λογισμικού μέσω προγνωστικών αναλύσεων και προβλέψεων που βασίζονται σε τεχνητή νοημοσύνη. Πριν από την Allstacks, ο Freeman είχε ηγετικές θέσεις στις Ravioli Labs και CertiRx, όπου εργάστηκε στη μηχανική λογισμικού, την έρευνα, τις τεχνολογίες κατά της παραποίησης και την ανάπτυξη προϊόντων. Νωρίτερα στη καριέρα του, απέκτησε εμπειρία σε startups, εταιρείες τεχνολογίας και ακαδημαϊκά ιδρύματα, συμπεριλαμβανομένης της διδασκαλίας ανάπτυξης ιστοσελίδων στο Wake Technical Community College. Το τεχνικό του υπόβαθρο καλύπτει ενσωματωμένα συστήματα, σχεδιασμό υλικού, μεγάλης κλίμακας πλατφόρμες λογισμικού, μηχανική μάθηση και ηγεσία μηχανικής, δίνοντάς του μια μοναδική προοπτική για την κατασκευή δεδομένων-κεντρικών προϊόντων που βοηθούν τις οργανώσεις να βελτιώσουν τα αποτελέσματα της παράδοσης λογισμικού.

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

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

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

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

Ο στόχος μας από την αρχή δεν ήταν να κάνουμε έναν μεμονωμένο προγραμματιστή ταχύτερο στο χαρακτηριστικό Χ. Ήταν να κάνουμε όλη την οργάνωση καλύτερη. Πώς να ευθυγραμμίσετε την προσπάθεια μηχανικής με επιχειρηματικά αποτελέσματα; Πώς να κάνετε τη μηχανική να υπηρετεί πραγματικά την επιχείρηση αντί να υπάρχει απλά δίπλα της; Χρειάζεστε μια καλύτερη κατανόηση των σχέσεων δεδομένων για να απαντήσετε σε αυτά. Είναι αυτά τα ερωτήματα που οδήγησαν σχεδόν κάθε απόφαση προϊόντων που έχουμε πάρει.

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

Δεν νομίζω ότι υπάρχει ένα σύνολο μετρικών που προβλέπει καλό και κακό, αλλά μάλλον μοτίβα για διαφορετικές φάσεις και τύπους οργανισμών. Τι έχω βρει πιο χρήσιμο είναι η αναγνώριση ότι οι οργανώσεις μηχανικής περνούν από εποχές βελτίωσης. Αυτό το μήνα, είναι η απόδοση της βάσης δεδομένων. Το επόμενο μήνα, είναι η επικοινωνία μεταξύ ομάδων. Στη συνέχεια, είναι “γιατί δεν μπορούμε να κλείσουμε κανένα PR;” Στη συνέχεια, είναι η παρατηρησιμότητα. Ως ηγέτης μηχανικής, είστε βυθισμένοι σε σήματα: κάποια διαγνωστικά, κάποια παρακολούθηση και πολλά που είναι απλά θόρυβος.

Τι βοηθά είναι να ξεκινήσετε με το πρόβλημα που πραγματικά βλέπετε, όχι με ένα μέτρο που θέλετε να βελτιώσετε. Αν ζητάτε “γιατί μου φαίνεται ότι παραδίδουμε λιγότερα από το προηγούμενο έτος”, αυτό είναι το σωστό σημείο εκκίνησης. Από εκεί, νομίζω ότι χρειάζεστε τρεις τύπους μετρικών: πρώτα, πώς να γνωρίζετε ότι το πρόβλημα είναι πραγματικό (ίσως μετρήσεις PR ανά προγραμματιστή με το χρόνο); δεύτερο, ποιες αλλαγές κάνετε και πώς τις παρακολουθείτε κατά τη διάρκεια (π.χ. υιοθέτηση ενός AI PR αναθεωρητή αν αυτό είναι η παρέμβασή σας); και τρίτο, πόσο σημαντικό είναι αυτό το πρόβλημα για την επιχείρηση. Η直觉 σας μπορεί να είναι σωστή ότι παραδίδετε 20 τοις εκατό λιγότερο κώδικα, αλλά η πραγματική ιστορία μπορεί να είναι ότι η QA παίρνει τώρα τρεις φορές περισσότερο χρόνο. Χρειάζεστε όλα τα τρία φακό να γνωρίζετε αν λύνετε το σωστό πράγμα.

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

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

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

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

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

Βλέπουμε αυτό καθημερινά. Με ένα καλό πράκτορα και ένα στεγανό περίβλημα γύρω του, μπορείτε να μεταβείτε από ιδέα, đôi φορές απευθείας από το στόμα του πελάτη, σε παραγωγή σε πραγματικό χρόνο.

Μέρος του τι κάνει αυτή την αλλαγή τόσο σημαντική είναι η αλλαγή στο βρόχο ανατροφοδότησης. Με εργαλεία τύπου copilot, ο άνθρωπος είναι στο βρόχο σε κάθε πρόταση. Ο πράκτορας προσφέρει μια ολοκλήρωση· αποδέχεστε ή απορρίπτετε αμέσως. Όταν είναι λάθος, το πιάνετε γρήγορα. Η ακτίνα της λάθος πρότασης είναι μια γραμμή κώδικα. Η κωδικοποίηση του πράκτορα λειτουργεί διαφορετικά· σας δίνετε ένα στόχο, ο πράκτορας αποσυνθέτει το έργο, εκτελεί ένα σχέδιο πολλαπλών βημάτων και παραδίδει ένα λειτουργικό модούλο. Ο άνθρωπος αναθεωρεί την έξοδο, όχι κάθε βήμα. Όταν η προδιαγραφή είναι λάθος, ο πράκτορας κατασκευάζει ολόκληρη την υλοποίηση σε αυτήν την λάθος προδιαγραφή και το ανακαλύπτετε κατά την αναθεώρηση.

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

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

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

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

Η παραδοσιακή ανάπτυξη λογισμικού ήταν ουσιαστικά περιορισμένη από το πόσο γρήγορα ένας προγραμματιστής μπορούσε να γράψει κώδικα που ανταποκρίνεται στις απαιτήσεις της επιχείρησης και της υποκείμενης τεχνολογίας. Αυτό το κόστος προσεγγίζει το μηδέν. Τι κάνουμε τώρα είναι να προχωρήσουμε σε κάτι που είναι πιο κοντά σε ένα μεμονωμένο προγραμματιστή ως διαχειριστή πρακτόρων. Αυτό το μοντέλο απαιτεί μια完全 διαφορετική προσέγγιση για τη μέτρηση της παραγωγικότητας, μια που βασίζεται σε κάτι άλλο από τους τокενς που παράγονται ή τις ώρες προγραμματιστή που διαθέτουν.

Μέρος του κινδύνου με τα τρέχοντα μετρικά είναι ότι κρύβουν τι συμβαίνει στην ομάδα. Οι ανώτεροι μηχανικοί με εργαλεία τεχνητής νοημοσύνης συσσωρεύουν το πλεονέκτημά τους: έχουν το контекст του κώδικα και τη κρίση για να οδηγήσουν την έξοδο του πράκτορα και να πιάσουν τις λεπτές αποτυχίες που περνούν το CI αλλά δημιουργούν αρχιτεκτονικά προβλήματα αργότερα. Οι προγραμματιστές πρώιμης καριέρας παράγουν τον ίδιο όγκο κώδικα αλλά ξοδεύουν περισσότερο χρόνο για την επιθεώρηση της έξοδου που δεν μπορούν να αξιολογήσουν πλήρως. Η ομαδική ταχύτητα φαίνεται καλή, μπορεί να έχει ακόμη και βελτιωθεί. Η διαφορά μεταξύ αυτών των δύο ομάδων δεν εμφανίζεται πουθενά σε ένα τυπικό πίνακα ελέγχου. Το σωστό ερώτημα για να αρχίσετε να ζητάτε δεν είναι “πόσο γρήγορα πηγαίνουμε” αλλά “πόσο από αυτό που παραδώσαμε ήταν σωστό από την πρώτη φορά”.

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

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

Η Allstacks ήταν επιτυχημένη σε αυτόν τον χώρο επειδή έχουμε κατασκευάσει γραφικούς контекστ από πριν ήταν ένα όνομα. Αναγνώρισαν πρώιμα ότι η σύνδεση όλων των δεδομένων μαζί ήταν απαραίτητη για να απαντήσουν στα ερωτήματα που οι πελάτες πραγματικά έθεσαν.

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

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

Όταν οι πράκτορες τεχνητής νοημοσύνης γίνονται πιο ενσωματωμένοι στις ροές εργασίας ανάπτυξης, τι μοιάζει μια καλά προετοιμασμένη οργάνωση μηχανικής σε σύγκριση με μια που δεν είναι έτοιμη;

Παραδόξως, δεν είναι πολύ διαφορετικό από το να είστε προετοιμασμένοι να φέρετε μια τάξη θερινών praktikant. Χρειάζεστε ισχυρά αυτοματοποιημένα σύνολα δοκιμών, στεγνά έγγραφα, μια ωριμασμένη CI/CD πipeline και τις φρουρές που θα τοποθετήσετε όταν προσθέτετε έναν αξιόπιστο αλλά μη εκπαιδευμένο προγραμματιστή στην ομάδα.

Τι είναι επίσης σημαντικό, και οι άνθρωποι έχουν την τάση να το υποτιμούν, είναι να επιστρέψετε τακτικά για να αναθεωρήσετε τα βασικά: τις κανόνες του πράκτορα, τα αρχεία AGENTS.MD. Μπορείτε να κάνετε μια στεγνή πρώτη πέρα, αλλά είναι εύκολο να μπείτε σε einen ρυθμό αποστολής με τον νέο τρόπο και να ξεχάσετε ότι μπορείτε πραγματικά να εκπαιδεύσετε μακριά πολλά κακά προεπιλογές. Πράγματα όπως η διδασκαλία του πράκτορα να τρέχει δοκιμές πριν από κάθε commit δεν πρέπει να απαιτούν μια ανθρώπινη υπενθύμιση κάθε φορά.

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

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

Έχω δει δύο κύριες τρόπους αποτυχίας. Η πρώτη είναι εταιρείες που δεν ζευγαρώνουν ομάδες μηχανικής με προϊόντα. Πολλές δομές ομάδων είναι κληρονομικές και έχουν υπάρξει για πολύ καιρό. Μια ομάδα μπορεί να κατέχει ένα μέρος τριών διαφορετικών προϊόντων ενώ μια άλλη κατέχει τέσσερα εντελώς. Η επένδυση μηχανικής έρχεται κυρίως xuống σε headcount, και όταν οι ομάδες δεν ευθυγραμμίζονται με προϊόντα, γίνεται πολύ δύσκολο να δείτε πού οι επιχειρηματικές προσδοκίες απομακρύνονται από την πραγματικότητα.

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

Αν ζητήσετε από έναν ηγέτη πωλήσεων να επιλέξει μεταξύ κάποιων ενημερώσεων npm και της λειτουργίας που χρειάζεται για να κλείσει μια συμφωνία, η λειτουργία κερδίζει κάθε φορά. Αλλά αν το πλαισιωθεί ως “βγείτε από την SOC συμμόρφωση ή να παραδώσετε αυτήν τη λειτουργία”, τώρα τους δείχνετε δύο συναλλαγές που μπορούν πραγματικά να αξιολογήσουν. Αυτή η αναπλασιά είναι το ganze παιχνίδι. Έχουμε δει πελάτες να κόβουν το χρόνο αναφοράς R&D με πάνω από δύο τρίτα απλά κάνοντας αυτό το έργο αυτοματοποιημένο αντί για χειροκίνητο. Ο μηχανισμός είναι ο ίδιος ανεξάρτητα από το αν ο στόχος είναι αναφορά R&D, δικαιολογία headcount ή απόδειξη ROI AI: συνδεδεμένα δεδομένα αντικαθιστούν συναρτημένα φύλλα εργασίας.

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

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

Οι ανησυχίες μου είναι πραγματικές. Οι φρεσκοαποφοιτημένοι θα εισέλθουν στη lực εργασίας χωρίς να έχουν ποτέ κωδικοποιήσει σε έναν κόσμο χωρίς πράκτορες κωδικοποίησης. Έχει η εκπαίδευση跟ować με αυτό; Τα εργαλεία κινούνται γρήγορα· η ανώτερη εκπαίδευση δεν κινείται πάντα μαζί τους. Η άλλη αλλαγή που παρακολουθώ είναι η θολότητα μεταξύ ανώτερων μηχανικών και ανώτερων προϊόντων. Οι πιο επιτυχημένοι praktikanten στο νέο μοντέλο είναι μηχανικοί που είναι βαθιά επενδυμένοι στη σκέψη προϊόντων.

Τι γίνεται πιο πολύτιμο είναι η κρίση: η ικανότητα να ορίσετε ένα πρόβλημα με ακρίβεια enough για τον πράκτορα να το λύσει, να αξιολογήσετε αν η λύση είναι σωστή και να πιάσετε τις λεπτές αποτυχίες που περνούν το CI αλλά δημιουργούν αρχιτεκτονικά προβλήματα αργότερα. Οι ανώτεροι μηχανικοί συσσωρεύουν το πλεονέκτημά τους: μπορούν να οδηγήσουν την έξοδο του πράκτορα και να πιάσουν τις αποτυχίες του. Η ανησυχία είναι για την πρώιμη καριέρα. Ο παραδοσιακός τρόπος για να χτίσετε αυτήν την κρίση ήταν να γράψετε πολύ κώδικα και να μάθετε από τα λάθη. Αυτή η πίσω-σύνδεσμος είναι αλλάζει με τρόπους που η βιομηχανία δεν έχει ακόμη εργαστεί.

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

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

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

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

Δύο πράγματα που είμαι αρκετά βέβαιος για το τριετές-πενταετές παράθυρο. Πρώτον, το ανταγωνιστικό πλεονέκτημα στη μηχανική AI θα έρθει από το βάθος και το πλάτος του контекστ, όχι από την ποιότητα του μοντέλου. Τα μοντέλα γίνονται τραπέζι· κάθε εργαλείο θα έχει ικανά. Τι θα διαφοροποιήσει τις ηγετικές πλατφόρμες είναι πόσο βαθιά κατανοούν την οργάνωση σας: τα repos σας, τη δομή της ομάδας σας, την ιστορία παράδοσής σας, τα μοτίβα ανάπτυξής σας. Τα εργαλεία που γνωρίζουν το σύστημά σας θα παράγουν ουσιαστικά διαφορετικές απαντήσεις από αυτά που δεν το κάνουν. Δεύτερον, η αλλαγή από αντιδραστική σε προδραστική. Σήμερα, τα εργαλεία απαντούν σε ερωτήματα όταν ζητηθούν. Σε quelques χρόνια, τα ηγετικά εργαλεία θα παρατηρούν συνεχώς και θα επιφέρουν κίνδυνο πριν ζητηθεί. Οι οργανώσεις που χτίζουν αυτόν τον контεκστ σήμερα συσσωρεύουν ένα πλεονέκτημα. Η επόμενη γενιά εργαλείων πρέπει να λύσει το πρόβλημα ποιότητας σε κλίμακα, και οι οργανώσεις που το λύσουν πρώτες θα έχουν ένα πραγματικό πλεονέκτημα.

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