SDD: Η νέα οργάνωση της τεχνολογίας λογισμικού στην εποχή της ΤΝ

Σπύρος Καραθανάσης, Chief Product & Technology Officer, Comsys

Για δεκαετίες, το λογισμικό ξεκινούσε από έναν άδειο editor και μια ομάδα μηχανικών που μετέφραζε σταδιακά την ασάφεια σε λειτουργική εφαρμογή. Σήμερα, ένα νέο μοντέλο αναδύεται: η προδιαγραφή μετατρέπεται στο πραγματικό κέντρο βάρους της ανάπτυξης, και η τεχνητή νοημοσύνη αναλαμβάνει να τη μετατρέψει σε κώδικα, δοκιμές, τεκμηρίωση και λειτουργική συνοχή. Ο Chief Product & Technology Officer της Comsys, Σπύρος Καραθανάσης, εξηγεί γιατί στα επόμενα χρόνια η τεχνολογία λογισμικού ίσως δεν θα ορίζεται από όσους γράφουν κώδικα, αλλά από όσους μπορούν να ορίζουν με ακρίβεια τι πρέπει να υλοποιηθεί.

Για χρόνια, η βιομηχανία λογισμικού καλλιεργούσε μια σχεδόν εμβληματική εικόνα: έναν μηχανικό μπροστά σε έναν άδειο editor, να δίνει σταδιακά μορφή σε μια ιδέα μέχρι να γίνει επιχειρησιακό σύστημα. Από το waterfall έως το agile και από τα monoliths στα distributed systems, ο κώδικας παρέμενε το αδιαμφισβήτητο σημείο εκκίνησης.

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

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

Με αφορμή αυτή τη μετατόπιση, συνομιλήσαμε με τον Σπύρο Καραθανάση, Chief Product & Technology Officer της Comsys, με πολυετή εμπειρία στην enterprise αρχιτεκτονική και στον ψηφιακό μετασχηματισμό μεγάλων οργανισμών. Η θέση του είναι σαφής: η επόμενη γενιά των προϊόντων λογισμικού δεν θα καθορίζεται από το ποιος ξέρει να γράφει υψηλού επιπέδου κώδικα, αλλά από το ποιος μπορεί να ορίσει ακριβέστερα τι ακριβώς πρέπει να κατασκευαστεί.

Θεωρείτε ότι η Τεχνητή Νοημοσύνη οδηγεί σε ουσιαστική μετάβαση στην ανάπτυξη λογισμικού ή η συζήτηση υπερτονίζει την έκταση της αλλαγής;

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

Για δεκαετίες, αντιμετωπίσαμε τον κώδικα ως το κορυφαίο δημιούργημα της τεχνολογίας λογισμικού. Όλα τα υπόλοιπα -απαιτήσεις, μοντέλα, κανόνες, user journeys, acceptance criteria- υπήρχαν για να εξυπηρετήσουν τη στιγμή που θα ξεκινούσε η «πραγματική» δουλειά: η συγγραφή κώδικα. Η Tεχνητή Νοημοσύνη δείχνει ότι αυτή η αντίληψη δεν ήταν φυσική αναγκαιότητα, αλλά σε μεγάλο βαθμό αποτέλεσμα των τεχνολογικών περιορισμών της εποχής.

Το waterfall βασίστηκε στην υπόθεση ότι η πρόθεση μπορεί να παγώσει εκ των προτέρων και να μεταφερθεί μηχανικά στην υλοποίηση. Το agile διόρθωσε αυτή την ψευδαίσθηση, αναγνωρίζοντας ότι το λογισμικό είναι συνεχής διαδικασία αναθεώρησης. Πρακτικές όπως το BDD, το OpenAPI Specification και το Infrastructure-as-Code έκαναν ήδη βήματα προς εκτελέσιμες προδιαγραφές.

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

Τι είναι, στην πράξη, το Specification-Driven Development; Και γιατί δεν είναι απλώς μια πιο κομψή λέξη για την τεκμηρίωση;

