Tuotantokehotteiden suunnittelu: järjestelmä-, kehittäjä- ja käyttäjäkerrokset

Prototyypissä kehote on eräänä iltapäivänä kirjoittamasi merkkijono. Tuotannossa tämä lähestymistapa hajoaa jo suunnilleen ensimmäisen kuukauden aikana.

Haluat muuttaa yhtä ohjeiden osaa mutta et muita. Haluat eri asiakastasoille erilaista toimintaa. Haluat A/B-testata versioita. Haluat palauttaa aiemman version, kun jokin rikkoutuu. Haluat tietää, milloin kehotetta muutettiin viimeksi ja miksi.

Tuotantokäyttöön tarkoitettu kehotejärjestelmä käsittelee kaiken tämän. Kyse ei ole ”merkkijonon kirjoittamisesta” vaan arkkitehtuurista.

Tässä artikkelissa käsitellään arkkitehtuurin kolme kerrosta, mallipohjien käyttöön liittyvä kuri, versionhallinta, arviointi ja operatiiviset käytännöt, jotka muuttavat kehotteet yksittäisistä artefakteista infrastruktuuriksi.

Tuotantokehotteisiin liittyvässä työssä on kaksi erillistä artefaktia: uudelleenkäytettävät mallipohjat ja pyyntökohtaiset tiedot. Versioi mallipohjat kuten koodi. Käsittele muodostettuja kehotteita ja mallien vastauksia arkaluonteisina lokeina aina, kun ne sisältävät käyttäjä-, asiakas- tai sisäisiä tietoja.

Kolme kerrosta

Tuotantokehotteissa on kolme erillistä kerrosta, joista jokaisella on omat huolenaiheensa:

Järjestelmäkerros. Vakaa toiminta, identiteetti ja rajoitteet. Muuttuu harvoin. Omistajana on tekoälyn toimintaa suunnitteleva tiimi.

Kehittäjäkerros. Ominaisuuskohtaiset ohjeet, työkalukuvaukset ja tuotosmuotovaatimukset. Muuttuu ominaisuuksien mukana. Omistajana on ominaisuudesta vastaava tiimi.

Käyttäjäkerros. Käyttäjän yksittäinen pyyntö sekä dynaaminen konteksti, kuten käyttäjän tiedot, keskusteluhistoria ja haettu tieto. Muuttuu jokaisella kutsulla.

Näiden sekoittaminen on tuotantokehotteiden yleisin virhe. Järjestelmäkehote kasvaa 5,000 sanan kokonaisuudeksi, jossa identiteetti, ominaisuusohjeet ja dynaaminen konteksti ovat sekaisin. Tällöin yhden asian muuttaminen rikkoo muita.

Kerrosten erottaminen on perusta:

┌─────────────────────────────────────┐
│ System prompt (stable)              │  Identity, behavior, hard constraints
├─────────────────────────────────────┤
│ Developer prompt (per-feature)      │  Feature instructions, tools, format
├─────────────────────────────────────┤
│ User prompt (per-call)              │  User query, context, conversation
└─────────────────────────────────────┘

Mallirajapinnat tukevat erottelua suoraan:

• OpenAI: roolit system, developer ja user.
• Anthropic: system, jonka jälkeen messages sisältää user- ja assistant-roolit. Työkalukuvaukset annetaan erillisenä parametrina.
• Gemini: systemInstruction, jonka jälkeen annetaan roolit sisältävä contents.

Käytä erottelua tarkoituksellisesti.

Kerros 1: järjestelmäkehote

Järjestelmäkehote määrittää, kuka tekoäly on ja miten se toimii. Se muuttuu harvoin.

Hyvä järjestelmäkehote käsittelee:

Identiteetin. Kuka tekoäly on. ”Olet [yrityksen] tekoälyavustaja, joka on erikoistunut [alaan].”

Äänensävyn ja tyylin. Miltä sen pitäisi kuulostaa. Käytä täsmällisiä ominaisuuksia epämääräisten kuvausten sijaan.

Ehdottomat rajoitteet. Asiat, joita se ei saa koskaan tehdä: tietyn sisällön tuottaminen, tiettyjen päätösten tekeminen tai tiettyjen ohjeiden sivuuttaminen.

