Ensinnäkin he käyttivät ChatGPT:tä kustannusten leikkaamiseen. Sitten he palkkasivat meidät siivoamaan AI:n teknistä velkaa.

Philip Tihonovich

Toukokuu 29, 2025 10 min lukea

Olisit yllättynyt, kuinka monet yritykset tekevät tätä nykyään.

Kuten eri puolilta alaa saadut raportit osoittavat, AI:n tuottamien koodivirheiden korjaamiseen keskittyville insinööreille on nyt kasvava erikoisala.

Kaavasta on tullut huomattavan johdonmukainen. Yritykset kääntyvät ChatGPT:n puoleen luodakseen migraatioskriptejä, integraatioita tai kokonaisia ominaisuuksia toivoen säästävänsä aikaa ja leikkaavansa kustannuksia. Teknologia vaikuttaa loppujen lopuksi nopealta ja helppokäyttöiseltä.

Sitten järjestelmät epäonnistuvat.

Ja he soittavat meille.

Viime aikoina olemme saaneet yhä enemmän tällaisia pyyntöjä. Emme ole toimittaneet uutta tuotetta, vaan pyrkineet purkamaan sotkun, joka on jäänyt jäljelle sen jälkeen, kun joku on luottanut kielimalliin ja tuotantokoodiinsa.

Tässä vaiheessa se alkaa näyttää omalta kapealta toimialaltaan. AI:n tuottamien virheiden korjaaminen on nyt laskutettava palvelu. Ja joissakin tapauksissa erittäin kallis sellainen.

GitClearin vuoden 2024 raportti vahvistaa sen, mitä olemme havainneet asiakkaidemme kanssa: AI-koodaustyökalut nopeuttavat toimituksia, mutta myös lisäävät päällekkäisyyksiä, vähentävät uudelleenkäyttöä ja kasvattavat pitkän aikavälin ylläpitokustannuksia.

Eräässä tapauksessa asiakas kääntyi puoleemme, kun AI:n tuottama siirtymä oli pudottanut kriittisiä asiakastietoja. Käytimme 30 tuntia hukattujen tietojen palauttamiseen, logiikan kirjoittamiseen alusta alkaen ja putkiston siivoamiseen. Ironista on se, että olisi ollut halvempaa antaa vanhemman kehittäjän kirjoittaa se vanhanaikaisella tavalla.

Tehdään kuitenkin selväksi, ettemme ole "AI:tä vastaan". Me käytämme sitä myös. Ja se on hyödyllinen oikeassa yhteydessä, oikeiden suojakaiteiden kanssa. Mutta se, mikä minua turhauttaa AI:hen liiallisessa luottamisessa ja sen laajalle levinneissä vaikutuksissa - ja luultavasti sinuakin - on maaginen ajattelu. Ajatus siitä, että kielimalli voi korvata todellisen insinöörityön.

Se ei voi. Ja kuten sanonta kuuluu, todiste on vanukkaassa. Kun yritykset teeskentelevät muuta, ne joutuvat lopulta maksamaan meidän kaltaisillemme siivoamisesta.

Miltä tällainen siivoustyö näyttää? Seuraavassa kerrotaan, mitä AI-afficionados eivät kerro sinulle menetetystä ajasta ja hukkaan heitetyistä rahoista.

Miltä tyypillinen pyyntö näyttää

Viesti tulee yleensä näin:

"Hei, voisitko vilkaista rakentamaamme mikropalvelua?". Käytimme ChatGPT:tä ensimmäisen version luomiseen. Työnsimme sen stagingiin, ja nyt RabbitMQ-jonomme on täysin täynnä."

Se alkaa aina pienestä. Tehtävästä, joka tuntui liian tylsältä tai aikaa vievältä. Esimerkiksi CSV-tiedoston analysointi, cron-työn uudelleenkirjoittaminen tai yksinkertaisen webhookin kytkeminen. Niinpä se annetaan kielimallille ja toivotaan parasta.

Mutta asia on näin: oireet ilmenevät paljon myöhemmin. Joskus päiviä myöhemmin. Ja kun ne ilmenevät, on harvoin selvää, että perussyy oli AI:n tuottama koodi. Se vain näyttää siltä, että jokin on pielessä.

"Arkkitehtuuriajattelua ei voi ulkoistaa kielimallille. AI voi nopeuttaa asioita, mutta tarvitaan silti insinöörejä rakentamaan järjestelmiä, jotka eivät hajoa paineen alla."

