Повеќето тимови сега знаат како да побараат код од асистент со вештачка интелигенција. Многу помалку знаат како да изградат софтвер што му дава на асистентот нешто доверливо од кое може да учи.

Таа разлика е важна. Добро напишан поттик може да произведе корисна функција, нацрт на тестови или веродостоен план за миграција. Но горната граница на квалитетот ја поставува системот околу него: архитектурата, именувањето, границите, тестовите, документацијата и одлуките кодирани во складиштето.

Вештачката интелигенција не ја заменува инженерската проценка. Таа ги засилува доказите што ѝ се достапни. Ако кодната база јасно ја соопштува намерата, асистентот може да им помогне на тимовите да се движат побрзо со помал надзор. Ако е полна со скриена поврзаност, недоследни конвенции и недокументирани деловни правила, ВИ самоуверено ќе ја репродуцира збунетоста.

Архитектурата е средина за учење

Развивачите често ја опишуваат архитектурата во смисла на приспособливост, одржливост или сигурност. Тие сè уште се суштински. Но современите тимови треба да додадат уште едно прашање: дали нов соработник, човек или ВИ, може да заклучи како функционира овој производ без да му се предаде мапа што постои само во нечија глава?

Добрата архитектура создава локално расудување. Развивач што ја менува логиката за претплати треба да може да ги најде релевантните доменски концепти, да ги разбере влезовите и излезите и да направи промена без да следи неповрзана состојба на корисничкиот интерфејс, детали од базата на податоци и код за известувања низ целата апликација.

Истиот квалитет ја прави ВИ-помошта покорисна. Фокусиран модул му дава на моделот ограничен проблем. Распространета датотека со повеќе одговорности му дава игра на погодување.

Ова не бара стремеж кон апстрактна чистота. Бара важните избори да бидат видливи. Јасните граници не се бирократија; тие се комуникација.

Градете околу концепти, а не околу случајности на рамката

Многу апликации постепено се организираат околу она што рамката го направила најлесно: контролери, обработувачи, пребарувања, компоненти, складишта и папки со помошни функции. Тие категории можат да бидат корисни, но ретко го објаснуваат бизнисот.

Продуктниот тим има корист кога кодот исто така го одразува јазикот што го користат неговите корисници и засегнати страни. Ако бизнисот има концепти како фактури, одобрувања, испораки, подобност или политики за пристап, тие концепти треба да имаат препознатливи места во системот.

Разгледајте функција што му дозволува на менаџер да одобри барање за надомест на трошоци. Слабата имплементација може да го смести правилото во обработувач на рута бидејќи таму се поднесува барањето од копчето. Посилниот дизајн му дава на правилото смислено место:

type ExpenseClaim = {
  status: "submitted" | "approved" | "rejected";
  amount: number;
};

function approveClaim(claim: ExpenseClaim, approverId: string) {
  if (claim.status !== "submitted") {
    throw new Error("Only submitted claims can be approved");
  }

  return {
    ...claim,
    status: "approved" as const,
    approvedBy: approverId,
  };
}

Примерот е намерно едноставен. Неговата вредност не е во синтаксата; туку во местото на одговорноста. Правилото за одобрување може да се тестира независно, повторно да се користи од повеќе интерфејси и да се разбере без читање HTTP-код.

Кога од ВИ-асистент се бара да го прошири ова однесување, тој има подобра шанса да го зачува постојниот модел. Може да види дека одобрувањето е доменска дејство со експлицитна транзиција на состојба, наместо споредно ажурирање на базата на податоци скриено во обработувач на барања.

Направете го „зошто“ откривливо

Кодот објаснува што прави системот. Не секогаш објаснува зошто го прави тоа на тој начин. Тој контекст што недостига е местото каде што почнуваат скапите грешки, особено во далечински тимови каде што брзо прашање до колега на соседното биро е невозможно.

Не ја документирајте секоја линија. Документирајте ги одлуките што разумен инженер инаку би можел да ги поништи. Краток запис често е доволен:

• Зошто пресметката користи одредено правило за заокружување.
• Зошто заднинска задача е идемпотентна.
• Зошто надворешната интеграција е изолирана зад адаптер.
• Зошто навидум излишната валидација се случува во повеќе од еден слој.
• Зошто старото однесување мора да остане додека не заврши миграцијата.

Поставете го овој контекст блиску до одлуката кога е можно: во краток коментар во кодот, документ на ниво на модул, опис на pull request или запис за архитектонска одлука. Форматот е помалку важен од неговото зачувување.

