Buksan ang isang repository anim na buwan matapos ma-ship ang isang feature at marami kang muling mabubuo. Masusundan mo ang architecture, masisiyasat ang schema, mababasa ang mga test, at makikita nang eksakto kung aling mga linya ang nabago.
Ang karaniwang hindi mo na muling mabubuo ay ang usapang nagbigay-daan para maging kailangan ang mga linyang iyon.
Hindi sasabihin sa iyo ng code na may validation rule dahil may isang customer na nagpapadala ng malformed exports. Hindi nito ipapaliwanag na ang kakaibang retry policy ay pumipigil sa duplicate transactions sa isang downstream system. Hindi nito ipapakita na tinanggihan ang mas malinis na interface matapos ang isang accessibility test, o na ang service boundary ay sumasalamin sa isang contractual restriction sa halip na isang engineering preference.
Napakahusay ng Git sa pagpapanatili ng kasaysayan ng code. Napapanatili nito ang layunin lamang kapag sinasadya ng isang team na isulat ang layuning iyon at panatilihin itong nakakabit sa implementation.
Matagal nang bahagi ng software engineering ang puwang na iyon. Mas ginagawa lang itong mas nakikita ng mga AI coding tool. Kayang basahin ng isang system ang bawat file sa isang repository, sundan ang bawat symbol, at bumuo ng isang patch na teknikal na kapani-paniwala habang mali pa rin ang problemang nilulutas nito.
Ang problema ay hindi na mapanlinlang ang code. Ang code ay sumasagot sa mas makitid na tanong.
Limang antas ng katotohanan sa engineering
Karamihan sa mahahalagang pagbabago sa software ay nakadepende sa limang magkakaibang antas ng ebidensya.
- Intent — Anong resulta ang hinihingi ng user, customer, o negosyo? Maaaring nasa specification, ticket, support conversation, o meeting note ito.
- Constraints — Ano ang hindi dapat masira? Ang mga pangako sa compatibility, security boundaries, regulasyon, kontrata, budget, at deadline ay madalas nasa labas ng repository.
- Implementation — Paano gumagana ang system sa kasalukuyan? Ang code, tests, schemas, dependencies, at deployment configuration ang bumubuo sa antas na ito.
- Runtime evidence — Ano ang nangyayari sa totoong system? Ang logs, traces, metrics, production data, at incident reports ay maaaring sumalungat sa mga palagay na mukhang makatwiran sa code.
- Decision history — Bakit pinili ang kasalukuyang approach? Nasa pull requests, design discussions, rejected alternatives, at mga nakaraang insidente ang sagot.
Pinakamalakas ang repository sa ikatlong antas. Naglalaman ito ng ilang bahagi ng iba, pero bihirang sapat para ganap na katawanin ang mga iyon.
Mahalaga ito dahil madalas lumilitaw ang mga pagkabigo sa software sa mga hangganan sa pagitan ng mga antas. Tumutugma ang implementation sa isang luma nang specification. Natutugunan ng fix ang ticket pero nilalabag ang isang operational constraint. Pumapasa ang mga test dahil naka-encode sa mga ito ang mga palagay ng kahapon. Panloob na magkakatugma ang code habang ang production data ay sumusunod sa isang pattern na walang sinumang nagdokumento.
Ang isang patch na tama sa lokal na saklaw ay maaari pa ring maging maling pagbabago.
Ano ang hindi kayang sagutin ng repositoryo nang mag-isa
Isipin ang isang user na nag-edit ng dokumento at pagkatapos ay hinanap ang na-update na pangungusap, pero ang lumang bersyon pa rin ang nakita sa mga resulta. Ang “Gawing mag-update agad ang search” ay mukhang malinaw na kahilingan. Ipinapakita ng repositoryo ang ilang posibleng lugar kung saan puwedeng magsimula, pero hindi nito kayang tukuyin nang mag-isa kung ano ang tamang ayos.
| Tanong | Malamang na pinagmulan |
|---|---|
| Aling bersyon ng dokumento ang awtoritatibo? | Pinagmulan ng dokumento at kasaysayan ng rebisyon |
| Saan nananatili ang lumang teksto? | Mga sync log, extraction output, search index, o cache |
| Ano ang ibig sabihin ng “agad” para sa produktong ito? | Pangako ng produkto o layunin ng serbisyo |
| Nagbago rin ba ang mga pahintulot ng dokumento kasabay ng nilalaman nito? | Mga source permission at kasaysayan ng audit |
| Ang lipas na resultang ito ba ay limitado sa isang user, source, o rehiyon? | Mga request trace at production metric |
Maaaring ipaliwanag ng search code kung paano ibinabalik ang mga resulta. Hindi nito masasabi sa iyo kung ang tunay na depekto ay pagkaantala sa synchronization, lipas na extraction, cache invalidation, propagation ng permission, o isang inaasahang asal na hindi naman kailanman tinukoy ng produkto.
Mas nagiging mahalaga ang pagkakaibang ito sa mga mature na system. Ang isang field na mukhang laos na ay maaari pa ring sumuporta sa isang legacy client. Ang isang service na mukhang duplicate ay maaaring naghihiwalay ng data na may magkaibang pangangailangan sa permission. Ang isang check na tila sobra ay maaaring siya lang ang tanging bakas sa antas ng code ng isang production incident na hindi kailanman nakita ng kasalukuyang team.
Mahalaga ang pagbawas ng complexity. Pero magastos ang pagbura sa kasaysayang nagkukubli bilang complexity.
Kahit mas maraming context, maaari pa ring mali ang sagot
Ang malinaw na solusyon ay bigyan ang AI ng mas maraming materyal: ang buong repositoryo, bawat ticket, bawat dokumento, bawat mensahe, at bawat log.
Nagbibigay iyon ng access, hindi pag-unawa.
Maaaring lipas na, magkakasalungat, haka-haka, o isinulat para sa magkaibang audience ang mga source. Hindi dapat manaig ang isang brainstorm laban sa isang naaprubahang specification. Hindi dapat tahimik na mapawalang-bisa ng isang anim-na-buwang-gulang na requirement ang desisyon sa produkto kahapon. Dapat maiugnay ang isang production log sa release, environment, at code path na lumikha nito. Hindi dapat ituring ang isang customer request bilang pangkalahatang requirement nang hindi muna sinusuri ang saklaw.
Kaya ang isang seryosong context system ay nangangailangan ng higit pa sa retrieval. Kailangan nito ng paraan para mangatuwiran tungkol sa:
- Awtoridad: Aling source ang pinapayagang magtakda ng requirement?
- Pagiging bago: Aling impormasyon ang kasalukuyan, at alin ang napalitan na?
- Pinagmulan: Saan nanggaling ang bawat claim, constraint, o konklusyon?
- Mga ugnayan: Aling issue, release, customer, dataset, at code path ang magkakaugnay?
- Mga pahintulot: Aling mga source ang maaaring gamitin para sa gawaing ito at ipakita sa taong ito?
Ang context ay hindi tambak ng mga token. Isa itong graph na may panahon, awtoridad, at mga hangganan.
Ang mas maraming context ay dapat magbunga ng mas maraming ebidensya, hindi ng mas mataas na kumpiyansa na walang ebidensya.
Ang tunay na yunit ng trabaho ay ang pagbabago
Nakaayos ang mga editor at coding tool sa paligid ng mga file dahil mga file ang binabago natin. Nakaayos ang mga engineering team sa paligid ng mga pagbabago.
Nagsisimula ang isang pagbabago sa isang dahilan. Nagiging requirement ito, humahawak sa code at data, dumaraan sa review, umaabot sa production, at lumilikha ng bagong ebidensya. Kung mananatiling magkakahiwalay ang mga yugtong iyon, magsisimula ang bawat susunod na gawain sa panibagong round ng archaeology.
Dapat sundan ng isang AI system na gumagawa sa totoong software ang lifecycle na iyon.
Bago ang implementation, dapat nitong tukuyin ang kahilingan, ang mga kaugnay na constraint, at anumang magkakasalungat na source. Dapat nitong malaman kung nag-aayos ito ng depekto, nagpapalit ng inaasahang asal, o nagpapakilala ng bagong contract.
Habang isinasagawa ang implementation, dapat nitong iugnay ang bawat makabuluhang pagpili sa ebidensya. Bakit ang module na ito? Bakit ang migration strategy na ito? Bakit panatilihin ang branch na ito? Dapat manatili ang paliwanag lampas sa chat na lumikha ng code.
Pagkatapos ng implementasyon, dapat nitong ikabit sa pagbabago ang mga resulta ng beripikasyon, mga desisyon sa review, at mga bagong natuklasang constraint. Kung hindi, ang susunod na tao—o ang susunod na AI session—ay kakailanganing tuklasin muli ang mga iyon.
Ito ang kaibhan ng isang tool na kayang mag-edit ng repository at ng isang sistemang kayang makilahok sa gawaing pang-engineering.
Dapat bawasan ng AI ang muling pagbubuo, hindi alisin ang paghatol
Ang mas mahusay na context ay minsang inilalarawan bilang landas tungo sa autonomous software development. Ang agarang halaga nito ay hindi gaanong dramatiko ngunit mas kapaki-pakinabang: ang pagbawas sa gastos ng muling pagbubuo ng realidad bago gumawa ng pagbabago.
Kayang ilapit ng AI ang orihinal na requirement sa kaugnay na code. Kaya nitong ilabas ang insidenteng nagpapaliwanag sa isang hindi pangkaraniwang safeguard. Kaya nitong iugnay ang isang pumapalpak na metric sa release na nagbago rito. Kaya nitong ipakita na hindi magkasundo ang dalawang authoritative source bago pa magsimula ang implementasyon.
Hindi inaalis ng mga kakayahang iyon ang paghatol sa engineering. Ginagawa nilang mas may batayan ito.
May tao pa ring kailangang magpasya kung aling tradeoff ang katanggap-tanggap, kung kumpleto ang isang requirement, at kung gaano kalaking panganib ang maaaring dalhin ng isang release. Dapat gawing nakikita ng sistema ang ebidensya at nasusuri ang pangangatwiran. Hindi nito dapat itago ang kawalan ng katiyakan sa likod ng isang makinis na patch.
Ang pamantayan ay hindi “kaya ba nitong bumuo ng code?”
Ang pamantayan ay “kaya ba nitong ipaliwanag kung bakit ito ang tamang pagbabago ngayon?”
Mula sa repository-aware tungo sa work-aware
Unang naging kapaki-pakinabang ang mga coding assistant sa pamamagitan ng pag-unawa sa file na nasa harap ng developer. Ang repository awareness ang sumunod na malaking hakbang: paghahanap ng kaugnay na code, pagsunod sa mga symbol, at paglalapat ng mga pagbabago sa buong proyekto.
Ang susunod na hakbang ay ang pagkakaroon ng kamalayan sa gawaing nakapaligid sa repository.
Ibig sabihin nito ang pag-uugnay ng code sa specification na humiling nito, sa usapang naglinaw rito, sa production evidence na humamon dito, at sa desisyong dapat maalala pagkatapos. Ibig din nitong sabihin ang hindi pagsama ng context na walang kaugnayan, lipas na, o lampas sa mga pahintulot ng user.
Habang binubuo ang Dvina, isa ito sa mga ideyang paulit-ulit naming binabalikan. Hindi nangyayari ang trabaho sa loob ng iisang file, application, o usapan. Nasa mga ugnayan sa pagitan ng mga ito ang kahulugan, at sa kung paano nagbabago ang mga ugnayang iyon sa paglipas ng panahon.
Nananatiling mahalaga ang repository. Ito ang executable source of truth para sa asal ng system. Hindi lang ito ang kumpletong source of truth para sa intensyon ng produkto, operasyonal na realidad, o memorya ng organisasyon.
Binabago ng buong kuwento kung ano ang nabubuo
Kung code lang ang mayroon, ang natural na tanong ay:
Anong pagbabago ang akma sa sistemang ito?
Sa mas malawak na context, nagiging ganito ang tanong:
Anong pagbabago ang akma sa sistemang ito, sa requirement na ito, sa kasaysayang ito, at sa sandaling ito?
Nahuhuli ng ikalawang tanong na iyon ang mga limitasyon bago pa mauwi ang mga ito sa mga regression. Ibinibigay nito sa mga reviewer ang pangangatwiran sa likod ng implementasyon. Tinutulungan nito ang mga bagong miyembro ng team na maunawaan kung bakit ganoon ang anyo ng system. Binibigyan nito ang AI ng isang nakaugat na papel: hindi bilang isang orakulo sa loob ng editor, kundi bilang kalahok na kayang magtipon ng ebidensya mula sa kabuuan ng gawain.
Hindi kailanman ang repo mo ang buong kuwento.
Ang oportunidad ay bumuo ng mga system na kayang basahin ang natitira rito—at maipakita kung paano sila nakarating doon.
