Копилотите со ВИ ја олеснија изработката на код. Тоа не е исто што и олеснување на создавањето корисен производ.

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

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

Почнете од вредноста, а не од имплементацијата

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

Кој кориснички проблем го намалуваме? Што се менува за таа личност кога ова ќе проработи? Како ќе знаеме дека промената ја подобрила ситуацијата, наместо само да додала уште една опција во интерфејсот?

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

• Кому му е потребно известувањето и какво дејство треба да овозможи?
• Кои настани се итни, а кои можат да почекаат за збирен преглед?
• Што се случува ако испораката не успее или пристигне доцна?
• Кои информации мора да бидат вклучени за примачот да може да дејствува без да го отвори производот?
• Што би ја направило функцијата доволно нападна за луѓето да ја оневозможат?

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

Користете ја ВИ како партнер за размислување, а не како авторитет

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

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

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

Доброто техничко лидерство значи истовремено да се задржат двете идеи: дизајнирајте за промени, но не купувајте сложеност пред производот да ја заслужи.

Барајте алтернативи со компромиси

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

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

ВИ може да ја забрза анализата. Не може да ја преземе дежурната служба, да му објасни збунувачко однесување на производот на клиент или да ја поправи довербата по тивок неуспех. Сопственоста останува човечка.

Претворете ја побрзата имплементација во подобро откривање

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

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

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

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

• Кое корисничко однесување треба да се подобри со ова?
• Кои претпоставки ги прави имплементацијата?
• Што се случува кога зависностите се бавни, недостапни или неконзистентни?
• Кои сигнали ќе ни кажат дали изданието помогнало?
• Како можеме безбедно да ја измениме или отстраниме функцијата ако претпоставката е погрешна?

Заштитете ја одржливата испорака

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

Генерираниот код сè уште треба внимателно да се чита. Уверлива имплементација може да крие слабо справување со грешки, проверки за авторизација што недостигаат, небезбедни претпоставки за податоците или однесување што работи само по среќниот пат. Побзото создавање ја прави дисциплинираната проверка поважна, не помалку важна.

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

Овие практики не се бирократија. Тие ја зачувуваат способноста на тимот повторно да се движи утре.

Направете ја оддалечената соработка понамерна

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

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

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

Изградете го расудувањето што алатките не можат да го заменат

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

Копилот со ВИ може да направи способна личност побрза. Ако се користи добро, може и да направи промислен тим пољубопитен: поспремен да истражува алтернативи, да тестира претпоставки, да документира одлуки и да се фокусира на работата што корисниците ја чувствуваат.

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