Kuusi kuukautta sitten sain Se oli CTO: lta, loistaa sellaisen kiireellisyyden kanssa, joka tekee koko päiväsi muutokseksi. Tätä "Team, we need an AI strategy! Let's get a smart summarizer on the dashboard. What's the fastest we can get an MVP out with GPT-4o-mini?" Ja tiedätkö mitä? Se oli jännittävää. Mandaatti oli yksinkertainen: "AI kaikessa. Nyt." Kehittäjänä mieleni oli jo kilpaileva. Tiesin, että voisin hakata prototyypin yhteen päivän loppuun mennessä. Kuuden kuukauden kuluessa tiimistäni ja minusta tuli ominaisuuksien tehdas. Lähetimme älykkään hakutuloksen, asiakaspalvelun chatbotin, työkalun käyttäjien palautteiden analysointiin, markkinointivirran generaattorin... yhteensä 15 ominaisuutta. Mutta me emme olleet innovaattoreita. Laitoimme ansaan tulevaisuuden itsellemme. Teimme mitä he pyysivät, mutta nopeus loi vuoren näkymättömiä teknisiä velkoja, jotka melkein maadoittavat koko kehitysjoukkueemme pysähtymään. Osa I: Kuinka olemme haudanneet itsemme tekniseen velkaan Tämä uudenlainen tekninen velka on salakavala. Se ei näytä sotkuiselta koodilta. Se näyttää puhtaalta, yksinkertaiselta ja nykyaikaiselta. Mutta se oli sarja aikapommeja, joista jokainen tikkasi alas kolmen hiljaisen tappajan ansiosta. Virhe #1: Shiny New Toy -oireyhtymä Hullu kiire, saimme mitä tahansa työkalua oli uusin tai helpoin. Yhteenveto, menimme OpenAI, koska kaikki puhuivat siitä. Chatbot, toinen joukkue oli jo pelannut Anthropic, joten käytimme sitä. Yksinkertainen käännös ominaisuus, joku löysi jotain epäselvää API, joka oli likaa halpaa. Meillä ei ollut suunnitelmaa, ei strategiaa - vain halu nopeutta. Yksilöllisesti kunkin ominaisuuden koodi näytti hyvältä. Mutta kun zoomit ulos, se oli puhdasta kaaosta. Olemme kamppailleet muutamien eri API-avainten, erilaisten SDK:ien ja erilaisten laskujen kanssa. Kun käyttäjä valitti, että yhteenvedot olivat hitaita, koko tutkimus käynnistyi vain selvittääkseen, kumpi puoli tusinaa myyjää pudotti pallon. Todellinen kipu osui kolmeen kuukauteen, kun yksi tärkeimmistä palveluntarjoajistamme päätti kaksinkertaistaa hinnat yön yli. Sen vaihtaminen ei ollut nopea ratkaisu. Virhe #2: Hauraat vauhdit ja "Kenen me syytämme?" -peli Käsittelimme kehotuksiamme ikään kuin ne olisivat vain toinen rivi konfig-tiedostossa. He eivät olleet. Ne olivat hauraita, kuiskaavia ehdotuksia koneelle, jota emme ymmärtäneet. Palautteen yhteenvetoajalle meillä oli kehotus, joka tuntui taideteokselta: Se toimi kuin charmia. Summarize the following user feedback into a single, positive-sounding sentence. Eräänä tiistaina se ei ollut. API-palveluntarjoaja oli työntänyt hiljaisen päivityksen malliinsa. Ilman varoitusta "positiivisen äänen" tiivistelmämme alkoivat kuulostaa ... sarkastisilta. Koko ominaisuutemme logiikka oli rikki, mutta mikään rivi koodistamme ei ollut muuttunut. Ei linteriä, ei staattista analyysiä, mikään ei olisi voinut varoittaa meitä. Asiakas valittaisi outoa, tuotemerkin ulkopuolista yhteenvetoa. Mitä minun pitäisi tehdä? Et voi tarttua suljetun lähdekoodin LLM: n sisään. Et voi nähdä, mitä tapahtuu. Päivittäisestä rutiinistani tuli turhauttava arvaus: 
 
 
 
 Okei, yritetään uudelleen sanoittaa se kymmenennen kerran... Onko se käyttäjän syöttö? Ehkä he kirjoittivat jotain outoa... edge case? Onko API:lla vain huono päivä? Aika tarkistaa tilasivu uudelleen... Tämä ei ole tekniikkaa. Se on nykyajan arvailua. Olin kiinni ominaisuudesta, jonka aivot olivat täydellinen musta laatikko. Virhe #3: Käytä Nuke tappaa lentäjä Tämä yksinkertainen API-puhelu oli tyhjä tarkistus, ja kirjoitimme ne kuin hullu. Yksi sisäisistä työkaluistamme - vain tukipyyntöjen luokittelu - käytimme yhtä suurista, yleiskäyttöisistä malleista. Lopulta tajusimme, että käytämme super-älykkäämpää ydinvoimaa tappamaan kärpäsen. paljon pienempi, hienostunut, avoimen lähdekoodin malli - vittu, jopa kourallinen Ilmoitukset – olisivat olleet kymmenen kertaa nopeampia ja sata kertaa halvempia. Mutta "Feature Factory" -mallissa kaikki, mikä oli tärkeää, oli saada se ovesta ulos. if/else Osa II: Kaivaa meidän tie ulos Noin kuuden kuukauden kuluttua asiat alkoivat hajota. Uuden ominaisuuden työntäminen rikkoisi vanhan ominaisuuden. Kustannuksemme olivat kaikkialla. Ja rehellisesti sanottuna joukkue oli tulipalojen torjunnassa. Meidän täytyi pysähtyä, hengittää ja aloittaa ratkaisun suunnittelu. Vaihe 1: Käynnistämme "Tech Debt Triage" Varasimme kokoushuoneen koko iltapäiväksi, laitoimme kaikki 15 AI-ominaisuutta valkoiseen tauluun ja kaiverrettiin ne kuolleen yksinkertaiseen 2x2-verkkoon. (Varmasti, piirrä tämä valkoisella taululla. Se on peli-muuttaja. Suosittelen yksinkertaisen 2x2 grid-kuvan luomista tässä) 
 
 
 X-Axis: Kuinka paljon tämä merkitsee liiketoiminnalle? Y-Axis: Kuinka paljon teknistä sotkua tämä on? (Low to High) Iltapäivä tuo paljon selkeyttä. 
 
 
 
 Top-Right (High Impact, High Debt): Asiakas chatbot, esimerkiksi. Bottom-Right (Low Impact, High Debt): Se typerä "mielenkiintoinen tosiasia" generaattori kirjautumisen näytöllä. Päätimme tappaa sen. Kaksi muuta neliötä: Päätimme jättää ne yksin. Jos se ei ole rikki, älä korjaa sitä. Vaihe 2: Rakensimme keskitetyn "AI Gateway" Rakensimme yhden yksinkertaisen sisäisen palvelun, johon kaikki muut sovelluksemme puhuvat.Tämä "portti" on nyt ainoa asia järjestelmässä, joka puhuu ulkopuolisten AI-tuottajien kanssa. . (Yksinkertainen kaavio on täydellinen täällä: [Our App] -> [Our AI Gateway] -> [OpenAI, Anthropic jne.]) Se antoi meille heti voimansa takaisin. 
 
 
 
 Valvonta: Voimme vaihtaa palveluntarjoajia yhdessä paikassa ilman, että mikään muu sovellus tietää. Säästöt: Rakensimme yksinkertaisen välimuistijärjestelmän suoraan porttiin. Sanity: Kaikki logging, seuranta ja hälytykset ovat nyt yhdessä, hallittavassa paikassa. Vaihe 3: Me Teimme ”Prompt Library” Rakensimme heille yksinkertaisen kirjaston - se on todella vain taulukko tietokannassa, jonka historiaa seurataan Gitissä - joka tallentaa jokaisen käyttämämme pyynnön. Nyt sovelluksemme vain pyytävät kirjastolta oikeaa kehotusta ennen puhelun tekemistä.Tämä lopulta erottaa "mitä sanoa" "miten sanoa se".Tuotepäällikömme voivat nyt säätää ja testata kehotuksia sydämensä sisältöön, eikä heidän tarvitse jättää teknistä lippua tekemään niin. Kyseessä on pitkä peli Katso, paine "lisätä AI" kaikkeen ei mene pois. Mutta meillä on valinta. Voimme pitää funktioita yhdessä hallitsemamme API: n yläpuolella, rakentamalla tulevaisuuden tuotteita, jotka ovat kalliita ja mahdottomia ylläpitää. Tai voimme tehdä todellista, joskus hitaampaa työtä. Uusi sääntö on yksinkertainen: arvioimme jokaista uutta ominaisuutta paitsi sen mukaan, mitä se pystyy tekemään, myös sen ominaisuuksien perusteella. Käsittelemällä velkamme ja rakentamalla nämä ohjauskerrokset olemme lopettaneet toimeksiantojen vastaanottamisen ominaisuustehtaassa. long-term cost of ownership. Peli ei ole vain AI. Kyseessä on Lopetetaan tehtaan ruokkiminen ja aloitetaan sellaisten asioiden rakentaminen, jotka kestävät. käyttämällä Omistaminen So, what's the worst AI tech debt you've stumbled into? I want to hear your war stories in the comments.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Contact Us Today at sales@saigontechnology.com

Drop me a message at 

Read My Stories

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Liian pitkä; Lukea

Get Free Unlimited IP Geo Data With IPinfo Lite

Olen poistanut 15 AI-ominaisuutta 6 kuukaudessa ja se melkein rikkoi meidät.

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

2.5 Reasons to Watch HackerNoon's Self-made Documentary

Spaghetti

About Bitcoin And “Web 2.5,” HackerNoon’s First Documentary

2.5 Reasons to Watch HackerNoon's Self-made Documentary

Spaghetti

About Bitcoin And “Web 2.5,” HackerNoon’s First Documentary

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps