Kā automatizēt manuālo darbu īpašuma tiesību pārbaudē

Un katrs štats spēlē pēc saviem noteikumiem. Ūdens tiesības Nevadā nestrādā tā kā Pensilvānijā. Noteikumi par pārvietojamām mājām mainās no apgabala uz apgabalu. Brīdinājums Floridā var neko nenozīmēt Ohaio. Pārbaudes kodu ir simtiem, un pareizais ir atkarīgs no dokumenta veida, štata un darījuma.

Tikai Pensilvānijā operācija apstrādā tūkstošiem pasūtījumu dienā.

Pirms AI viss bija manuāli. Pārbaudītājs atvēra milzīgu piegādātāja paketi, vienu PDF, kas dažreiz pārsniedza 100 lapas, un sadalīja to ar rokām. Izlasīja katru dokumentu pret kontrolsarakstu. Salīdzināja juridiskos aprakstus. Iezīmēja robežu koordinātas ārējā rīkā. Piešķīra pārbaudes kodus, pārlūkojot bibliotēku ar simtiem ierakstu. Atzīmēja visu aizdomīgo.

Katrs pasūtījums. Katru dienu. Milzīgs daudzums prasmīga, bet atkārtojoša darba.

Skaitlis jau bija aprēķināts. AI bija jāpārņem atkārtojošais darbs, lai komanda varētu pievērsties spriedumiem, kuriem patiešām vajag cilvēka pieredzi.

Ambīcijai bija arī disciplīna. Nebija vēlmes vienā dienā pārslēgt visu uz pilnu automatizāciju.

Pieeja bija cita. Cilvēks paliek cilpā. AI dara darbu, pārbaudītājs to apstiprina. Precizitāti mēra. Ja 99 no 100 rezultātiem lietotājs apstiprina, šo soli var automatizēt pilnībā.

Eksperimentēt. Mērīt. Pielāgot. Paplašināt tikai tad, kad dati saka, ka tas ir droši.

Šis princips noteica katru nākamo lēmumu.

Loģika bija vienkārša: mēs to uzbūvējām divās nedēļās, jūs esat profesionāļi, jums vajadzētu tikt galā divās dienās. Tādas bija cerības.

Nācās paskaidrot, ka prototips nav produkts. Gatavs produkcijai nozīmē drošību, mērogojamību, īstu datubāzi un integrāciju ar dzīviem pasūtījumu datiem. Tas nozīmē, ka rīks strādā, kad uz to katru dienu paļaujas tūkstošiem cilvēku.

Grūtākā daļa bija to pierādīt, piegādājot ātri.

UX dizainers savāca prasības, ielika tās Figma Make un dažu stundu laikā ieguva koncepta ekrānus. Nākamajā dienā dizains bija gatavs. Frontend komanda kodam izmantoja Cursor, Claude un Copilot. Backend komanda funkcijām izmantoja Claude Sonnet un Cursor. Jira tika iestatīts Rovo AI aģents, kas no projekta dokumentācijas automātiski sagatavoja un precizēja lietotāju stāstus.

Pirmais produkcijai gatavais produkts tika piegādāts trīs nedēļās.

AI nebija tikai tas, ko būvēja. AI bija veids, kā to būvēja.

Intervētajiem šī joma bija pilnīgi jauna. Viņi nebija AI entuziasti. Nebija lietojuši AI rīkus. Nezināja, ko gaidīt, ko AI prot un ko paši no tā grib.

Izpēte aizņēma vairāk laika nekā pirmā prototipa būvēšana. Rezultāts bija neskaidri punkti, kurus vadība neapstiprināja un neprioritizēja.

Tāpēc komanda pārstāja mēģināt izvilkt prasības no cilvēkiem, kuri produktu vēl nevarēja iedomāties. Saīsināt ceļu līdz tirgum. Noklāt kritisko funkcionalitāti, to nesarežģījot. Palaist produkcijā, lai reāli lietotāji sāk rīku lietot. Tad uzlabot pēc īstas uzvedības, nevis hipotētiskām intervijām.

