Gautam Korlam, Ανώτερος Μηχανικός στη Sonar – Σειρά Συνεντεύξεων

Gautam Korlam, Ανώτερος Μηχανικός στη Sonar, είναι ένας έμπειρος μηχανικός λογισμικού και ηγέτης τεχνολογίας του οποίου η καριέρα έχει εστιάσει στην υποδομή προγραμματιστών, στην ποιότητα κώδικα, στον αυτοματισμό και στην ανάπτυξη λογισμικού με υποβοήθηση AI. Πριν ενταχθεί στη Sonar, συνέδισε την ίδρυση της Gitar και υπηρέτησε ως CTO, δημιουργώντας μια πλατφόρμα AI‑native σχεδιασμένη για αυτοματοποίηση της αξιολόγησης κώδικα, διάγνωση αποτυχιών συνεχούς ενσωμάτωσης (CI), εντοπισμό αιτιών ρίζας και παραγωγή διορθώσεων. Η Sonar εξαγόρασε τη Gitar τον Μάιο του 2026, με τον Korlam και την ομάδα της Gitar να εντάσσονται στην εταιρεία για να συνεχίσουν την ανάπτυξη της τεχνολογίας ως μέρος της ευρύτερης πλατφόρμας επαλήθευσης κώδικα της Sonar. Πριν από τη Gitar, ο Korlam πέρασε σχεδόν μια δεκαετία στην Uber, προοδεύοντας από μηχανικό ιδρυτή στην ομάδα πλατφόρμας κινητών στο ρόλο του Ανώτερου Μηχανικού. Κατά τη διάρκεια της θητείας του, συνέβαλε στην κατασκευή και κλιμάκωση της κεντρικής υποδομής προγραμματιστών της Uber, ηγήθηκε σημαντικών πρωτοβουλιών monorepo και συστήματος κατασκευής, ανέπτυξε απομακρυσμένα περιβάλλοντα προγραμματιστών και εργαλεία CI/CD, και πειραματίστηκε με ανοιχτού κώδικα μεγάλα γλωσσικά μοντέλα όπως τα StarCoder, OctoCoder και Code Llama για τη βελτίωση του AI‑assisted coding μέσα στη βάση κώδικα της Uber. Προηγούμενη εμπειρία του περιλαμβάνει ρόλους μηχανικού στην Lookout και ερευνητική εργασία στο UC Santa Barbara, καθώς και πρακτική άσκηση στη Microsoft και την Oracle.

Sonar είναι μια εταιρεία λογισμικού που εστιάζει στην επαλήθευση κώδικα, την αυτοματοποιημένη αξιολόγηση κώδικα, την ποιότητα κώδικα και την ασφάλεια εφαρμογών. Η κορυφαία της πλατφόρμα, SonarQube, αναλύει κώδικα που γράφουν προγραμματιστές και κώδικα που παράγεται από AI για να εντοπίσει σφάλματα, ευπάθειες, προβλήματα συντηρησιμότητας και άλλα ζητήματα ποιότητας πριν φθάσουν στην παραγωγή, με προσφορές που καλύπτουν cloud, αυτοδιαχειριζόμενα και ροές εργασίας ενσωματωμένων περιβαλλόντων ανάπτυξης. Η Sonar δηλώνει ότι η τεχνολογία της χρησιμοποιείται από περισσότερους από 7 εκατομμύρια προγραμματιστές και 22.000 πελάτες και αναλύει πάνω από 750 δισεκατομμύρια γραμμές κώδικα καθημερινά. Η εξαγορά της Gitar επέκτεινε αυτή την προσέγγιση σε AI‑native αξιολόγηση κώδικα και αποκατάσταση, συνδυάζοντας τη μηχανή επαλήθευσης του SonarQube με εργαλεία που μπορούν να αξιολογούν κώδικα, να διερευνούν αποτυχίες CI και να προτείνουν ή να εφαρμόζουν διορθώσεις καθώς η ανάπτυξη λογισμικού γίνεται ολοένα και πιο καθοδηγούμενη από AI.

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

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

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

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

Η ανάλυση βασισμένη σε κανόνες είναι το σωστό εργαλείο όταν η ιδιότητα είναι αποφασίσιμη από τον ίδιο τον κώδικα. Μολυσμένη είσοδος που φθάνει σε σημείο απορριψης, μια αναφορά σε null σε διαδρομή που κάποιος παρέλειψε, διαπιστευτήρια ενσωματωμένα στον κώδικα, μια εξάρτηση με γνωστό CVE, μια εισαγωγή που διασχίζει ένα επίπεδο που δεν πρέπει. Λαμβάνετε την ίδια απάντηση σε κάθε εκτέλεση και μπορείτε να δείξετε το λόγο που ενεργοποιήθηκε, γι’ αυτό η επιβολή ανήκει σε αυτό το επίπεδο.

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

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

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

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

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

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

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

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

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

Η αξιολόγηση και η επαλήθευση έχουν ήδη γίνει το σημείο συμφόρησης. Στην πραγματικότητα, η Έρευνα Προγραμματιστών State of Code 2026 διαπίστωσε ότι οι ομάδες δηλώνουν ότι δαπανούν περίπου ένα τέταρτο της εργασιακής εβδομάδας ελέγχοντας και διορθώνοντας την έξοδο AI. Με αυτό, δεν είναι έκπληξη το γεγονός ότι μόνο το 48% των προγραμματιστών ελέγχει πάντα τον κώδικα που παράγεται από AI πριν τον υποβάλει, παρόλο που η πλειοψηφία (96%) δεν εμπιστεύεται πλήρως ότι είναι λειτουργικά σωστός.

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

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

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

Οι περισσότεροι περιορισμοί που θέτουμε στην δική μας αποκατάσταση αφορούν το εύρος. Η Gitar διορθώνει CI που έσπασε, και ελέγχει ότι η commit πριν από το δικό της push ήταν πράσινη πριν αναλάβει οποιαδήποτε ευθύνη. Σταματά μετά από δύο επακόλουθες commits αντί να συνεχίζει σε μια κόκκινη κατασκευή. Όταν η αποτυχία δεν έχει σχέση με την αλλαγή, ένα ασταθές τεστ ή ένα σφάλμα υποδομής, ακολουθεί τη διαδρομή επανάληψης αντί για τη διαδρομή διόρθωσης, επειδή το «να σταματήσει το τεστ να αποτυγχάνει» είναι ο στόχος που θέλετε λιγότερο να επιδιώξει ένας ικανός πράκτορας.

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

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

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

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

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

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

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

Ξεκινήστε με τα αποτελέσματα, όχι με τον αριθμό των σχολίων που παράγει ένα σύστημα AI. Θα μετρούσα τον χρόνο από το pull request μέχρι τη συγχώνευση, τον χρόνο που δαπανάται στη διάγνωση αποτυχιών CI, το ποσοστό με το οποίο οι διορθώσεις περνούν στην πρώτη προσπάθεια επικύρωσης, και πόσο συχνά τα ζητήματα διαρρέουν σε μεταγενέστερα στάδια ή στην παραγωγή.

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

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

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

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

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