Techninės detalės

Agentas dirba jūsų kode. Žmogus patikrina kiekvieną pakeitimą.

„Squirrel“ paima vieną užduotį iš jūsų Plane eigos ir atlieka ją naujoje git worktree su atskira šaka, o tada pateikia pakeitimą peržiūrai. „Squirrel“ kūrėjas jį peržiūri ir įtraukia maždaug per 30 min., o laiko žurnalas įrašomas toje pačioje šakoje, šalia kodo.

Trumpai, kasdieniais žodžiais: jūs surašote užduotį, „Squirrel“ ją atlieka, o „Squirrel“ žmogus patikrina kiekvieną pakeitimą prieš jam pasirodant. Likusi puslapio dalis – techninė to paties sakinio versija, skirta kūrėjui, techniniam patarėjui ar IT partneriui, kuris nori patikrinti mūsų teiginius. Jei norite žinoti tik tai, ką „Squirrel“ nuveikia jūsų verslui, skaitykite verslo puslapį – ten tas pats pasakyta be detalių.

41 „PipelinePharma“ užduotys per 42 mūsų pačių darbo valandų; sąmata – apie 135 vyresniojo kūrėjo valandų.

Persiųsti kolegai

Užduotis įeina – peržiūrėtas pull request išeina

Per vidurį nėra pokalbių lango. Viename gale įeina užduotis, kitame išeina pull request su šaka, commit'ais ir registruotu laiku.

  • Užduotis ir yra instrukcija: jos aprašymas arba komentaras, nuo kurio prasideda darbas. Nereikia atskiro prompt failo, kurį reikėtų sinchronizuoti su bilietu.
  • Agentas dirba savo git worktree ir savo šakoje, todėl jūsų darbinė kopija ir joje esantys neįrašyti pakeitimai neliečiami.
  • Darbas įrašomas dar prieš sesijos pabaigą ir po to dar kartą patikrinamas su git status --porcelain, tad pasibaigusi sesija negali palikti darbo vien agento atmintyje.
  • Antra, atskira sesija registruoja laiką toje šakoje ir įrašo žurnalą, todėl pakeitimui priskirtos valandos guli šalia paties pakeitimo.
  • Pull request atidaromas už jus: gh pr create --fill, o Gitea remote atveju – tea pr create.
  • Rezultatas grįžta kaip Plane komentaras su šakos ir pull request nuorodomis, o užduotis pereina į jūsų nustatytą peržiūros būseną.
  • „Squirrel“ kūrėjas perskaito diff ir jį sujungia. Agentas nesujungia niekada.

Kas iš tikrųjų vyksta ir kokia tvarka

Dauguma agentų sprendimų sugenda ne modelyje, o tarpuose: pakeitimas, kuris nebuvo įrašytas, laikas, kurio niekas neužregistravo, pull request, kurio niekas neatidarė. Kiekvieną žemiau esantį žingsnį užtikrina procesas, o ne tai, kas tą dieną rašo promptą.

  1. 1

    Paleidiklis

    Plane užduotis, priskirta Dumbo arba aiškiai paminėta komentare. Aprašymas arba komentaras, nuo kurio prasideda darbas, ir yra instrukcija.

  2. 2

    Worktree ir aplinka

    Kol modelis dar nepaleistas, užduočiai sukuriama šaka ir worktree, o aplinka paruošiama per SSH: priklausomybės, konfigūracija, virtuali aplinka. Jūsų darbinė kopija neliečiama.

  3. 3

    Taisyklės

    Kiekvienas paleidimas gauna platformos master taisykles prompto pradžioje, o tas blokas aiškiai nurodo, kad jos viršija prieštaraujančias projekto instrukcijas. Jei master taisyklių įkelti nepavyksta, užklausa nutraukiama, o ne paleidžiama be jų. Jūsų AGENTS.md, CLAUDE.md ar .clinerules vis tiek guli worktree ir galioja kodui.

  4. 4

    Kodavimo sesija

    Agentas dirba be sąsajos ir su automatiniais patvirtinimais, naudoja atskirą šakos duomenų katalogą ir aiškiai nurodytus provider, model, raktą bei mąstymo lygį, todėl dvi užduotys tame pačiame serveryje negali perimti viena kitos konfigūracijos. Sesija pagal nutylėjimą ribojama 30 minučių.

  5. 5

    Commit

    Sesijos prašoma įrašyti pakeitimus, bet įrašymu nepasitikima: viskas, kas po sesijos liko neįrašyta, įrašoma iš išorės.

  6. 6

    Laiko žurnalas

    Antra, atskira sesija registruoja laiką tame pačiame worktree ir įrašo žurnalą į šaką. Kodavimo sesijai aiškiai draudžiama registruoti ar minėti laiką, todėl valandos, priskirtos pull request, yra tos, kurios buvo užregistruotos.

  7. 7

    Publikavimas ir tvarkymasis

    Worktree dar kartą patikrinamas su git status --porcelain, šaka nusiunčiama, o worktree pašalinamas. Sesija, kuri nutrūksta pusiaukelėje, negali palikti nepaskelbtos šakos ar likusio katalogo.

  8. 8

    Pull request

    gh pr create --fill atidaro pull request; Gitea remote atveju tą patį daro tea pr create. Release paleidimas pirmiausia įjungia nutolusią numatytąją šaką į užduoties šaką ir paleidžia projekto testus, todėl konfliktai išryškėja dar prieš žmogui žiūrint diff.

  9. 9

    Atsakymas atgal

    Rezultatas ir nuorodos atsiranda kaip komentaras užduotyje, o užduotis pereina į jūsų sukonfigūruotą peržiūros būseną.

