Loading...

Solorak
Payroll, ΑΙ και οι υπόλοιποι

Payroll, ΑΙ και οι υπόλοιποι

Το AI έχει μπει για τα καλά στο καθημερινό workflow όλων μας. Άλλοι το χρησιμοποιούν για debugging. Άλλοι για documentation. Άλλοι για UI/UX. Μέχρι πρόσφατα, η συζήτηση γύρω από το AI στο development ήταν κυρίως γύρω στις λύσεις άμεσων ζητημάτων. Πόσο πιο γρήγορα γράφουμε κώδικα , “fix my bug” κλπ.

AITOKENPAYROLLSALARYCOMPANY

Σύμφωνα με άρθρο του CIO, η Gartner προειδοποιεί ότι τα κόστη από AI coding tokens σε επιχειρήσεις μπορεί μέσα στα επόμενα δύο χρόνια να φτάσουν ή ακόμα και να ξεπεράσουν τον μέσο μηνιαίο μισθό ενός software engineer, με βάση έναν παγκόσμιο μέσο όρο περίπου $2.000 τον μήνα. Το άρθρο αναφέρει επίσης παραδείγματα υπερβολικής κατανάλωσης, όπως developers ή business users που έφτασαν σε usage χιλιάδων δολαρίων μέσα σε έναν μήνα.

Και αυτό αλλάζει τη συζήτηση.

Γιατί μέχρι τώρα αρκετοί βλέπαμε το AI coding κυρίως σαν ένα εργαλείο επιτάχυνσης.

Σαν κάτι που πληρώνεις με μια συνδρομή και το χρησιμοποιείς όσο χρειάζεσαι.

Σαν “έναν βοηθό” που κάνει λίγο πιο εύκολη τη μέρα σου.

Αλλά σε enterprise περιβάλλοντα, ειδικά όταν μπαίνουν coding agents, μεγάλα context windows και consumption-based pricing, η χρήση δεν είναι πλέον τόσο απλή.

Δεν είναι απλώς “έχω Copilot ή δεν έχω”.

Είναι πόσα tokens καταναλώνονται.

Και κάπου εκεί, το AI από “εργαλείο παραγωγικότητας” αρχίζει να μοιάζει με νέο λειτουργικό κόστος.

Σαν να προσέλαβες έναν πολύ γρήγορο junior, αλλά να χρεώνει κάθε σκέψη του σε tokens.

Το ενδιαφέρον είναι ότι αυτό δεν σημαίνει πως το AI δεν αξίζει.

Το αντίθετο.

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

Το πρόβλημα δεν είναι ότι το AI έχει κόστος.

Το πρόβλημα είναι όταν το κόστος δεν είναι ορατό.

Γιατί με έναν ανθρώπινο developer, το κόστος είναι σχετικά καθαρό. Υπάρχει μισθός, χρόνος, εμπειρία, παραγωγικότητα, output.

Με το AI, όμως, το κόστος μπορεί να είναι πιο “θολό”.

Μπορεί να φαίνεται μικρό στην αρχή.

Ένα prompt εδώ.
Ένα refactor εκεί.
Ένα “διάβασε αυτά τα 20 αρχεία και βρες το bug”.
Ένα “γράψε tests για όλο το module”.
Ένα “τρέξε ξανά με περισσότερο context”.

Και ξαφνικά, η χρήση αρχίζει να ανεβαίνει.

Όχι επειδή κάποιος έκανε απαραίτητα κάτι λάθος.

Αλλά επειδή το AI είναι εύκολο στη χρήση.

Και ό,τι είναι εύκολο στη χρήση, συνήθως χρησιμοποιείται περισσότερο.