Tas kļuva par darba principu. Vadība deva funkciju sarakstu, komanda palīdzēja prioritizēt pēc biznesa vērtības, un piegāde gāja īsos soļos.

Kvalitātes pārbaudēs lēmumu koki ir iebūvēti uzvednēs. Modelis brīvi nespriež, kas varētu būt problēma. Tas iet pa ceļu. Vai dokumentā ir minētas pārvietojamās mājas? Ja jā, pārbauda konkrētos noteikumus šim dokumenta veidam. Ja nē, iet tālāk. Katrs zars beidzas ar skaidru lēmumu. Modelis katru reizi uzdod tos pašus jautājumus. Paredzams ir labāk nekā gudrs.

Uzvedņu izpēte sākās ar diviem lielākā apjoma štatiem, Pensilvāniju un Floridu, un tos izmantoja kā bāzi. Mēģinājums pirmajā dienā nosegt katru izņēmumu katrā štatā procesu noslīcinātu troksnī.

Tonis izrādījās tikpat svarīgs kā precizitāte. Kad AI problēmas atzīmēja ar frāzi “tas ir nepareizi”, pārbaudītāji asi iebilda un negatīvās atsauksmes strauji pieauga. Labojums bija pārrakstīt visu kā ieteikumu. “Mēs redzam šo, bet jūsu title atskaitē ir minēts X. Ir vērts paskatīties.” Tā pati informācija. Pavisam cita reakcija.

Tas, kā AI runā ar lietotāju, nosaka, vai to pieņem vai pret to cīnās.

TitleFlow tam pieslēdzas. Palīdzības dienests tiek integrēts. Nākamais ir iekšējais projekts SDA. Viens dzinējs apkalpo vairākas platformas, nedublējot infrastruktūru.

Datu piekļuvei komanda uzbūvēja MCP serveri. Modelim vajag pasūtījuma detaļas, piegādes vēsturi, pārbaudes kodus un pārējos biznesa datus, kas dzīvo TitleFlow. Serveris tos padara pieejamus kā rīkus. Jauns rīks ir konfigurācijas izmaiņa, nevis koda izmaiņa.

Drošība balstās uz deleģēšanas tokenu. MCP serveris ir publiskajā internetā, bet dati aiz tā ir sensitīva juridiska informācija. Reālu piekļuves datu vietā sistēma izsniedz īslaicīgus tokenus ar ierobežotām tiesībām. Tikai lasīšana vienai mapei, nevis atslēgas visam kontam. Ja tokens noplūst, kaitējums paliek ierobežots.

Dažas ķēdes aizņem 10 līdz 15 minūtes. Izpilde pārgāja no sinhronas uz asinhronu, lai cilvēki var turpināt strādāt, kamēr AI darbojas fonā.

Kad primārais pakalpojumu sniedzējs bija četras stundas nepieejams, automātiska pārslēgšanās pārgāja uz rezerves modeli un serviss palika augšā. Primārais modelis tika izvēlēts juridiskās jomas dēļ. Noturība tik un tā nozīmē, ka rezerve vienmēr ir gatava.

Maza komanda piegādāja tempā, kāds parasti prasa daudz lielāku komandu. Trīs nedēļas sešu mēnešu vietā pirmajam produktam, un pēc tam nepārtraukta funkciju plūsma.

Ar to, kas jau ir produkcijā, klients ir sasniedzis 30% no gada izmaksu ietaupījuma mērķa.

Dzinējs turpina augt. Palīdzības dienesta integrācija ir procesā. Nākamais ir SDA. Jaunas uzvedņu ķēdes turpina iznākt, balstoties uz reālu lietotāju atsauksmēm.

Sistēma netika būvēta no jauna. AI slānis tika pievienots uzmanīgi, un lietotāji tika virzīti uz to soli pa solim, katrā posmā pierādot vērtību.