Μια διαδρομή 4,5 ωρών από την ιδέα σε λειτουργική εφαρμογή fitness με LLM agents.
Στο προηγούμενο άρθρο μου, “From Code to Insights: Software Engineering Best Practices for Data Analysts”, ανέφερα ότι οι δεξιότητες μηχανικού και οι βέλτιστες πρακτικές είναι εξαιρετικά χρήσιμες για αναλυτές και άλλους επαγγελματίες δεδομένων.
Αυτό ισχύει ακόμη περισσότερο στην εποχή της τεχνητής νοημοσύνης, όπου έχουμε πολύ περισσότερες ευκαιρίες να φτιάχνουμε δικά μας αναλυτικά εργαλεία: από εξελιγμένους προβολείς δεδομένων με γραφήματα και σενάρια, μέχρι προσομοιωτές που προβλέπουν αποτελέσματα με βάση παραμέτρους εισόδου. Προσωπικά, χρησιμοποιώ συνεχώς web εφαρμογές στην καθημερινή δουλειά μου.
Υπήρξε πολύς θόρυβος γύρω από το vibe coding, αλλά φαίνεται πως οι επαγγελματίες μηχανικοί το ξεπερνούν και στρέφονται στην ανάπτυξη με προδιαγραφές (spec-driven development). Ακόμη και ο Andrej Karpathy, που εισήγαγε τον όρο “vibe coding” τον Φεβρουάριο του 2025, παραδέχθηκε έναν χρόνο μετά ότι αυτή η εποχή τελειώνει και μπαίνουμε στην ηλικία της agentic engineering — ορχήστρωση agents πάνω σε λεπτομερείς προδιαγραφές με ανθρώπινη επίβλεψη.
“Today (1 year later), programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny. The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software. Many people have tried to come up with a better name for this to differentiate it from vibe coding, personally my current favorite “agentic engineering”: – “agentic” because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. – “engineering” to emphasize that there is an art & science and expertise to it. It’s something you can learn and become better at, with its own depth of a different kind.”
Σε αυτό το άρθρο, βάζω την ανάπτυξη με προδιαγραφές στην πράξη, σε ένα πράσινο πεδίο, ακολουθώντας τις βέλτιστες πρακτικές από το μάθημα της JetBrains στο DeepLearning.AI, “Spec-Driven Development with Coding Agents”.
Το project είναι προσωπικό, αλλά σχετίζεται με δεδομένα. Καθώς ετοιμάζομαι για έναν ημιμαραθώνιο τον Σεπτέμβριο, προσπαθώ να ισορροπήσω τρέξιμο και ενδυνάμωση. Υπάρχουν πολλά εργαλεία, το καθένα για διαφορετικό κομμάτι της διαδρομής, και αποδείχθηκε δύσκολο να βρω μια λύση που να μου ταιριάζει. Έτσι, αποφάσισα να πετύχω δύο στόχους μαζί: να φτιάξω τη δική μου web εφαρμογή και να μάθω κάτι καινούργιο στην πορεία.
Πριν περάσουμε στην υλοποίηση, αξίζει να δούμε συνοπτικά τη θεωρία πίσω από την ανάπτυξη με προδιαγραφές.
Vibe coding vs ανάπτυξη με προδιαγραφές
Οι περισσότεροι έχουμε δοκιμάσει το vibe coding: γράφεις ένα σύντομο prompt (π.χ. “Please add a DAU chart to my web application”), περιμένεις τον agent να κάνει την αλλαγή, τρέχεις τοπικά και ελέγχεις αν το αποτέλεσμα ανταποκρίνεται στις προσδοκίες.
Συνήθως όχι. Επιστρέφεις στο ίδιο chat, ζητάς προσαρμογές, και επαναλαμβάνεις μέχρι το αποτέλεσμα να είναι αρκετά καλό.
Αυτό λειτουργεί ικανοποιητικά για απλά projects, αλλά δεν κλιμακώνεται, ειδικά όταν πολλοί developers δουλεύουν στον ίδιο κώδικα.
Τα βασικά μειονεκτήματα είναι η απουσία βέλτιστων πρακτικών και κοινών συμβάσεων. Χωρίς δομημένη προσέγγιση, μια ομάδα μπορεί εύκολα να καταλήξει με πέντε διαφορετικούς τρόπους εκπαίδευσης ενός ML μοντέλου μέσα στο ίδιο DBT pipeline.
Ένα ακόμη σύνηθες πρόβλημα είναι ότι δεν διατηρούμε τα αποτελέσματα ή το σκεπτικό από τις συνομιλίες μας με agents. Έτσι, χάνεται γιατί πάρθηκαν κάποιες αποφάσεις. Για παράδειγμα, ένας agent μπορεί να “ξεχάσει” γιατί καθάρισες τα δεδομένα με συγκεκριμένο τρόπο και μια επόμενη ενημέρωση να αλλάξει σιωπηρά το αποτέλεσμα.
Υπάρχει και η φθορά του context. Οι agents είναι stateless και, σε μεγαλύτερα projects, συχνά ξεκινάμε νέα chats λόγω ορίων παραθύρου συμφραζομένων, ουσιαστικά από την αρχή.
Η ανάπτυξη με προδιαγραφές (SDD) μοιάζει περισσότερο με τις παραδοσιακές πρακτικές μηχανικής. Αντί να πηδάμε κατευθείαν στην υλοποίηση, κάνουμε πρώτα τη δύσκολη σκέψη: παίρνουμε αρχιτεκτονικές αποφάσεις, ορίζουμε απαιτήσεις και τις τεκμηριώνουμε σε δομημένες markdown προδιαγραφές, αποθηκευμένες στο repo και ενημερωμένες μαζί με το project. Έτσι, αποσυνδέουμε τις προδιαγραφές (τι και γιατί φτιάχνουμε) από την υλοποίηση (τον κώδικα).
Το SDD λύνει βασικά προβλήματα του vibe coding, διατηρώντας το context σε συνεδρίες και μεταξύ διαφορετικών agents, ενώ ευθυγραμμίζει ανθρώπους και agents γύρω από τα αδιαπραγμάτευτα του project.
Μια τυπική ροή SDD περιλαμβάνει στάδια όπως:
Το πρώτο βήμα είναι ο καθορισμός του “συντάγματος” — μια συμφωνία στις βασικές αποφάσεις του project. Συνήθως περιλαμβάνει ορισμένα βασικά έγγραφα:
Οι προδιαγραφές μπορούν να δημιουργηθούν τόσο για νέα όσο και για υπάρχοντα projects, κάτι που κάνει την προσέγγιση ευέλικτη.
Αφού ολοκληρωθεί η τεκμηρίωση σε επίπεδο project, περνάμε στη φάση ανάπτυξης λειτουργιών, που συνήθως περιλαμβάνει:
Αφού υλοποιήσεις την πρώτη λειτουργία, είναι δελεαστικό να συνεχίσεις αμέσως. Όμως τώρα είναι η σωστή στιγμή για παύση και αναστοχασμό.
Εδώ μπαίνει το replanning. Πρόκειται για φάση επανεξέτασης του “συντάγματος” και των προηγούμενων αποφάσεων, ώστε να διασφαλιστεί ότι παραμένουν ευθυγραμμισμένες με τους στόχους του project.
Αρκετά με τη θεωρία — ώρα για πράξη.
Για να δω πώς δουλεύει το SDD στην πράξη, το εφάρμοσα σε ένα πραγματικό greenfield project.
Ξεκίνησα δημιουργώντας νέο repository (και, ναι, ξόδεψα μισή ώρα για όνομα και λογότυπο): repository. Κατέγραψα και το αρχικό product vision στο README.md.
Ένα από τα θετικά του SDD είναι ότι είναι ως επί το πλείστον agnostic ως προς LLM, agent ή IDE. Μπορείς να δουλέψεις με ό,τι σε βολεύει. Για το project αυτό, χρησιμοποίησα Visual Studio Code με το plugin Claude Code, ώστε να αξιοποιώ τον Claude ως agent και να κάνω review των αλλαγών κώδικα μέσα από τον editor.
Δημιουργία “συντάγματος”
Όπως είπαμε, πρώτο βήμα είναι το “σύνταγμα”. Δεν χρειάζεται να γραφτεί αποκλειστικά στο χέρι· μπορείς να χρησιμοποιήσεις LLMs με βάση το αρχικό product vision και διευκρινιστικές ερωτήσεις.
Ο agent έκανε μια σειρά από διευκρινιστικές ερωτήσεις για να ορίσει το “σύνταγμα” και να φτιάξει αρχικό πλάνο υλοποίησης.
Στο τέλος, δημιούργησε και τα τρία αρχεία που ζητήσαμε.
Εδώ μπορεί να θες να ζητήσεις αμέσως από τον agent να ξεκινήσει την υλοποίηση, αλλά είναι νωρίς.
Πριν προχωρήσουμε, χρειάζεται να επικυρώσουμε και να βελτιώσουμε το “σύνταγμα”. Αξίζει ο χρόνος εδώ, γιατί αυτή η προδιαγραφή θα μεταφραστεί αργότερα σε χιλιάδες γραμμές κώδικα. Καλύτερα να λύνονται οι ασάφειες τώρα.
Συνήθως το κάνω διαβάζοντας τα έγγραφα και κάνοντας διαδοχικά iterations με τον agent, με ερωτήσεις και διορθώσεις. Καλή πρακτική είναι όλες οι αλλαγές να περνούν από τον agent, όχι με χειροκίνητα patches, για να κρατιέται η συνοχή. Για παράδειγμα, του είπα ότι χρειαζόμαστε authentication, αφού θα καταγράφω προπονήσεις από desktop και κινητό. Αυτό οδήγησε σε ενημερώσεις στο tech stack και στο roadmap.
Όταν είσαι ικανοποιημένος, μπορείς να ζητήσεις από δεύτερο agent — με φρέσκο context — να κάνει κριτική στο πλάνο. Υπάρχουν πολλές ενδείξεις ότι η “reflection” βελτιώνει την ποιότητα εξόδου.
Μετά τους ελέγχους, κάνουμε commit το “σύνταγμα” στο repository.
Περνάμε στην πρώτη φάση λειτουργικότητας. Σύμφωνα με το roadmap, ξεκινάμε με το MVP: Core Activity Logging. Στο τέλος αυτής της φάσης, ο χρήστης θα μπορεί να συνδεθεί από desktop και mobile, να καταγράψει τρέξιμο και προπόνηση γυμναστηρίου και να τα δει στο ιστορικό με πλήρεις λεπτομέρειες.
Κάθε φάση λειτουργικότητας ακολουθεί τον κύκλο plan → implement → validate. Ξεκινάμε ορίζοντας προδιαγραφές και πλάνο.
Tip: αξίζει να ανοίξεις νέα συνεδρία με καθαρό context στον LLM agent.
Ο agent συνέταξε γρήγορα τις προδιαγραφές.
Ώρα ξανά για review, ώστε όλα να ευθυγραμμίζονται με το αρχικό όραμα. Στην agentic engineering, ο ρόλος του developer μετατοπίζεται στη διεύθυνση, το review και τις αρχιτεκτονικές αποφάσεις, όχι στη χειρόγραφη συγγραφή specs ή κώδικα.
Μόλις είσαι εντάξει με το πλάνο, περνάμε στην υλοποίηση. Προτιμώ να υλοποιώ ομάδες εργασιών χωριστά αντί για “one-shot” όλη τη φάση, ανάλογα με το μέγεθος. Για αυτό το project, χρησιμοποίησα το εξής prompt.
Όταν ο κώδικας είναι έτοιμος, ακολουθεί το review — από τα σημαντικότερα βήματα.
Σε εφαρμογές δεδομένων, εστιάζω στη βασική επιχειρησιακή λογική και ελέγχω ότι οι αριθμοί βγάζουν νόημα.
Ομολογώ ότι ξέρω ελάχιστα από frontend τεχνολογίες, οπότε σπάνια κάνω λεπτομερές review frontend κώδικα. Αντί γι’ αυτό, τρέχω τοπικά και ελέγχω αν λειτουργεί όπως πρέπει. Σε αυτή την περίπτωση, έτρεξα την εφαρμογή για να τη δω.
Μετά από λίγες επαναλήψεις με τον agent, τρέξαμε την app τοπικά και λειτούργησε. Μπορούμε ήδη να προσθέτουμε διαφορετικές ασκήσεις και τύπους δραστηριότητας και να καταγράφουμε cardio και strength sessions.
Μετά το manual review, είναι χρήσιμο να χρησιμοποιήσεις reflection και να ζητήσεις από νέο agent να ελέγξει αν η υλοποίηση ευθυγραμμίζεται με το πλάνο και με τα σημεία στο validation.md.
Θεωρητικά, στο SDD η φάση λειτουργικότητας κλείνει με validation. Στην πράξη, σπάνια είναι τόσο καθαρό. Πιθανό να βρεις σημεία που δεν δουλεύουν όπως πρέπει. Τότε έχεις δύο επιλογές:
Ένα σημαντικό σημείο: είναι δελεαστικό να εξηγήσεις το πρόβλημα στον agent και να ζητήσεις γρήγορα “fixes”, χωρίς να ενημερώσεις τις προδιαγραφές. Απόφυγέ το. Η διατήρηση της προδιαγραφής ως πηγής αλήθειας είναι που κάνει την προσέγγιση ανθεκτική.
Αφού ολοκληρωθούν οι έλεγχοι, δημιουργούμε και κάνουμε merge το pull request.
Σε αυτό το σημείο έχουμε ήδη λειτουργική εφαρμογή και το αποτέλεσμα είναι πραγματικά ικανοποιητικό. Ακόμη πιο εντυπωσιακό, όλη η διαδικασία πήρε λίγο πάνω από δύο ώρες από άκρη σε άκρη (συμπεριλαμβανομένης της συγγραφής του άρθρου όσο ο agent δούλευε).
Με τέτοια πρόοδο, είναι φυσικό να θέλεις να συνεχίσεις. Το καταλαβαίνω, αλλά στη σημερινή εποχή, η κύρια αξία του ανθρώπου είναι στη σκέψη και στην αρχιτεκτονική. Τώρα είναι η στιγμή για ένα βήμα πίσω: συνεχίζουμε στην ίδια κατεύθυνση; Τι αλλάζουμε σε προϊόν και διαδικασία;
Όταν άρχισα να χρησιμοποιώ την εφαρμογή, κατάλαβα ότι δεν καλύπτει πλήρως ακόμη τη χρήση μου. Πρέπει να αναπροτεραιοποιήσουμε, ώστε να τη χρησιμοποιώ καθημερινά το συντομότερο. Το έκανα με το παρακάτω prompt.
Το replanning είναι επίσης καλή στιγμή να ξαναδούμε τη διαδικασία μας. Για παράδειγμα, παρατήρησα ότι δεν ενημερώνουμε συστηματικά το roadmap.md και οι προδιαγραφές αρχίζουν να “αποκλίνουν”. Θα ήταν χρήσιμο να εισαγάγουμε changelog, ώστε να έχουμε καθαρό ιστορικό εξέλιξης του προϊόντος.
Ας το ζητήσουμε από τον agent.
Αφού ευθυγραμμιστήκαμε στην κατεύθυνση και στήσαμε σωστά το πλαίσιο, συνεχίζουμε την ανάπτυξη.