ВИ може извонредно добро да сумира и поврзува постојно знаење. Не може сигурно да обнови отфрлена продуктна одлука од погрешно име на функција. Третирајте го трајниот контекст како дел од производот, а не како незадолжителен процесен товар.

Користете ги тестовите како извршлив продуктен јазик

Тест-пакетот е една од најсилните алатки за подучување во едно складиште. Тој покажува не само дека кодот работи, туку и што тимот смета дека е доволно важно за да се заштити.

Тестовите стануваат особено вредни кога го опишуваат однесувањето во продуктни термини. Споредете тест со име returns_400_when_invalid со тест со име cannot_approve_a_claim_that_has_already_been_rejected. Вториот пренесува правило. Му помага на идниот соработник да ја разбере намерата пред да ги менува деталите на имплементацијата.

За критичните работни текови, давајте предност на тестови што го покриваат договорот на границата и донесувањето одлуки во јадрото. На пример:

• Единични тестови за цени, дозволи, транзиции на состојби и правила за валидација.
• Интеграциски тестови за трајно зачувување во базата на податоци, редици и адаптери за трети страни.
• Тестови од крај до крај за мал број кориснички патувања со висока вредност.

Целта не е максимален број тестови. Таа е доверлива повратна информација. Бавните, кршливи или двосмислени тестови ги учат и луѓето и ВИ дека пакетот е предмет на преговарање. Брзите, специфични тестови ја претвораат промената од чин на надеж во рутинска инженерска активност.

Дизајнирајте работни текови што ги држат луѓето одговорни

Развојот со ВИ-помош може да ги наведе тимовите да го мерат резултатот според обемот: повеќе pull request-ови, повеќе генерирани тестови, повеќе затворени тикети. Одржливата испорака бара поинаква мерка: колку самоуверено тимот може да го менува производот?

Техничките лидери треба јасно да ја определат сопственоста. Лицето што поднесува промена останува одговорно да ја разбере, валидира и објасни нејзините компромиси. „Асистентот го генерираше“ не е инженерско образложение.

Практичен работен тек за преглед може да ја зачува брзината без да ги намали стандардите:

1. Почнете со јасна изјава за проблемот и критериуми за прифаќање.
2. Побарајте од ВИ опции, гранични случаи или тесен нацрт за имплементација.
3. Прегледајте го резултатот во однос на локалните конвенции и продуктните ограничувања.
4. Извршете ги релевантните тестови и проверете ги патеките на неуспех, а не само среќната патека.
5. Забележете ги новите одлуки таму каде што идните одржувачи ќе ги најдат.

Овој пристап е особено корисен за распределени тимови. Пишаните очекувања ја намалуваат зависноста од синхрона достапност. Колега во друга временска зона може да разбере зошто постои промена, како била валидирана и што останува неизвесно.

Намалете ја двосмисленоста пред да побарате забрзување

Најдобриот ВИ-поттик често му претходи подобра инженерска подготовка. Пред да побарате помош за имплементација, дефинирајте ја границата на промената. Идентификувајте го изворот на вистината. Именувајте го условот за успех. Одлучете што не смее да се промени.

Наместо да прашате: „Додај потсетници за фактури“, поставете ја работата попрецизно: „Испрати еден потсетник за неплатени фактури по датумот на доспевање, избегни дупликати на испраќања, забележи го обидот и не менувај фактури што веќе се означени како платени.“

Таа јасност го подобрува секој дел од испораката: продуктна дискусија, имплементација, преглед, тестирање и операции. ВИ е само уште еден учесник што има корист од добро дефиниран проблем.

Кодната база станува артефакт на лидерството

Како што ВИ презема повеќе рутинско подготвување на нацрти, вредноста на техничкото лидерство дополнително се поместува кон проценката: обликување граници, појаснување намера, управување со ризик и создавање услови во кои добрата работа е повторлива.

Најсилните тимови нема да бидат оние со најумните поттици. Тоа ќе бидат тимовите чии системи ја кажуваат вистината за производот: што прави, зошто се однесува така, каде припаѓаат одлуките и како промената може да се потврди.

Градете софтвер од кој може да учи внимателен новодојденец. Градете го така што колега може безбедно да го подобри месеци подоцна. Градете го така што ВИ-асистентот ќе наиде на шаблони што вреди да се прошират. Тоа не е само подготовка за нов сет алатки. Тоа е трајниот занает на создавање корисни дигитални производи.