Dmitri Nazarevitš

Tekninen johtaja

Kymmenen tällaisen tapauksen jälkeen kuvioita alkaa hahmottua:

Ei testejä. Yhtään. Ei edes helvetinmoista vakuuttelua. Vain raakaa, spekulatiivista koodia, jota ei koskaan harjoitettu kunnolla.
Ei tietoisuutta järjestelmän rajoista. Olemme nähneet ChatGPT-skriptejä, jotka kysyvät kolmea mikropalvelua synkronisesti, eivät ota huomioon aikakatkaisuja ja räjäyttävät koko kutsuketjun ensimmäisestä epäonnistumisesta.
Tapahtumien väärinkäyttö. Eräs asiakas käytti AI:n tuottamaa SQL:ää, jossa oli sisäkkäisiä transaktioita Node.js-palvelun sisällä käyttäen Knexiä. Se toimi, kunnes se ei toiminut, ja puolet kirjoituksista epäonnistui hiljaa.
Hienovaraiset kilpailuolosuhteet. Etenkin monisäikeisissä tai asynkroniikkapainotteisissa koodirakenteissa. Tällaiset virheet eivät näy kehitystyössä, mutta tuhoavat tuotannon mittakaavassa.

Ja tietenkin, kun kaikki romahtaa, AI ei jätä sinulle kommenttia, jossa sanotaan: "Muuten, arvelen tässä".

Se on sinun vastuullasi.

Tapaus 1: Migraatiokomentosarja, joka pudotti hiljaa asiakastiedot pois käytöstä

Tämä tuli nopeasti kasvavalta fintech-yritykseltä.

He olivat ottamassa käyttöön uutta versiota asiakastietomallistaan jakamalla yhden suuren JSONB-kentän Postgresissä useisiin normalisoituihin taulukoihin. Aika tavallista tavaraa. Mutta koska aikataulu oli tiukka ja käsiä ei ollut tarpeeksi, yksi kehittäjistä päätti "nopeuttaa asioita" pyytämällä ChatGPT:tä luomaan siirtoskriptin.

Se näytti päällisin puolin hyvältä. Skripti purki JSON-tiedot, poimi yhteystiedot ja lisäsi ne uuteen user_contacts pöytä.

Niinpä he juoksuttivat sitä.

Ei kuivaharjoittelua. Ei varmuuskopiointia. Suoraan stagingiin, joka, kuten kävi ilmi, jakoi tietoja tuotannon kanssa kopion kautta.

Muutamaa tuntia myöhemmin asiakastuki alkoi saada sähköposteja. Käyttäjät eivät saaneet maksuilmoituksia. Toisten profiileista puuttui puhelinnumeroita. Silloin he soittivat meille.

Mikä meni pieleen

Jäljitimme ongelman käsikirjoitukseen. Se suoritti perusuuttamisen, mutta se teki kolme kohtalokasta oletusta:

Se ei käsitellyt NULL arvoja tai puuttuvia avaimia JSON-rakenteen sisällä.
Se lisäsi osittaisia tietueita ilman validointia.
Se käytti ON CONFLICT DO NOTHING, joten kaikki epäonnistuneet lisäykset jätettiin hiljaisesti huomiotta.

Tulos: noin 18% yhteystiedoista oli joko kadonnut tai vioittunut. Ei lokitietoja. Ei virheilmoituksia. Vain hiljainen tietojen menetys.

Mitä korjaaminen vaati

Lähetimme pienen ryhmän selvittämään sotkua. Teimme näin:

Diagnoosi ja replikaatio (4 tuntia) Loimme skriptin uudelleen hiekkalaatikkoympäristössä ja ajoimme sen tietokannan tilannekuvaa vastaan. Näin varmistimme ongelman ja kartoitimme tarkalleen, mitä puuttui.
Rikostekninen tietojen tarkastus (8 tuntia) Vertasimme rikkinäistä tilaa varmuuskopioihin, tunnistimme kaikki tietueet, joista puuttui tai joissa oli osittaisia tietoja, ja vertasimme niitä tapahtumalokeihin jäljittääksemme, mitkä lisäykset epäonnistuivat ja miksi.
Siirtymislogiikan uudelleenkirjoittaminen (12 tuntia) Kirjoitimme koko skriptin uudelleen Python:llä, lisäsimme täyden validointilogiikan, rakensimme palautusmekanismin ja integroimme sen asiakkaan CI-putkeen. Tällä kertaa se sisälsi testit ja kuivakäyttötuen.
Manuaalinen tietojen palauttaminen (6 tuntia) Joitakin tietueita ei voitu palauttaa varmuuskopioista. Haimme puuttuvat kentät ulkoisista järjestelmistä (heidän CRM- ja sähköpostipalvelun tarjoajan sovellusliittymistä) ja palautimme loput manuaalisesti.