Toimintamallit. Miten se käsittelee tavallisia tilanteita, kuten kieltäytymistä, eskalointia ja epävarmuutta.

Turvallisuuden ja vaatimustenmukaisuuden. Pakolliset ilmoitukset, sääntelyä koskevat säännöt ja sisältökäytännöt.

Mitä sen EI pitäisi sisältää:

• Ominaisuuskohtaisia ohjeita (”tee myyntisähköposteissa X”).
• Dynaamista kontekstia (”käyttäjän tilaushistoria on…”).
• Työkalukuvauksia, jotka kuuluvat muualle.
• Usein muuttuvia asioita.

Hyvä järjestelmäkehote on 300-1000 sanaa pitkä. Pidempi on vaikea hallita, ja lyhyempi määrittää toiminnan puutteellisesti.

Toimiva mallipohja:

You are [name], an AI assistant for [company / context].

## Your role
[2-3 sentences on what you do]

## Voice and style
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Do not [anti-pattern 1]
- Do not [anti-pattern 2]

## Hard constraints
- Never [hard rule 1]
- Never [hard rule 2]
- Always [hard rule 3]

## How to handle uncertainty
- If you don't know something factual: say so explicitly.
- If a user asks for something outside scope: offer what you can help with.
- If a request might cause harm: refuse and explain why.

## Format expectations
- Plain text by default
- Use markdown when displaying code or structured data
- Be concise; do not pad responses with filler

Tämä on kokonaisuuden selkäranka. Jokainen vuorovaikutus kulkee sen läpi. Muutokset tehdään harkiten ja harvoin.

Kerros 2: kehittäjäkehote

Kehittäjäkehote on ominaisuuskohtainen. Eri ominaisuuksilla on eri kehittäjäkehotteet.

Tiivistysominaisuuden kehittäjäkehote:

Task: produce a summary of the document below.

Requirements:
- 3-5 bullet points
- Each bullet is one complete sentence
- Focus on facts and concrete claims, not impressions
- If the document contains numbers, include the most important ones
- Do not include marketing language or speculation
- If the document is ambiguous about something important, note it

Format: plain markdown bullets, no preamble.

Koodikatselmointiominaisuuden kehittäjäkehote:

Task: review the code diff below.

Output a JSON object with:
- summary: 1-2 sentence overview of the change
- concerns: array of specific issues (each: file, line, severity, description)
- suggestions: array of improvements (each: file, line, suggestion)
- approved: boolean (true if no blocking concerns)

Severity levels:
- "blocker": must be fixed before merge
- "warning": should be addressed but not blocking
- "nit": stylistic, optional

Focus on:
- Logic errors
- Security issues
- Performance issues
- Missing test coverage
- Unclear naming or structure

Skip:
- Formatting (handled by formatter)
- Subjective style preferences

Jokaisella ominaisuudella on oma kehittäjäkehotteensa. Ne tallennetaan, versioidaan ja arvioidaan erikseen.

Kerros 3: käyttäjäkehote

Käyttäjäkerros on dynaaminen. Se sisältää tavallisesti:

Käyttäjän varsinaisen pyynnön. ”Tiivistä tämä asiakirja.”

Järjestelmän hakeman kontekstin. RAG-järjestelmän asiakirjat, asiakashistorian ja keskusteluhistorian.

Kutsukohtaiset muuttujat. Käyttäjän nimen, aikavyöhykkeen, kielivalinnan ja asiakastason.

Kerros muodostetaan ohjelmallisesti kutsun aikana. Rakenne näyttää tavallisesti tältä:

{conversation_history_summary}

{retrieved_context}

User's request: {user_query}

Additional context:
- User name: {name}
- User timezone: {timezone}
- User tier: {tier}

Tarkka rakenne riippuu ominaisuudesta. Periaate on, että tiedot kuuluvat tähän kerrokseen eivätkä järjestelmä- tai kehittäjäkehotteisiin.

Mallipohjien hallinta

Tuotantokehotteet rakennetaan mallipohjista. Merkkijonojen yhdistäminen suoraan koodissa on prototyyppitapa, joka ei skaalaudu.

Yksinkertainen mallipohjajärjestelmä:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

Kehittyneempi vaihtoehto on ehtoja ja osamallipohjia tukeva mallipohjakirjasto, kuten Jinja2 tai Handlebars.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