Kas lieka jūsų

Jūs neperduodate nei saugyklos, nei standartų. „Squirrel“ kūrėjas peržiūri ir sujungia kiekvieną pull request.

Jūsų taisyklės

Jūsų AGENTS.md, .clinerules ar CLAUDE.md yra worktree ir galioja kodui. Tik tiesioginis konfliktas su master taisyklėmis sprendžiamas jų nenaudai, ir promptas tai pasako, o ne palieka atsitiktinumui.

Jūsų modeliai

Apdorojimo režimas nustatomas projektui. ES režimas kiekvieną užklausą siunčia į OpenRouter ES tašką ir atmeta bet kurį modelį, kurio nėra ES sąraše; globalus režimas vietoj to naudoja provider sąrašą. Jūsų raktas, jūsų pasirinkimas.

Peržiūra ir sujungimas

„Squirrel“ kūrėjas peržiūri ir sujungia kiekvieną pull request. Agentas nesujungia niekada. Tą patį diff galite peržiūrėti šakoje bet kada.

Jūsų pakeitimai

Komentuokite užduotyje, kas turėtų būti kitaip; kitas paleidimas prasideda nuo to komentaro, o ne nuo naujo prompto.

Jūsų saugykla

Prieiga, leidžianti atidaryti pull request; vien deploy raktas tam nepakanka. Jūsų saugykloje nieko diegti nereikia: aplinkos paruošimą ir uždarymą vykdo procesas, o ne jūsų kode įrašyti hook scenarijai.

Jūsų užduočių dydis

Užduotis, kurią vyresnysis kūrėjas įvertintų viena–aštuoniomis valandomis. Didesnis darbas pirmiausia skaidomas, ir būtent tai leidžia peržiūrėti kiekvieną pull request.

Ko jis nedarys

Vertingiausios garantijos yra neigiamos.

  • Nesujungs. Tik pull request: sujungimas yra žmogaus sprendimas ir žmogaus paspaudimas.
  • Netylint nepames sesijos darbo: worktree tikrinamas su git status --porcelain, o viskas, kas liko, įrašoma prieš paskelbiant šaką.
  • Nepaliks worktree: jis pašalinamas, kai šaka nusiunčiama.
  • Nerašys laiko žurnalo į jūsų užduočių sistemą: registravimas vyksta atskiroje sesijoje, su laiku susiję žodžiai iš komentaro išvalomi, o žurnalas patenka į šaką ir kūrėjo el. paštą.
  • Nepersijungs į globalų tašką ES režimu: modelis, kuris neatitinka ES sąlygų, nutraukia užduotį su savo pavadinimu pranešime, o ne tyliai persijungia.
  • Nepaleis be savo taisyklių: trūkstamas taisyklių failas sustabdo paleidimą dar prieš modelį.

Kur patenka kodas ir užklausos

Jūsų kodas tvarkomas MB Pikutis infrastruktūroje: Tier-3 duomenų centre Vilniuje ir įmonės duomenų centre Kaune. MB Pikutis turi ISO/IEC 27001:2022 (LST EN ISO/IEC 27001:2023) sertifikatą, apimantį interneto ir mobiliųjų programų kūrimą, diegimą bei priežiūrą ir hostingo paslaugų teikimą – sertifikatas Nr. 251.2718, galioja iki 2028 m. gruodžio 22 d., sertifikavo UAB SERTIKA.