Kokonaisaika: 30 tuntia

Kaksi insinööriä, kolme päivää. Kustannukset asiakkaalle: noin $4,500 palvelumaksut.

Suurempi isku tuli kuitenkin asiakkaiden aiheuttamista ongelmista. Epäonnistuneet ilmoitukset johtivat maksamatta jääneisiin maksuihin ja asiakaspoistumisiin. Asiakas kertoi käyttäneensä ainakin $10,000 tukipyynnöistä, SLA-kompensaatioista ja hyväntahtoisuushyvityksistä, jotka johtuvat yhdestä epäonnistuneesta käsikirjoituksesta.

Ironista on se, että vanhempi kehittäjä olisi voinut kirjoittaa oikean migraation ehkä neljässä tunnissa. Mutta lupaus AI-nopeudesta maksoi heille lopulta kaksi viikkoa siivousta ja maineen vahingoittumista.

Korjaamme sen, minkä ChatGPT rikkoi - ja rakennamme sen, mitä se ei pystynyt.

Tapaus 2: API-asiakas, joka jätti huomiotta nopeusrajoitukset ja rikkoi tuotannon.

Tämä tuli lakiasiainteknologian alan startup-yritykseltä, joka kehittää asiakirjojen hallintaympäristöä asianajotoimistoille. Yksi heidän keskeisistä ominaisuuksistaan oli integroituminen hallituksen sähköisen ilmoituspalvelun kanssa - kolmannen osapuolen REST API OAuth 2.0:lla ja tiukalla nopeusrajoituksella: 50 pyyntöä minuutissa, ei poikkeuksia.

Sen sijaan, että integraatio olisi annettu kokeneen backend-palvelun kehittäjän tehtäväksi, joku tiimin jäsenistä päätti "prototyypittää" sen ChatGPT:n avulla. He lisäsivät OpenAPI-spesifikaation, pyysivät Python-asiakasta ja saivat siistin näköisen skriptin, jossa oli seuraavat ominaisuudet requests, uusintalogiikka käyttäen tenacity, ja tokenin päivitys.

Näytti paperilla vakaalta. Joten he lähettivät sen.

Mikä meni pieleen

Aluksi kaikki näytti olevan hyvin. Asiakas käsitteli yksittäiset pyynnöt oikein, läpäisi todennuksen ja jopa yritti uudelleen, jos pyyntö epäonnistui. Mutta todellisessa käytössä, erityisesti kuormitettuna, alusta alkoi käyttäytyä arvaamattomasti.

Näin todella tapahtui:

Ei kunnioiteta hintarajoja. Generoitu koodi ei lukenut tai tulkinnut X-RateLimit-Remaining tai Retry-After otsikot. Se vain jatkoi pyyntöjen lähettämistä sokeasti.
Uusintayritykset pahensivat tilannetta. Kun 429-virheitä alkoi tulla takaisin, sitkeyskorjain yritti niitä automaattisesti uudelleen. Ei jitteriä. Ei jonotusta. Vain jatkopyyntöjen tulva.
API-palveluntarjoaja on tilapäisesti estänyt heidän IP-osoitteensa. Kolmeen tuntiin kukaan alustalla ei pystynyt synkronoimaan asiakirjoja. Ei lokitietoja, ei hälytyksiä. Vain hiljainen epäonnistuminen.

Tämä ei ollut yhden rivin korjaus. Se oli väärinkäsitys siitä, miten tuotantojärjestelmät käyttäytyvät. Ja se on hyvä esimerkki siitä, mitä LLM:t eivät tiedä; ei siksi, että ne olisivat rikki, vaan siksi, että niillä ei ole ajotietoisuutta.

Lopeta AI:n tuottaman koodin korjaaminen prodissa - ota meidät mukaan, ennen kuin se hajoaa.