Mallipohjat auttavat ehkäisemään muuttujien kautta tapahtuvia kehoteinjektioita, kun käyttäjän syöte suojataan asianmukaisesti. Ne mahdollistavat ehdollisen logiikan ja pitävät kehotteen rakenteen yhdenmukaisena.

Versionhallinta

Kehotteet ovat koodia. Tallenna ne lähdekoodin versionhallintaan.

Toimiva malli on repositorion prompts/-hakemisto, jossa jokaisella kehotteella on oma tiedosto:

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Jokainen tiedosto sisältää erillisen kehotteen ja oman muutoshistoriansa. Muutokset katselmoidaan PR:ssä. Tuotantojulkaisut viittaavat tiettyihin versioihin.

Miksi tämä on tärkeää:

• Erojen näkyvyys. Kun kehote muuttuu, ero näkyy PR:ssä ja katselmoijat näkevät täsmälleen, mitä muuttui.
• Palautus. Kun muutos rikkoo jotakin, aiemman version voi palauttaa.
• Historia. Kysymyksiin ”milloin hyvityskäytäntöä muutettiin kehotteessa?” ja ”miksi tämä kappale on tässä?” voi vastata git blame -historian avulla.
• Työkalut. Lintterit, validaattorit ja arviointikokonaisuudet integroituvat kaikki tiedostopohjaisiin kehotteisiin.

Vältä koodiin merkkijonoina tallennettuja kehotteita, joita on vaikea löytää ja vertailla, käyttöliittymätyökaluun tallennettuja kehotteita, joiden versiointi on työkalun eikä sinun hallinnassasi, sekä ihmisten keskusteluikkunoista kopioituja kehotteita, joita ei seurata eikä voi testata.

Älä tallenna versionhallintaan tuotantokeskusteluja, asiakastietueita, tukipyyntöjä, sisäisiä asiakirjoja tai arkaluonteisia muuttujia sisältäviä muodostettuja kehotteita. Lähdekoodin versionhallintaan kuuluvat uudelleenkäytettävät mallipohjat, testiaineistot ja puhdistetut arviointiesimerkit. Todelliset jäljitykset kuuluvat havainnoitavuustietovarastoon, jossa on säilytysajat, käyttöoikeuksien hallinta ja peittäminen.

Kehote tietona: ulkoinen tallennus

Tiedostopohjainen versionhallinta on liian hidasta usein muuttuville kehotteille, kuten A/B-testeille, asiakastasojen variaatioille ja lokaaleille tarkoitetuille kehotteille.

Ratkaisumalli on tietokanta tai palvelu, joka tallentaa kehoteversiot metatietoineen.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

Palvelu ylläpitää:

• Jokaisen kehotteen nykyisiä ja aiempia versioita.
• Metatietoja siitä, milloin, kuka ja miksi version lisäsi.
• Jokaiseen versioon liitettyjä arviointituloksia.
• Mahdollisuutta palauttaa aiempi versio.

Työkaluja ovat PromptLayer, Helicone ja organisaation omat ratkaisut. Useimmille tiimeille yksinkertaisella tietokantaskeemalla toteutettu oma ratkaisu toimii hyvin.

Käyttöliittymä on ratkaiseva. Sekä insinöörien että muiden asiantuntijoiden, kuten tuote- ja sisältötiimien, pitäisi voida muokata kehotteita. Muutokset kuitenkin katselmoidaan ja niiden on läpäistävä arvioinnit ennen tuotantoon vientiä.

Arvioinneilla rajatut muutokset

Jokainen kehotemuutos käy läpi arvioinnit ennen käyttöönottoa. Tästä ei tingitä vakavasti otettavissa tuotantojärjestelmissä.

Prosessi:

1. Insinööri tai muu asiantuntija luonnostelee kehotemuutoksen.
2. Muutos ajetaan arviointikokonaisuutta vasten.
3. Arviointitulokset katselmoidaan muutoksen rinnalla.
4. Jos arvioinnit läpäistään ilman regressioita ja mielellään parannuksin, muutos voidaan hyväksyä.
5. Hyväksytyt muutokset julkaistaan.
6. Julkaisun jälkeinen valvonta havaitsee arvioinneilta huomaamatta jääneet ongelmat.

