Κώδικας χωρίς υπογραφή

Κώδικας χωρίς υπογραφή

Αν η εποχή του “move fast and break things” είχε επίσημο τέλος, ίσως να ήταν η στιγμή που η Amazon συγκάλεσε mandatory engineering meeting μετά από μια σειρά outages που έριξαν το retail site και το app της. Συμπεριλαμβανομένου ενός crash έξι ωρών που άφησε εκατομμύρια χρήστες να μη βλέπουν τιμές, να μην μπορούν να κάνουν checkout, και να μην έχουν πρόσβαση στους λογαριασμούς τους.

Στο internal briefing, τα incidents χαρακτηρίστηκαν ως “high blast radius” και συνδέθηκαν με “Gen-AI assisted changes”. Η ιστορία αυτή δεν αφορά μόνο την Amazon. Αφορά κάθε οργανισμό που έχει αρχίσει να εντάσσει AI coding tools στη ροή ανάπτυξης λογισμικού χωρίς να έχει φτιάξει πρώτα το σύστημα που τα περιβάλλει.Το πρόβλημα δεν είναι το AI, είναι τα metrics.

Όταν το KPI είναι το “usage”, χάνεται το αποτέλεσμα

Η Amazon είχε θέσει στόχο 80% daily usage για τα AI coding tools μεταξύ των engineers της — ταυτόχρονα με απολύσεις 16.000 εργαζομένων τον Ιανουάριο και capex $200 δισεκατομμυρίων για φέτος. Η εξίσωση είναι απλή: λιγότεροι engineers, περισσότερος AI-generated κώδικας, ταχύτερο deployment.

Το πρόβλημα είναι ότι η μετρική “usage” δεν μετράει αποτέλεσμα. Μετράει συμμετοχή. Και αυτή η διάκριση κοστίζει όταν η οργάνωση επιβραβεύει τη χρήση του εργαλείου αντί για την ποιότητα της έκβασης.

Όταν ο στόχος είναι “χρησιμοποίησε το εργαλείο” και όχι “φτιάξε κάτι που δουλεύει”, ο engineer δεν έχει κίνητρο να αμφισβητήσει το output. Έχει κίνητρο να το περάσει. Ακριβώς αυτό περιγράφουν current και former Amazon engineers στο Reddit: πρωτεύοντα ρόλο είχε η παράδοση, όχι η λειτουργικότητα.

• Το KPI εστιάζει στη συμμόρφωση (χρήση) αντί για αξιοπιστία (outcomes).
• Το review γίνεται τυπικό, όχι ουσιαστικό, όταν προέχει η ταχύτητα.
• Σε incidents, η ευθύνη μετακινείται στο εργαλείο αντί να επιστρέφει στη μηχανική κρίση και στο process.

Κάποιος ανέφερε engineers που χρησιμοποιούν AI tools για να αντιμετωπίσουν άλλα AI tools σε έναν “proxy war of blame” κατά τα on-call incidents. Ακούγεται absurd. Δεν είναι.

Το πρόβλημα του verbose κώδικα — και γιατί δεν το συζητάμε αρκετά

Υπάρχει και ένα πιο τεχνικό, λιγότερο συζητημένο πρόβλημα με τα AI coding tools. Ο κώδικας που παράγουν τα LLMs τείνει να είναι σημαντικά πιο verbose από ό,τι χρειάζεται. Δουλεύει — μέχρι να μη δουλεύει.

Και όταν κάτι πάει στραβά, ο άνθρωπος που καλείται να διαβάσει τον κώδικα βρίσκεται μπροστά σε ένα codebase που δεν μοιάζει με τίποτα γνωστό. Δεν ακολουθεί τα conventions ενός established project, δεν έχει το fingerprint κάποιου senior developer, και δεν το έχει γράψει κανείς που να μπορεί να εξηγήσει γιατί έκανε αυτές τις επιλογές. Η τεκμηρίωση γίνεται συχνά “AI output του AI output”.

Η αντίδραση: safeguards, sign-off και ένα ακόμα outage

Η Amazon αντέδρασε γρήγορα: ο Senior VP Dave Treadwell παραδέχθηκε ότι τα “best practices and safeguards” γύρω από τα AI coding tools δεν έχουν ακόμα διαμορφωθεί πλήρως. Junior και mid-level engineers χρειάζονται πλέον senior sign-off για οποιαδήποτε αλλαγή με AI-assisted κώδικα.

Παράλληλα, η AWS είχε υποστεί τον Δεκέμβριο ένα ξεχωριστό 13ωρο outage αφού το δικό της AI tool, το Kiro, διέγραψε και αναδημιούργησε ολόκληρο ένα coding environment. Το μήνυμα είναι σαφές: η αυτοματοποίηση χωρίς κατάλληλα guardrails δεν “επιταχύνει” — μετακινεί το ρίσκο σε μεγαλύτερη κλίμακα.

Εργαλείο ή σύστημα; Η ερώτηση που αποφεύγουμε

Όπως επισήμαναν ο The Primeagen και ο AI researcher Demetri Spanos, τα μοντέλα είναι έξυπνα — αλλά όχι τόσο έξυπνα όσο τα αντιμετωπίζουμε όταν τα βάζουμε σε production χωρίς guardrails. Το tool δεν είναι στρατηγική. Είναι component.

Η πρόοδος από τον Δεκέμβριο του 2025 δεν ήρθε από βελτίωση των raw models. Ήρθε από την ωρίμανση των agent loops και των team workflows γύρω τους. Το AI coding tool από μόνο του δεν φτάνει — χρειάζεται το σύστημα που το περιβάλλει.

1. Καθαρά outcomes αντί για “usage”: αξιοπιστία, latency, incident rate, change failure rate.
2. Review culture που αξιολογεί intent, trade-offs και συμβατότητα με conventions.
3. Guardrails σε CI/CD: tests, policy checks, staged rollouts, observability.
4. Ownership: κάποιος άνθρωπος υπογράφει τις επιλογές και μπορεί να τις εξηγήσει.

Τι σημαίνει αυτό για εμάς

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

Η ταχύτητα που κερδίζεις από τα AI coding tools δεν σημαίνει τίποτα αν δεν μπορείς να εμπιστευτείς το αποτέλεσμα. Και η εμπιστοσύνη δεν χτίζεται με usage dashboards. Χτίζεται με processes, review culture, και την κατανόηση ότι το AI είναι multiplier — όχι αντικατάσταση της κρίσης.