Miten korjasimme sen

Vian jäljittäminen ja eristäminen (6 tuntia) Lisäsimme väliohjelmiston, joka tarkastaa lähtevän liikenteen, ja vahvistimme pyyntöjen tulvan huippukäytön aikana. Loimme myös vian uudelleen staging-tilassa, jotta ymmärtäisimme täysin laukaisevan mallin.
API-asiakasohjelman uudelleenrakentaminen (10 tuntia) Kirjoitimme asiakkaan uudelleen käyttämällä httpx.AsyncClient, toteutti semafooripohjaisen kuristimen, lisäsi eksponentiaalisen backoffin ja jitterin ja käsitteli asianmukaisesti seuraavia asioita. Retry-After ja nopeusrajoitusotsikot.
Rasitustesti ja validointi (6 tuntia) Simuloimme Locustin avulla reaalimaailman käyttöä tuhansilla samanaikaisilla pyynnöillä, testasimme nopeuden rajoittamista erilaisissa purskeissa ja vahvistimme, että jatkuvassa kuormituksessa ei ole 429 sekuntia.
Seurannan ja hälytysten lisääminen (4 tuntia) Asetimme mukautettuja Prometheus-mittareita API-käytön seuraamiseksi minuutissa ja lisäsimme hälytyksiä, jotka ilmoittivat tiimille, jos he lähestyivät nopeuskynnyksiä.

Kokonaisaika: 26 tuntia

Kaksi insinööriä kahden ja puolen päivän aikana. Kustannukset asiakkaalle: noin $3,900.

Suurempi ongelma on se, että heidän suurin asiakkaansa - lakiasiaintoimisto, jonka arkistoinnille on tärkeää aikaa - ei päässyt kahteen oikeuteen jättämisikkunaan katkoksen vuoksi. Asiakkaan oli tehtävä vahinkojen torjuntaa ja tarjottava alennusta säilyttääkseen asiakkaan.

Kaikki tämä siksi, että kielimalli ei ymmärtänyt eroa "toimivan koodin" ja "tuotantokelpoisen koodin" välillä. Ja aivan kuten siinä kävi, pinoon lisättiin hiljaa toinen kerros AI:n teknistä velkaa.

Miksi näin tapahtuu jatkuvasti

Pelottavaa ei ole se, että nämä asiat menevät pieleen. vaan se, miten ennalta arvattavaksi kaikki on muuttumassa.

Jokainen näistä tapauksista noudattaa samaa kaavaa. Kehittäjä pyytää ChatGPT:ltä koodinpätkää. Se palauttaa jotain, joka toimii juuri niin hyvin, ettei se aiheuta virheitä. Hän liittää sen järjestelmään, siistii sitä ehkä hieman ja lähettää sen olettaen, että jos se kääntyy ja toimii, sen on oltava turvallinen.

Mutta tässä on juju: Suuret kielimallit eivät tunne järjestelmääsi.
He eivät tiedä, miten palvelusi ovat vuorovaikutuksessa keskenään.
He eivät tunne latenssibudjettiasi, käyttöönottoputkiasi, havainnointiasetuksiasi tai tuotantoliikennemalleja.

Ne luovat todennäköisimmältä näyttävän koodin harjoitusdatan mallien perusteella. Siinä kaikki. Tietoisuutta ei ole. Ei takuita. Ei intuitiota järjestelmän suunnittelua varten.

Tuotos heijastelee sitä usein:

Koodi, joka toimii kerran, mutta epäonnistuu kuormituksessa.
Ei suojaavaa ohjelmointia, ei vikasietoisuutta.
Huono ymmärrys reaalimaailman rajoituksista, kuten nopeusrajoituksista, aikakatkaisuista tai mahdollisesta johdonmukaisuudesta.
Arkkitehtonisen tarkoituksen tuntu on täysin olematon

Vielä pahempaa on se, että koodi näyttää oikealta. Se on syntaktisesti puhdas. Se läpäisee linterit. Se saattaa jopa kuulua perustestin piiriin. Mutta siitä puuttuu se yksi asia, jolla on oikeasti merkitystä: konteksti.

Siksi nämä viat eivät näy heti. Ne odottavat perjantai-illan käyttöönottoja, vilkkaasti liikennöityjä ikkunoita ja harvinaisia ääritapauksia. Tämä on AI:n teknisen velan luonne - se on näkymätöntä, kunnes se rikkoo jotain kriittistä.