Käytännössä jokaisella kehotteella on arviointikokonaisuus, joka ajetaan CI:ssä kehotemuutosten yhteydessä.

Ilman tätä porttia kehotemuutokset rikkovat asioita arvaamattomasti. Portin avulla muutoksia voi tehdä nopeasti ja luottavaisesti.

Käytännöllinen julkaisun tarkistuslista

Vaadi lyhyt tarkistuslista ennen kehoteversion tuotantoon vientiä:

Artikkeliin linkitetty tarkistuslista muuttaa nämä tarkistukset toistettavaksi julkaisukatselmoinniksi.

A/B-testaus tuotannossa

Uusia kehotteita kannattaa A/B-testata olemassa olevaa versiota vastaan pienellä osalla tuotantoliikenteestä, jotta arviointien lisäksi saadaan todelliseen käyttöön perustuvaa tietoa.

Malli:

• 95% liikenteestä käyttää tuotantokehotetta v3.
• 5% saa uuden ehdokkaan v4.
• Mittaa käyttäjäpalaute, jatkomittarit ja todellisen liikenteen arviointitulokset.
• Päätä riittävän aineiston jälkeen, otetaanko v4 käyttöön kokonaan eli 100%, vai säilytetäänkö v3.

Työkaluja ovat ominaisuusliput, kuten LaunchDarkly tai oma toteutus, kehoteversiointipalvelut, kuten PromptLayer, sekä mukautettu reititys.

Varoitukset:

• A/B-testaus havaitsee vain mitattavat signaalit. Ilman käyttäjäpalautetta tai jatkovaiheiden konversiomittareita se kertoo vain vähän.
• Tilastollinen merkitsevyys vaatii riittävän volyymin. A/B-testaus on vaikeaa pienen volyymin ominaisuuksissa.
• Älä aja liian montaa A/B-testiä samanaikaisesti, sillä niiden vuorovaikutuksista tulee epäselviä.

Kehotteiden havainnoitavuus

Jokaisesta tuotannon LLM-kutsusta pitäisi kirjata:

• Käytetty kehotemallipohja eli nimi ja versio.
• Korvatut muuttujat käyttäen sallittujen nimien luetteloa ja tarvittaessa peitettyjä arvoja.
• Lopullinen muodostettu kehote vain, jos käytäntö sallii sen. Muussa tapauksessa tallenna peitetty, otokseen valittu tai tiivisteenä esitetty versio.
• Mallin vastaus, joka peitetään tai poimitaan otoksena arkaluonteisissa työnkuluissa.
• Viive, tokenit ja kustannus.
• Jatkosignaalit, kuten käyttäjäpalaute ja onnistumismittarit.

Näitä tietoja tarvitaan sen selvittämiseen, miksi malli antoi tietylle käyttäjälle oudon vastauksen. Ilman niitä voit vain arvailla.

Tallennuspaikkana voi olla tietokantataulu tai havainnoitavuustyökalu. Kaiken lokittamisesta syntyy todellisia kustannuksia (kutsumäärä × tokenimäärä × tallennustila). Kaiken lokittaminen aiheuttaa myös todellisen tietosuojariskin. Päätä työnkulkukohtaisesti, mitä kenttiä on turvallista tallentaa, peitä salaisuudet ja henkilötiedot oletusarvoisesti ja pidä säilytysajat lyhyinä, ellei vaatimustenmukaisuus edellytä pidempää säilytystä. Jotkin tiimit käyttävät otantaa.

Katselmointi tarkoittaa säännöllistä, esimerkiksi viikoittaista, käytäntöä, jossa luetaan otos todellisista tuotantokehotteista ja vastauksista. Näin havaitaan ongelmia, joita arvioinnit eivät löydä.

Kehotteiden antimallit

Vältä seuraavia malleja:

Antimalli 1: jättikehote. 10,000 sanan järjestelmäkehote yrittää käsitellä kaikki tilanteet. Sitä on vaikea muuttaa ja selvittää, ja malli jättää usein sen ohjeet huomiotta myöhempien ohjeiden yhteydessä.

Korjaus: erota kerroksittaisiin, tarkasti rajattuihin kehotteisiin. Yksi kutakin ominaisuutta kohti.

Antimalli 2: merkkijonojen yhdistäminen koodissa.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Hauras, vaikealukuinen ja altis injektioille.