Modelio išvados keliauja per OpenRouter, naudojant tą tašką, kuriam sukonfigūruotas projektas. ES režimu užklausos eina į https://eu.openrouter.ai/api/v1, o kiekvienas sukonfigūruotas modelis – pagrindinis ir kiekvienas atsarginis – prieš paleidimą tikrinamas pagal OpenRouter ES modelių sąrašą; auto-maršrutizavimo modeliai ir batch API atmetami, o atsarginį modelį turi teikti kitas provider nei pagrindinį. Globaliu režimu užklausos eina į OpenRouter globalų tašką su provider sąrašu.

Joks API raktas nėra įrašytas procese ar išspausdinamas žurnaluose. Worktree pašalinami, kai kodavimas baigtas, o prieiga prie saugyklos panaikinama uždarant kliento projektą – ir tai, ką sukuriame, priklauso jums.

Detalės čia: Security, Privacy, Data processing agreement

Prieš kiekvieną diegimą atliekama žinomų saugumo problemų patikra

Prieš pakeitimui pasirodant, jo paleidimui skirtas image‘as patikrinamas mūsų Harbor konteinerių registre. Tikrinamas kiekvienas diegiamas image‘as, o image‘as, kuris patikros nepereina, neįdiegiamas.

Patikra ieško žinomų saugumo problemų image‘e – dalių, iš kurių jis sudarytas, ir to, ką jos žinomai turi. Tai žinomų problemų patikra, o ne teiginys, kad kuris nors diegimas neturi pažeidžiamumų, ir ji nepakeičia žmogaus, kuris perskaito pakeitimą.

Neskelbiame skenerio pavadinimo, pereinamųjų slenksčių ar patikros dažnumo: tai registro nustatymai, kurie gali keistis nekeičiant paslaugos.

Kur to nepakanka

Perskaitykite tai prieš demonstraciją. Tai mažas, peržiūrėtas darbo vienetas, o ne komanda.

Peržiūra yra lubos

Kiekvienas pull request laukia maždaug 30 min. „Squirrel“ kūrėjo peržiūros. Ta peržiūra yra registruotose valandose, tad už ją mokama, o ne gaunama nemokamai – ir būtent ji riboja pralaidumą.

Užduoties forma svarbi

Geriausiai sekasi užduotys, kurias vyresnysis įvertintų viena–aštuoniomis valandomis. Duokite neaiškų epą – gausite neaiškų pull request; skaidymas yra darbų dalis.

Dvi užduočių sistemos, du git serveriai

Plane užduotims; GitHub arba Gitea pull requestams. Šiame procese šiandien nėra Jira ar Linear kelio.

ES režimas yra sąrašas

Jis garantuoja tašką ir tai, kad modeliai yra OpenRouter ES sąraše. Jis pats neatsako į visus duomenų rezidentiškumo ar saugojimo klausimus apie konkretų provider – paklauskite to, kurio jums reikia.

Sprendimus priima žmogus

Agentas atlieka apibrėžtą užduotį. Architektūra, produkto sprendimai ir galutinis žodis, kas išleidžiama, lieka jūsų komandai.

Terminas įprastas, ne garantuotas

Pristatymai dažniausiai tą pačią dieną. Eilė, platformos sutrikimas ar didesnė nei įvertinta užduotis tai pakeičia.

Susikurkite procesą patys arba naudokitės juo

Didžiąją šio puslapio dalį galima atkartoti: įrankiai atviri, o worktree–pull request ciklas – geras savaitgalis skriptų. Sąžiningas skirtumas yra visa tai, ką po to reikėtų nuolat palaikyti.