Το Specification-Driven Development, ή SDD, είναι μία αναδυόμενη πρακτική κατά την οποία μια πλούσια, δομημένη προδιαγραφή -σε φυσική γλώσσα ή ημι-τυπική μορφή- λειτουργεί ως αφετηρία από την οποία οι AI agents παράγουν, συγχρονίζουν και εξελίσσουν τον κώδικα, unit, performance και security tests, την τεκμηρίωση και τα deployment artifacts. Η προδιαγραφή μετατρέπεται έτσι στο σημείο εκκίνησης μιας συνεχούς αρχιτεκτονικής ροής μέσα από την οποία AI agents μεταφράζουν το domain intent σε κώδικα, tests, interfaces και λειτουργικά artifacts του συστήματος. Το κρίσιμο στοιχείο είναι ακριβώς αυτό: η προδιαγραφή δεν είναι πια ένα παράρτημα. Αποτελεί τον οργανωτικό πυρήνα ολόκληρου του συστήματος.

Το ερώτημά σας βέβαια είναι δίκαιο: μήπως είναι απλώς νέος όρος για παλιά ιδέα; Η βιομηχανία είχε ήδη επιχειρήσει κάτι παρόμοιο στις αρχές της δεκαετίας του 2000 με το Model-Driven Architecture (MDA): από platform-independent models να παράγεται αυτόματα κώδικας. Η αφετηρία ήταν ορθή, αλλά η υλοποίηση αποδείχθηκε εξαιρετικά δύσκολη — τα εργαλεία της εποχής δεν μπορούσαν να γεφυρώσουν την απόσταση ανάμεσα στη σημασιολογία του μοντέλου και στην πολυπλοκότητα της παραγωγής. Αυτό που αλλάζει σήμερα δεν είναι η φιλοσοφία, αλλά κυρίως είναι τα εργαλεία: τα LLMs μπορούν να ερμηνεύουν τη φυσική γλώσσα και να παράγουν πολλαπλές μορφές artifacts με τρόπο που κανένα MDA pipeline δεν μπορούσε. Δεν μιλάμε για «καλύτερη τεκμηρίωση», αλλά για μια νέα οργάνωση της ίδιας της τεχνολογίας λογισμικού.

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

Αν η προδιαγραφή μετατρέπεται στον πυρήνα της ανάπτυξης και η Τεχνητή Νοημοσύνη αναλαμβάνει ολοένα μεγαλύτερο μέρος της υλοποίησης, τι απογίνεται ο developer;

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

Ο developer της επόμενης γενιάς θα είναι περισσότερο συγγραφέας προδιαγραφών, επιμελητής κανόνων, αρχιτέκτονας πρόθεσης (architect of intent) — ο άνθρωπος που μετατρέπει μια επιχειρησιακή ανάγκη σε ξεκάθαρο, δομημένο και ελέγξιμο νόημα. Όχι απλώς να υλοποιήσει αυτό που του δόθηκε, αλλά να ορίσει τι ακριβώς σημαίνει αυτό που ζητείται.

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

Πολλοί υποστηρίζουν ότι κάθε νέα γενιά μεθοδολογίας υπόσχεται καλύτερη ποιότητα και λιγότερο technical debt. Γιατί το SDD να είναι διαφορετικό;

Επειδή το πιο θεμελιώδες technical debt δεν είναι στην πραγματικότητα τεχνικό. Είναι σημασιολογικό. Πολλοί οργανισμοί νομίζουν πως έχουν κυρίως code ή technical debt, ενώ στην πραγματικότητα υποφέρουν από intent debt. Και το SDD έχει αξία ακριβώς επειδή αντιμετωπίζει αυτό το βαθύτερο επίπεδο φθοράς.

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

Αυτό είναι το αθέατο κόστος σχεδόν κάθε μεγάλης enterprise εφαρμογής. Όχι μόνο επειδή ο κώδικας γίνεται περίπλοκος, αλλά επειδή η λογική του συστήματος αρχίζει να διασκορπίζεται παντού: σε παλιά tickets, σε meetings που δεν τεκμηριώθηκαν ποτέ, σε γνώση που κουβαλούν συγκεκριμένοι άνθρωποι, σε wiki pages που κανείς δεν εμπιστεύεται πλήρως. Ο νέος άνθρωπος που μπαίνει στην ομάδα δεν κληρονομεί σαφήνεια. Κληρονομεί αποσπάσματα.

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