Korjaus: käytä mallipohjajärjestelmää.

Antimalli 3: sama kehote liian moneen käyttötapaukseen.

Yhtä yleisavustajan kehotetta käytetään sähköpostien luonnosteluun, koodikatselmointiin, asiakastukeen ja tutkimukseen. Tehtävät ovat erilaisia, eikä yksi kehote optimoi mitään niistä.

Korjaus: käytä yhteisen järjestelmäkehotteen päällä ominaisuuskohtaisia kehittäjäkehotteita.

Antimalli 4: kovakoodatut kehotteet.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

Kehote on haudattu koodiin. Sitä ei voi muokata ilman julkaisua, A/B-testata tai versioida itsenäisesti.

Korjaus: siirrä kehote tiedostoon tai palveluun.

Antimalli 5: ei arviointikattavuutta.

Ominaisuus julkaistaan kehotteella, jota ei ole koskaan testattu järjestelmällisesti. Laatu perustuu tuntumaan, eikä ajautumista voi havaita.

Korjaus: jokaisella kehotteella on arviointikokonaisuus.

Antimalli 6: tietojen sekoittaminen järjestelmäkehotteeseen.

You are an assistant for John, a premium customer who joined in 2023, lives in Tallinn, and has 47 open tickets.

Nyt järjestelmäkehote muuttuu jokaisella kutsulla. Välimuisti ei toimi, ja sekaannusta syntyy.

Korjaus: dynaamiset tiedot kuuluvat käyttäjä- tai kontekstikerrokseen, eivät järjestelmäkehotteeseen.

Antimalli 7: ohjeet on haudattu keskelle.

Help the user with their request. Be polite. Format output as JSON. Don't use markdown. The user is asking about pricing, so be careful about quoting numbers. Output should be 1-2 sentences. Now help them.

Tärkeät ohjeet hukkuvat, eikä malli välttämättä huomaa niitä.

Korjaus: käytä selkeitä osioita ja sijoita kriittiset ohjeet alkuun ja loppuun, koska viimeaikaisuusvaikutus auttaa.

Tavallisten ominaisuuksien erityismallit

Muutama ominaisuuskohtainen malli:

Luokittelu

Task: classify the following text into one of these categories:
- billing: payment, refund, subscription
- technical: bug, error, integration issue
- account: login, password, profile changes
- feature_request: new functionality requests
- complaint: general dissatisfaction without specific actionable issue

Output a JSON object: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Text to classify:
{text}

Mallit: määritelmillä varustetut luetellut luokat, rakenteinen tuotos sekä luottamus- ja perustelukentät.

Tietojen poiminta

Task: extract structured data from the document below.

Schema:
- vendor_name: company that issued the invoice
- invoice_number: as printed on the document
- date: ISO 8601 format
- line_items: array of {description, quantity, unit_price, total}
- subtotal, tax, total: numbers

Rules:
- If a field is not present, use null
- Numbers should be numeric, not strings
- For ambiguous cases, set "needs_review": true and explain

Document:
{document}

Mallit: yksiselitteinen skeema, tyyppiodotukset, puuttuvien tietojen käsittely ja epäselvien tapausten eskalointi.

Tyylin mukainen generointi

Task: write a {format} on the topic of {topic}, targeting {audience}.

Style:
- {Specific style trait 1}
- {Specific style trait 2}
- Avoid: {anti-pattern 1}, {anti-pattern 2}

Constraints:
- Length: {N} words
- Include: {required elements}
- Exclude: {forbidden elements}

Voice reference:
[Provide a sample of the desired voice]

Output: the {format} only, with no preamble or post-script.

Mallit: täsmälliset tyylipiirteet yleisten sijaan, yksiselitteiset rajoitteet ja äänensävyn sitominen esimerkkitekstiin.

Agenttisilmukka

You have access to the following tools:
{tool_descriptions}

For each turn:
1. Think about what you need to do.
2. Decide if you need a tool. If yes, call it.
3. After observing the result, decide if you need more tools or can answer.
4. When you have enough information, produce the final answer.

Constraints:
- Maximum 5 tool calls per request.
- If after 5 calls you can't complete, explain what's missing.
- Never invent tool names or arguments.
- Verify tool results before acting on them.

User request:
{user_query}