Το CIO αναφέρει ότι οι επιχειρήσεις δυσκολεύονται να προβλέψουν και να ελέγξουν αυτά τα κόστη, γιατί οι AI coding workloads είναι μεταβλητοί και πολλές φορές δεν υπάρχει αρκετή διαφάνεια στον τρόπο που υπολογίζεται και χρεώνεται η κατανάλωση tokens. Επίσης, η Gartner σημειώνει ότι χωρίς σωστό governance, τα κόστη μπορούν να αυξηθούν γρηγορότερα από τα productivity gains που υποτίθεται ότι προσφέρουν τα εργαλεία.

Αυτό είναι σημαντικό.

Γιατί η συζήτηση για το AI δεν μπορεί να μείνει μόνο στο “γράφει πιο γρήγορα κώδικα”.

Πρέπει να πάει και στο:

Πότε αξίζει να το χρησιμοποιώ;

Για τι είδους tasks;

Με πόσο context;

Με τι επίπεδο autonomy;

Με ποιο μοντέλο;

Και πώς μετράω αν όντως με βοήθησε;

Εδώ μπαίνει και κάτι που θεωρώ πολύ κοντά στο developer mindset: context engineering.

Όσο περισσότερο χρησιμοποιώ AI εργαλεία, τόσο περισσότερο καταλαβαίνω ότι δεν είναι μόνο θέμα “καλού prompt”.

Είναι θέμα σωστού context.

Τι του δίνω να διαβάσει.

Τι του ζητάω να αγνοήσει.

Πόσο συγκεκριμένο είναι το task.

Αν του δίνω ολόκληρο το project ενώ χρειάζεται μόνο ένα component.

Αν του ζητάω να λύσει ένα μικρό bug ή αν του πετάω όλο το codebase και του λέω “βρες τι φταίει”.

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

Γιατί, όπως και στα projects, έτσι και στο AI, όσο πιο γενικό είναι το request, τόσο μεγαλύτερο είναι το χάος που μπορεί να παραχθεί.

Το άρθρο του CIO αναφέρει ότι η Gartner προτείνει token thresholds, usage monitoring, escalation policies, use-case driven decision frameworks και διαχωρισμό tasks σε developer-led, developer-with-agent και fully agent-led. Επίσης προτείνει να χρησιμοποιούνται μικρότερα μοντέλα για απλά, συχνά tasks και πιο δυνατά frontier models μόνο όταν η πολυπλοκότητα το απαιτεί.

Αυτό είναι κάτι που προσωπικά το βρίσκω πολύ λογικό.

Γιατί δεν χρειάζεσαι πάντα το πιο δυνατό AI model.

Όπως δεν χρειάζεσαι πάντα Kubernetes για ένα μικρό project.

Όπως δεν χρειάζεσαι πάντα microservices για ένα απλό API.

Έτσι και στο AI, δεν χρειάζεται πάντα να ανοίγεις το μεγαλύτερο context window και να καλείς τον πιο ακριβό agent για κάθε μικρό task.


Το θέμα είναι να ξέρεις τη διαφορά.

Αυτό φέρνει και μια αλλαγή στον ρόλο του developer.

Παλαιότερα έπρεπε να ξέρεις μόνο πώς να γράφεις κώδικα.

Μετά έπρεπε να ξέρεις frameworks, APIs, databases, deployment, cloud, security, testing.

Τώρα προστίθεται και κάτι ακόμα:

Πρέπει να ξέρεις πώς να χρησιμοποιείς AI χωρίς να σπαταλάς χρόνο, χρήμα και context.

Δεν είναι απλώς prompt engineering.

Είναι workflow thinking.

Πότε να σταματήσεις.

Πότε να κάνεις εσύ το debugging.

Και πότε να πεις:

“Οκ, εδώ το AI με δουλεύει.”

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

Αλλά μακροπρόθεσμα μπορεί να χάνεις skill.

Αν όμως το χρησιμοποιείς σαν συνεργάτη, σαν δάσκαλο και σαν εργαλείο έρευνας, τότε μπορεί πραγματικά να σε ανεβάσει επίπεδο.

Payroll, ΑΙ και οι υπόλοιποι