Πότε ακριβώς ένας AI agent παύει να είναι απλώς βοηθητικό εργαλείο και γίνεται co-developer;

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

Το vibe coding -η πρακτική να δίνεις σε έναν AI agent ασαφείς οδηγίες και να αποδέχεσαι ό,τι παράγει χωρίς βαθιά κατανόηση- είναι η εκχώρηση της σκέψης, όχι η ενίσχυσή της. Χτίζει πάνω σε αόρατη ασάφεια, και στο enterprise περιβάλλον η ασάφεια δεν συγχωρείται.

Ένας AI agent που λειτουργεί ως co-developer μπορεί να διαβάσει μια προδιαγραφή, να τη χαρτογραφήσει σε αρχιτεκτονικές επιλογές, να παράγει πολλαπλά τμήματα του συστήματος, να τα συσχετίσει με tests και να επιστρέψει με απορίες εκεί όπου η ανθρώπινη σκέψη παραμένει ατελής. Από εργαλείο παραγωγικότητας γίνεται μηχανισμός γνωστικής πίεσης. Ο καλός AI agent δεν είναι αυτός που «γράφει» — είναι αυτός που ρωτά: εδώ υπάρχει ασάφεια, εδώ λείπει failure scenario, εδώ δύο κανόνες συγκρούονται.

Αυτή η διαφορά -ανάμεσα στον agent που συμμορφώνεται και σε αυτόν που αντιπαρατίθεται- είναι η διαφορά ανάμεσα στο Vibe Coding και στο Specification-Driven Development. Πρόσφατες αναλύσεις του Gartner επιβεβαιώνουν αυτή την κατεύθυνση: οι AI agents μετασχηματίζουν τον κύκλο ζωής του λογισμικού, ενώ οι μηχανικοί μετακινούνται προς ρόλους σχεδιασμού, εποπτείας και διακυβέρνησης — ενισχύοντας την ανάγκη για σαφείς, εκτελέσιμες προδιαγραφές.

Πιστεύετε ότι οι Low-code πλατφόρμες είναι ίσως το πιο φυσικό περιβάλλον για specification-driven ανάπτυξη. Για αρκετούς software engineers αυτό ακούγεται αιρετικό.

Ακούγεται αιρετικό μόνο αν μείνουμε προσκολλημένοι στα παλιά στερεότυπα για το Low-code. Ουσιαστικά, το Low-code ήταν εξαρχής μια προσπάθεια να μεταφερθεί η ανάπτυξη σε πιο δηλωτικό επίπεδο: να περιγράφονται workflows, entities, permissions, integrations και business logic με όρους πιο κοντινούς στη δομή του προβλήματος. Αυτό το καθιστά φυσικό συγγενή του SDD — και τα δύο μοντέλα στηρίζονται στην ίδια παραδοχή: η αξία παράγεται από τη σωστή οργάνωση της πρόθεσης, όχι από την υλοποίηση κάθε λεπτομέρειας από μηδενική βάση.

Σε ένα ώριμο περιβάλλον Low-code, η πλατφόρμα γνωρίζει ήδη κρίσιμα πράγματα για τη δομή μιας εφαρμογής: φόρμες, entities, κανόνες, connectors, deployment contexts. Ένας AI agent που λειτουργεί πάνω σε δομημένη προδιαγραφή δεν δουλεύει στο κενό — δουλεύει μέσα σε γνωστή γραμματική. Μπορεί να διαβάσει μια προδιαγραφή και να παράγει, όχι να μαντέψει. Αυτή η δυναμική αρχίζει να εμφανίζεται σε enterprise πλατφόρμες, διεθνώς αλλά και στην ελληνική αγορά, ως ευρύτερη αναδυόμενη κατεύθυνση.