Mallit: yksiselitteiset päättelyvaiheet, työkalubudjetti, hallusinaatioiden esto ja tulosten arviointi.

Tiimin merkitys

Tuotantokehotteisiin osallistuu tavallisesti useita ihmisiä:

• Insinöörit yhdistävät kehotteet järjestelmään, ylläpitävät mallipohjia ja hallitsevat julkaisuja.
• Tuotetiimi määrittää, mitä kehotteilla pitäisi saavuttaa.
• Sisältö- ja markkinointitiimi omistaa äänensävyä ja tyyliä koskevat ohjeet.
• Toimiala-asiantuntijat tietävät, mikä on oikein tietyissä käyttötapauksissa, kuten oikeudellisessa kielessä tai lääketieteellisissä termeissä.

Hyödyllinen malli on koodikatselmointia vastaava kehotekatselmointi, jossa jokaiselle alalle valitaan oikeat katselmoijat. Sisältötiimi katselmoi äänensävyn muutokset, insinöörit logiikkamuutokset ja toimiala-asiantuntija alakohtaisen sisällön.

Arkaluonteisissa oikeudellisissa, lääketieteellisissä ja taloudellisissa käyttötapauksissa kehotteet voivat vaatia muodollisen katselmoinnin ja hyväksynnän. Rakenna prosessi sen mukaisesti.

Kehotteiden 90 päivän kypsytyssuunnitelma

Tiimeille, jotka siirtyvät ”kehotteet ovat merkkijonoja koodissa” -tilasta ”kehotteet ovat hallittua infrastruktuuria” -tilaan:

Päivät 1-30: perusta.

• Siirrä kaikki kehotteet erillisiin tiedostoihin lähdekoodin versionhallinnassa.
• Ota käyttöön 3 kerroksen malli (järjestelmä, kehittäjä ja käyttäjä).
• Rakenna yksinkertainen mallipohjakerros.
• Ota käyttöön kehotteiden ja vastausten peruslokitus.

Päivät 31-60: arviointi.

• Rakenna arviointikokonaisuudet 5 tärkeimmälle kehotteelle.
• Aja arvioinnit kehotemuutoksille aluksi manuaalisesti.
• Ota arviointien CI-integraatio käyttöön niin, että ne ajetaan automaattisesti PR:issä.

Päivät 61-90: operointi.

• Toteuta kehotteiden versiointi tietokannassa tai palvelussa.
• Lisää A/B-testauksen mahdollisuus vähintään yhdelle kriittiselle kehotteelle.
• Rakenna koontinäytöt tuotantokehotteiden laadulle.
• Luo kehotemuutosten katselmointiprosessi.

90 päivän jälkeen kehotteet ovat hallittua infrastruktuuria. Muutokset ovat harkittuja, testattavia, katselmoitavia ja palautettavia. Laatua voidaan mitata ja ajautuminen havaita.

Kehotteet infrastruktuurina

Tuotantokehotteet eivät ole merkkijonoja. Ne muodostavat kerroksittaisen järjestelmän, jossa versiointia, mallipohjia, arviointia ja havainnoitavuutta hallitaan kurinalaisesti.

Kolmen kerroksen arkkitehtuuri (järjestelmä, kehittäjä ja käyttäjä) erottaa huolenaiheet ja pitää kehotteet ylläpidettävinä. Mallipohjat ehkäisevät haurautta. Lähdekoodin versionhallinta tai kehotepalvelu tarjoaa versiohistorian. Arvioinnit rajaavat muutoksia, ja havainnoitavuus löytää arvioinneilta huomaamatta jääneet ongelmat.

Tämä ei ole valinnaista vakavasti otettavassa tuotantotyössä. Vaiheet ohittavat tiimit päätyvät kehotekaaokseen: merkkijonoja on hajallaan koodissa, tuotannossa olevasta versiosta ei ole tietoa, laatua ei mitata ja toiminta muuttuu jatkuvasti ilman selitystä.

Kehoteinfrastruktuuriin panostavat tiimit saavat hallittavaa, mitattavaa ja parannettavaa tekoälytoimintaa. Tämä erottaa hyvin ikääntyvän ominaisuuden tekniseksi velaksi muuttuvasta ominaisuudesta.

Aloita arkkitehtuurista. Kaikki muu helpottuu.