Kun AI todella auttaa

Kuten aiemmin mainitsimme, myös me käytämme AI:tä. Lähes jokaisella tiimimme insinöörillä on paikallisesti käytössä Copilotin kaltainen asennus. Se on nopea, hyödyllinen ja rehellisesti sanottuna loistava tapa ohittaa tylsät kohdat.

Mutta tässä on ero: mikään ei päädy päähaaraan ilman, että se käy läpi vanhemman insinöörin ja useimmissa tapauksissa CI-putken, joka tietää, mitä etsiä.

LLM:t ovat loistavia:

uusien palveluiden tai API-päätepisteiden rakennuspohjat,
olemassa olevan logiikan testikattavuuden luominen,
auttaa suurten koodikantojen toistuvassa refaktoroinnissa,
yksinkertaisten komentosarjakomentosarjojen kääntäminen infrastruktuuri-ohjelmointimalleiksi,
tai jopa vertailemalla algoritmisia lähestymistapoja, jotka me jo ymmärrämme.

Mitä he ovat ei hyvä suunnittelussa. Tai kontekstissa. Tai turvallisissa oletusarvoissa.

Siksi olemme rakentaneet työnkulut siten, että LLM-tuloksia käsitellään ehdotuksina, ei totuuden lähteenä. Seuraavassa on, miltä se näyttää käytännössä:

Merkitsemme kaikki AI:n tuottamat komitukset, jotta ne on helppo jäljittää ja tarkistaa.
Toimittajillamme on rivikehotukset, mutta pakotetuilla pre-commit-koukuilla, jotka estävät kaiken, mitä ei ole testattu tai dokumentoitu.
CI:ssämme on staattisen analyysin sääntöjä, jotka merkitsevät turvattomia malleja, joita olemme nähneet LLM:ssä aiemminkin: esimerkiksi vartioimattomia uusintayrityksiä, rajaamattomia aikakatkaisuja, naiivia JSON-jäsennyksiä tai vaarallista SQL-käsittelyä.
Jokainen LLM:n tuottamaa koodia sisältävä vetopyyntö käy läpi pakollisen inhimillisen tarkistuksen, jonka suorittaa yleensä joku vanhempi henkilö, joka ymmärtää toimialueen logiikan ja riskipinnan.

Oikein käytettynä se säästää aikaa. Sokeasti käytettynä se on aikapommi.

Mitä suosittelemme teknologiajohtajille

Emme ole täällä käskemässä sinua kieltämään AI-työkaluja. Se laiva on lähtenyt.

Mutta kielimallille annetaan oikeus sitoutua? Se vain aiheuttaa ongelmia.

Sen sijaan suosittelemme seuraavaa:

1. Kohtele LLM:tä kuin työkaluja, ei insinöörejä.

Anna heidän auttaa toistuvan koodin kanssa. Anna heidän ehdottaa ratkaisuja. Mutta älä luota heihin kriittisiä päätöksiä. Kaiken AI:n tuottaman koodin on oltava vanhemman insinöörin tarkistama, ei poikkeuksia.

2. LLM:n tuottaman koodin jäljitettävyys

Olipa kyse sitten commit-tagista, metatiedoista tai koodin kommenteista, tehdään selväksi, mitkä osat ovat peräisin AI:stä. Tämä helpottaa tarkastusta, virheenkorjausta ja riskiprofiilin ymmärtämistä myöhemmin.

3. Määrittele sukupolvipolitiikka

Päättäkää tiiminä, missä LLM:n käyttö on hyväksyttävää ja missä ei. Boilerplate? Toki. Auth flows? Ehkä. Transaktiojärjestelmät? Ei missään nimessä ilman tarkistusta. Tehdään politiikasta selkeä ja osa teknisiä standardeja.

4. Lisää DevOps-tason valvonta

Jos annat AI:n tuottaman koodin koskettaa tuotantoa, sinun on oletettava, että jokin menee lopulta rikki. Lisää synteettisiä tarkistuksia. Nopeusrajoitusvalvontalaitteet. Riippuvuuksien seuranta. Tee näkymätön näkyväksi, varsinkin kun alkuperäinen kirjoittaja ei ole ihminen.

5. Rakenna palautettavuutta varten