Susikurkite procesą patys arba naudokitės juo
Ko reikia Jei kuriate patys Su „Squirrel“
Užduoties pradžia Įklijuokite bilietą į pokalbių langą ir diff grąžinkite ranka. Priskirkite užduotį Dumbo arba paminėkite jį komentare. Bilietas ir yra instrukcija.
Izoliacija Leiskite agentui redaguoti jūsų darbinę kopiją ir tikrinkite, ką jis paliko. Nauja šaka ir worktree kiekvienai užduočiai, pašalinami paskelbus šaką.
Taisyklės ir standartai Kiekvieną kartą iš naujo įklijuokite savo taisykles į promptą ir tikėkitės, kad jos išliks. Master taisyklės įterpiamos kiekvieną kartą, o jūsų saugyklos agentų failai vis tiek taikomi.
Nenutolimas nuo main Fetch, merge, konfliktų sprendimas ir testų paleidimas – jūsų pačių rankomis. Release paleidimas įjungia nutolusią numatytąją šaką į užduoties šaką ir paleidžia projekto testus prieš pull request.
Neįrašytas darbas Sužinokite iš git status, kad sesija redagavo failus ir nieko neįrašė. Worktree tikrinamas su git status --porcelain, o viskas, kas liko, įrašoma prieš publikavimą.
Pull request Aprašymą rašykite iš atminties arba iš diff. gh pr create --fill (arba tea pr create), o rezultatas ir nuorodos atsiranda kaip komentaras užduotyje.
Modelio duomenų kelias Tai, ką numato jūsų gateway, ir įrodymas, kad taip ir liko. Projektui nustatytas ES arba globalus režimas, o kiekvienas modelis patikrinamas pagal OpenRouter ES sąrašą prieš ES paleidimą.
Laiko apskaita Spėliokite, kiek paleidimas truko, jau po fakto. Atskira sesija registruoja laiką ir įrašo žurnalą į šaką kartu su kodu.
Peržiūra Jūs skaitote kiekvieną diff arba kažkas išleidžiama neperžiūrėta. „Squirrel“ kūrėjas peržiūri kiekvieną pull request (apie 30 min.) ir jį sujungia.
Palaikymas Jums lieka runner'iai, hook'ai, paslaptys, pakartojimai ir žmogus, kuris tai išmano. Hostinga: nuo €1,880 per mėnesį už 16 registruotų valandų; papildomos valandos – €55.

Kairysis stulpelis aprašo darbą, o ne konkurentą. Planai: Starter – €1,880/mėn. su 16 registruotų valandų (įdiegimas €490); Team – €2,908/mėn. su 36 registruotų valandų (įdiegimas netaikomas, kai terminas ne trumpesnis nei trys mėnesiai); papildomos valandos – €55; kainos be PVM; AI naudojimas iki €150 vienam projektui per mėnesį įskaičiuotas.

Ką „Squirrel“ daro, o ko – ne

Trumpas sąrašas, pagal kurį prašome mus vertinti. Abi pusės yra paslaugos dalis.

„Squirrel“ daro

  • Kiekvieną užduotį atlieka savoje kodo kopijoje ir savoje šakoje, tad jūsų darbo kopija ir neįrašyti pakeitimai neliečiami.
  • Paleidžia projekto automatinius patikrinimus dar prieš žmogui perskaitant pakeitimą.
  • Kiekvieną pakeitimą pateikia „Squirrel“ kūrėjui, kuris jį peržiūri ir nusprendžia, ar jis įtraukiamas.
  • Užduočiai skirtą laiką įrašo šalia pakeitimo, kad valandas būtų galima palyginti su darbu.
  • Prieš diegimą patikrina image‘ą dėl žinomų saugumo problemų ir sustabdo image‘ą, kuris patikros nepereina.
  • Modelio užklausas siunčia tik į ES arba globalų tašką, kuriam projektas sukonfigūruotas, ir atsisako modelio, kuris ten neleidžiamas.

„Squirrel“ nedaro

  • Neįtraukia savo darbo pats: įtraukimas yra žmogaus sprendimas ir žmogaus paspaudimas.
  • Neišgalvoja apimties. Užduotį rašote jūs; mes darome tai, kas joje parašyta.
  • Nepakeičia komandos. Tai vienas mažas, peržiūrėtas darbas vienu metu.
  • Neskatina programinės įrangos be pažeidžiamumų. Patikra randa žinomas problemas image‘e, bet negali įrodyti, kad kodas saugus.
  • Nepalieka jūsų kodo darbo kopijos: ji pašalinama baigus kodavimą, o prieiga panaikinama uždarius projektą.
  • ES režimu tyliai nepersijungia modelių. Modelis, kuris neatitinka ES sąlygų, nutraukia užduotį ir tai nurodo.

FAQ

Klausimai, kuriuos kūrėjai užduoda pirmiausia

