Garatzaileon rola abiadura sinestezinean aldatzen ari da. Niri behintzat, azken urtean bizitza aldatu dit nire lan egiteko moduak. Eta ez naiz lanaren etorkizunari buruzko teoria abstraktuez ari; nire haragian bizi izan dudan errealitate bat da, nire proiektu pertsonalak nola garatu nituen alderatzean: maps.eus eta ai.maps.eus.
Hasierako puntua: Kulturmapsetik benetako azpiegiturara
maps.eus-en lehen bertsioarekin hasi nintzenean, helburua xumea zen: Kulturmaps atala sortu nahi nuen Open Data Euskadi lehiaketara aurkezteko. Garai hartan, ez nekien PostGIS edo datu-base espazialak existitzen zirenik ere. Garapen guztia super artisaua izan zen, ikuspegi eta modelo bakoitza eskuz idatziz.
Une horretan, AIa bilatzaile azkar bat baino ez zen nabigatzaileko fitxa batean, sintaxi zalantza zehatzat argitzeko, StackOverflow-ra jotzea bezala. Nik idazten nuen lerro bakoitza eta banekien zehazki koma bakoitza nora zihoan. Azkenean, nire muga fisikoa kode lerro bakoitza idazteko abiadura zen.
Jauzi kualitatiboa: proiektua hutsetik berreraikitzea AIarekin IDEan
Aldaketa handia iazko urte amaieran hasi zen, proiektua hutsetik berreraikitzea erabaki nuenean, Gemini zuzenean nire garapen ingurunean (IDE) erabiliz. AIa bilatzaile soil bat izatetik ikaskuntza kide aktibo izatera igaro zen. Izan ere, AIak berak proposatu zidan azpiegitura hobe bat erabiltzea (PostGIS bezala) eta urratsez urrats inplementatzen lagundu zidan.
AIa nire mugak zabaltzen, tresna berriak ikasten eta nire bizikleta ibilaldietan erabiltzen ditudan aplikazioak barnetik nola funtzionatzen duten ulertzen laguntzen ari zait. Elkarrekin hau egiteko gai izan ginen:
- Datu-base espazial osoa muntatu, ibilbideak kalkulatzeko errepide-sareak nola modelatu daitezkeen ikasiz.
- OpenStreetMapeko datu konplexuak prozesatu eta inportatu.
- Azpiegitura guztia Docker edukiontziekin konfiguratu (Celery atzeko lanetarako eta Redis katxerako), lehen saiakuntza-errore bidez egunak edo asteak eramango zizkidan zerbait.
Ondorioz, bikepacking ibilbideak sortzeko eta bistaratzeko motor osoa altxatu dut, ia kode lerrorik eskuz idatzi gabe.
Erronka berria: kodea kontrolpetik ez ihes egitea
Kodea azkar sortzea oso ondo dago, pero benetako arriskua kontrola galtzea eta inork ulertzen edo mantentzen ez duen "kutxa beltz" batekin amaitzea da. Hori dela eta, nire lan egiteko modua erabat aldatu da:
- Arkitektura hobeto diseinatu eta modularizatu: Kode sorkuntza desantolatu ez dadin, funtsezkoa da goi-mailako diseinua eta proiektua modulutan nola egituratu argi izatea AIari ezer eskatu aurretik. Ez da lan erraza, batez ere AIak fitxategi askotan aldaketa pila bat proposatzen dituenean aldi berean. Egunero topatzen ditugu zailtasun berriak eta hobetzeko moduak bilatzen ari gara.
- Ikuskaritza eta berrikuspenaren ikasketa (Code Review): Lehen eskuz egindako aldaketa txikiak berrikusten bagenituen, orain AI agente batek dozenaka fitxategi alda ditzake une batean. Oraindik ez gara gai sortzen den guztia modu kritikoan eta segurtasun osoz irakurtzeko. AIarekin elkarlanean ikasen ari gara eta sortutako kodea fidagarria izateko metodoak bilatzen ditugu: Specs-Driven Development probatzen ari gara, sortutako kodearen gainean testak definitzen, AI bera kodea modu interaktiboan dokumentatzeko erabiltzen eta tresna berriak ikasten, hala nola OpenSpec.
- Testak eta CI/CD automatizatu: AIak sortutako kodean itsu-itsuan fidatzea suarekin jolastea da. Lasai egoteko, gakoa gure integrazio jarraituko (CI/CD) pipelinea ahalik ahalik eta gehien indartzea da. AIak testak sortzen laguntzen digu, baita segundotan ezer hautsi ez dela egiaztatuko duten auditoretza automatikoko gidoiak prestatzen ere.
Proiektu pertsonalak vs. benetako inguruneak
Proiektu pertsonalak eta laborategiak leku bikainak dira eredu hauekin jolasteko eta zer egiteko gai diren ikusteko (Claude adibidez, nire ustez Gemini baino kode irtenbide sendoagoak eta koherenteagoak ematen dituena). Hor, hanka sartzea jokoaren parte da.