Suurimmat näkemämme AI:n aiheuttamat epäonnistumiset eivät johtuneet "huonosta" koodista. Ne johtuivat hiljaisista virheistä - puuttuvista tiedoista, rikkoutuneista jonoista, uusintakokeilumyrskyistä - jotka jäivät tuntikausia havaitsematta. Panosta tarkkailtavuuteen, varalogiikkaan ja palautuksiin. Varsinkin jos annat ChatGPT:n kirjoittaa siirtymiä.

Lyhyesti sanottuna AI voi säästää tiimisi aikaa, mutta se ei voi ottaa vastuuta.

Se on edelleen ihmisen työtä.

Loppuajatukset: ≠ ohjelmistoinsinöörit: AI ≠ ohjelmistosuunnittelijat

AI voi auttaa sinua liikkumaan nopeammin. Mutta se ei voi ajatella puolestasi.

Se ei ymmärrä arkkitehtuuria. Se ei tiedä, mitä "done" tarkoittaa sinun kontekstissasi. Eikä se todellakaan välitä siitä, että dataputkesi katkeaa hiljaa perjantai-iltana.

Siksi meidän teknologiajohtajina on keskityttävä järjestelmän häiriönsietokykyyn, ei pelkästään nopeuteen.

On houkuttelevaa antaa AI:n hoitaa tylsät osat. Ja joskus se on ihan hyvä. Mutta jokainen oikotie on kompromissi. Kun AI:n tuottama koodi lipsahtaa läpi tarkastamatta, siitä tulee usein AI:n teknistä velkaa. Sellaista, jota ei huomaa ennen kuin ops-tiimisi joutuu sammuttamaan sitä tuotannossa.

Jos olet jo törmännyt tähän seinään, et ole yksin. Olemme auttaneet tiimejä toipumaan kaikista mahdollisista ongelmista, jotka ovat ulottuneet rikkinäisistä migraatioista API-katastrofeihin. Emme vain muokkaa koodia. Autamme uudistamaan sen taustalla olevaa ajattelua.

Sillä loppujen lopuksi juuri se tekee järjestelmistä luotettavia.

Philip Tikhanovich

Pää Python-, Big Data-, ML/DS/AI-osaston johtaja

Philip keskittyy terävästi kaikkeen dataan ja AI:hen. Hän kysyy oikeat kysymykset jo varhaisessa vaiheessa, luo vahvan teknisen vision ja varmistaa, ettemme vain rakenna älykkäitä järjestelmiä - vaan oikeat järjestelmät, jotka tuottavat todellista liiketoiminta-arvoa.

Lue lisää

Sisällysluettelo

Ota yhteyttä

Varaa puhelu tai täytä alla oleva lomake, niin otamme sinuun yhteyttä, kun olemme käsitelleet pyyntösi.

Nimi

Yritys

Sähköposti

Puhelin

Viesti

Lähetä meille ääniviesti

Liitä asiakirjoja

Lataa tiedosto

Voit liittää 1 enintään 2 Mt:n tiedoston. Hyväksytyt tiedostomuodot: pdf, jpg, jpeg, png.

Klikkaamalla Lähetä, annat suostumuksesi siihen, että Innowise käsittelee henkilötietojasi meidän Tietosuojakäytäntö antaa sinulle asiaankuuluvia tietoja. Antamalla puhelinnumerosi suostut siihen, että voimme ottaa sinuun yhteyttä puheluiden, tekstiviestien ja viestisovellusten kautta. Puhelu-, viesti- ja datahintoja voidaan soveltaa.

Voit myös lähettää meille pyyntösi
osoitteeseen contact@innowise.com

Mitä tapahtuu seuraavaksi?

Kun olemme vastaanottaneet ja käsitelleet pyyntösi, otamme sinuun yhteyttä ja kerromme yksityiskohtaisesti projektin tarpeet ja allekirjoitamme NDA-sopimuksen luottamuksellisuuden varmistamiseksi.

Tutkittuaan toiveesi, tarpeesi ja odotuksesi tiimimme suunnittelee projektin ehdotuksen, jossa esitetään työn laajuus, tiimin koko, aika- ja kustannusarviot.

Järjestämme kanssasi tapaamisen, jossa keskustellaan tarjouksesta ja sovitaan yksityiskohdista.

Lopuksi allekirjoitamme sopimuksen ja aloitamme projektisi toteuttamisen heti.