Tai, ką išgirstame iš žmonių, kurie skaitys diff'us.

  • Ar jūs gaunate teisę sujungti į main?

    Ne. Mums reikia prieigos, leidžiančios kurti pull request; vien deploy raktas tam nepakanka. Agentas niekada nesujungia: kiekvieną pull request peržiūri ir sujungia „Squirrel“ kūrėjas, o jūsų šakų apsaugos taisyklės lieka galioti.

  • Koks modelis iš tikrųjų vykdo mano kodą?

    Tai, kas nustatyta projektui: pagrindinis modelis ir jo atsarginiai, patikrinti prieš paleidimą. ES režimu kiekvienas jų turi būti OpenRouter ES modelių sąraše, o auto-maršrutizavimo modeliai ir batch API atmetami. Fiksuoto modelių sąrašo neskelbiame, nes jis kinta greičiau nei puslapis.

  • O jei pull request neteisingas?

    Komentuokite užduotyje, kas turėtų būti kitaip. Kitas paleidimas prasideda nuo to komentaro, toje pačioje šakoje, o diff visą laiką lieka peržiūrimas.

  • Ar jis liečia mano darbinę kopiją?

    Neliečia. Darbas vyksta atskiroje šakoje ir worktree, kuriuos sukuria ir pašalina procesas, todėl jūsų darbinėje kopijoje esantys neįrašyti pakeitimai niekada nekelia rizikos.

  • Ką reikia įdiegti mano saugykloje?

    Nieko. Aplinkos paruošimas ir uždarymas yra komandos, kurias procesas vykdo per SSH, o ne jūsų saugykloje įrašyti hook scenarijai. Jei jau turite AGENTS.md, CLAUDE.md ar .clinerules, jie yra gerbiami. Dar neturite lentos ar saugyklos? Abu sutvarkome už jus, o CI/CD procesas ir testavimo aplinka ateina kartu.

  • Kaip matuojamas laikas?

    Atskira registravimo sesija užrašo jį prie šakos ir įrašo žurnalą kartu su kodu, todėl pakeitimui priskirtas valandas galima patikrinti pagal patį pakeitimą.

  • Ar galiu pamatyti, ką agentas iš tikrųjų padarė?

    Plane komentare yra rezultatas ir šakos bei pull request nuorodos. Pull request turi commit'us ir diff – tą patį diff, kurį skaitė peržiūrėtojas.

  • Kiek tai kainuoja?

    Nuo €1,880 per mėnesį už 16 registruotų valandų, papildomos valandos – €55; peržiūra įskaičiuota į tas valandas. Team – €2,908 per mėnesį už 36 registruotų valandų. Įdiegimas – vienkartiniai €490, netaikomi Team planui, kai terminas ne trumpesnis nei trys mėnesiai. Kainos be PVM.

  • O kaip „GitHub Copilot“?

    Copilot – tai įrankis kūrėjams, kuriuos jau samdote: jo kodavimo agentas gali paimti priskirtą GitHub užduotį ir atidaryti juodraštinį pull request, o Copilot palaiko ES duomenų saugojimą „GitHub Enterprise Cloud“ su data residency (patikrinta pagal viešą „GitHub“ dokumentaciją, 2026 m. lapkritį). Vis tiek reikia žmogaus, kuris apibrėžtų užduotį, peržiūrėtų diff ir už jį atsakytų. „Squirrel“ tą žmogų suteikia.

  • Kas nutinka mano saugyklai ir prieglobai, kai nustojame dirbti?

    Saugykla ir rezultatai lieka jums. Worktree pašalinami, kai kodavimas baigtas, o mūsų prieiga prie saugyklos panaikinama uždarant projektą. Priegloba atskira: testavimo ir produkcinė aplinka tęsiasi MB Pikutis infrastruktūroje tiek, kiek jos norėsite.

Atvejo analizės akcentas

Įrodymai iš įgyvendintų darbų

Įgyvendinti svetainės darbai

„PipelinePharma“: 41 užduotis, kiekviena peržiūrėta

Svetainės darbų sąrašas įgyvendintas per 42 darbo valandas – kiekvieną pakeitimą prieš paleidžiant patikrino žmogus.

3.2x greičiau su 41 užduotimis, matuota viename projekte

Mūsų 42 darbo valandos pakeitė apie 135 vyresniojo kūrėjo darbo valandas.

Skaityti „PipelinePharma“ atvejo analizę  

Atsiųskite užduotį, perskaitykite pull request

Vienos užduoties pakanka tam įvertinti. Atsiųskite iki trijų – grįšime su apimties įvertinimu, arba rezervuokite demonstraciją ir pažiūrėkite, kaip užduotis įvykdoma nuo pradžios iki galo.

Pažiūrėti „PipelinePharma“ skaičius