Η φιλοσοφία του SDD καθόρισε και τον σχεδιασμό του Jaggle, την AI-powered low-code πλατφόρμα που αναπτύσσουμε στην COMSYS. Στόχος μας δεν ήταν απλώς ένα εργαλείο που παράγει κώδικα γρηγορότερα, αλλά ένα περιβάλλον όπου η επιχειρησιακή πρόθεση -κανόνες, ροές, εξαιρέσεις, constraints- αποτυπώνεται με σαφήνεια και οδηγεί άμεσα σε λειτουργικές εφαρμογές enterprise επιπέδου. Ο AI agent μέσα σε μια τέτοια πλατφόρμα δεν ξεκινά από το μηδέν. έχει ήδη οργανωμένο πλαίσιο -entities, workflows, κανόνες διακυβέρνησης, deployment contexts- και λειτουργεί πάνω σε σαφές και ελεγχόμενο υπόβαθρο.

Πλατφόρμες όπως το Jaggle δείχνουν πώς εφαρμόζεται στην πράξη η specification-driven λογική: ένα περιβάλλον όπου η προδιαγραφή, η αυτοματοποίηση, η διακυβέρνηση και η ταχεία ανάπτυξη εφαρμογών συνδέονται σε ένα πιο ενιαίο και συνεκτικό μοντέλο.

Αν αυτό το μοντέλο ωριμάσει, ποιοι θα κερδίσουν;

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

Αντίθετα, θα πιεστούν όσοι συνεχίζουν να λειτουργούν μέσα από ακριβό οργανωτικό θόρυβο: handoffs, σιωπηρή γνώση, documentation drift, ασάφεια ανάμεσα στο business και στο engineering. Ένα μεγάλο μέρος της σημερινής βιομηχανίας πληρώνεται, στην πράξη, για να διαχειρίζεται σύγχυση. Αυτό δεν θα μείνει ανεπηρέαστο.

Θα εμφανιστούν νέοι ρόλοι — specification architects, AI workflow governors, domain curators, policy engineers. Η βιομηχανία θα γίνει λιγότερο γοητευμένη από την ποσότητα της παραγωγής και περισσότερο εξαρτημένη από την ποιότητα της εννοιολογικής πειθαρχίας.

Ποιο είναι το μεγαλύτερο ρίσκο αυτού του μοντέλου;

Το πρώτο είναι η πειστική πλάνη: AI-generated αποτελέσματα που μοιάζουν στιβαρά και τεχνικά ώριμα, αλλά παραμένουν ουσιαστικά λανθασμένα.

Το δεύτερο είναι η διακυβέρνηση. Όταν η προδιαγραφή γίνεται πυρήνας του συστήματος, παύει να είναι αδιάφορα και «αθώο» κείμενο. Μια αλλαγή στη διατύπωση μπορεί να επηρεάσει code generation, tests, interfaces, compliance behavior και production logic. Review, versioning, approvals και change control παύουν να είναι γραφειοκρατικές λεπτομέρειες.

Και μετά έρχεται το spec debt. Η αφαίρεση δεν εξαφανίζει την πολυπλοκότητα — τη μεταφέρει. Μια κακή προδιαγραφή, φλύαρη, αντιφατική, κακώς δομημένη, μπορεί να γίνει εξίσου επιβλαβής με ένα γερασμένο legacy σύστημα. Ο οργανισμός μπορεί απλώς να περάσει από το specification debt στο technical debt χωρίς καν να το αντιληφθεί εγκαίρως.

Τι θα προτείνατε σε έναν CTO ή engineering leader που θέλει να κινηθεί προς αυτή την κατεύθυνση σήμερα;

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

Η σωστή αφετηρία είναι ένα οριοθετημένο πεδίο όπου οι κανόνες έχουν σημασία και το κόστος της αμφισημίας είναι μετρήσιμο. Μετά, πρέπει να ορίσεις τι σημαίνει «καλή προδιαγραφή» για τον οργανισμό σου: πώς γράφονται business rules, πώς τεκμηριώνονται edge cases και constraints, πώς γίνεται review και έγκριση αλλαγών. Και τέλος, να επιλέξει περιβάλλοντα που ενώνουν πρόθεση, υλοποίηση και διακυβέρνηση σε μία ροή και μέσα σε ένα συνεκτικό περιβάλλον.

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

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