Ietvara inženierija: Codex lietojums aģentu prioritārajā pasaulē

Pēdējo piecu mēnešu laikā mūsu komanda ir veikusi eksperimentu: izstrādājot un piegādājot programmatūras produkta iekšējo beta versiju ar 0 manuāli rakstītām koda rindiņām.

Produktam ir iekšējie ikdienas lietotāji un ārējie alfa testētāji. Tas piegādā, izvieto, salūst un tiek salabots. Atšķirība ir tāda, ka katra koda rinda—lietojumprogrammas loģika, testi, CI (nepārtrauktās integrācijas) konfigurācija, dokumentācija, novērojamība un iekšējie rīki—ir rakstīta ar Codex. Mēs lēšam, ka mēs to izveidojām aptuveni 1/10 no laika, kas būtu bijis nepieciešams, lai kodu uzrakstītu ar roku.

Cilvēki vada. Aģenti izpilda.

Mēs apzināti izvēlējāmies šo ierobežojumu, lai izveidotu to, kas bija nepieciešams, lai būtiski palielinātu inženierijas ātrumu. Mums bija vairākas nedēļas, lai piegādātu to, kas beigās izrādījās miljons koda rindu. Lai to izdarītu, mums vajadzēja saprast, kas mainās, kad programmatūras izstrādes komandas galvenais uzdevums vairs nav rakstīt kodu, bet gan izstrādāt vides, noteikt ieceri un veidot atgriezeniskās saites ciklus, kas ļauj Codex aģentiem veikt uzticamu darbu.

Šis ieraksts ir par to, ko mēs iemācījāmies, veidojot pilnīgi jaunu produktu ar aģentu komandu—kas neizdevās, kas uzkrājās, un kā maksimāli izmantot mūsu vienīgo patiesi ierobežoto resursu: cilvēka laiku un uzmanību.

Pirmais iesūtījums tukšā repozitorijā tika veikts 2025. gada augusta beigās.

Sākotnējais karkass—repozitorija struktūra, CI konfigurācija, formatēšanas noteikumi, pakotņu pārvaldnieka iestatīšana un lietojumprogrammas ietvars—tika ģenerēts ar Codex CLI, izmantojot GPT‑5, vadoties pēc neliela esošo veidņu kopuma. Pat sākotnējo AGENTS.md failu, kas aģentiem norāda, kā strādāt repozitorijā, bija uzrakstījis Codex.

Nebija iepriekš izstrādāta cilvēka rakstīta koda, kas sistēmai kalpotu par atskaites punktu. No paša sākuma repozitoriju veidoja aģents.

Pēc pieciem mēnešiem repozitorijs satur aptuveni miljonu koda rindu, kas aptver lietojumprogrammas loģiku, infrastruktūru, rīkus, dokumentāciju un iekšējos izstrādātāju rīkus. Šajā periodā tika atvērti un sapludināti aptuveni 1500 pull request, un Codex virzīja neliela komanda — tikai trīs inženieri. Tas nozīmē vidējo caurlaidspēju 3,5 PRs uz vienu inženieri dienā, un pārsteidzoši, ka caurlaidspēja ir palielinājusies, komandai pieaugot līdz septiņiem inženieriem. Svarīgi, ka šī izvade netika radīta tikai izvades dēļ: produktu iekšēji ir izmantojuši simtiem lietotāju, tostarp ikdienas iekšējie pieredzējušie lietotāji.

Visā izstrādes procesā cilvēki nekad tieši nepiedalījās koda veidošanā. Tas kļuva par komandas pamatfilozofiju: nekāds manuāli rakstīts kods.

Praktiskas cilvēku veiktas programmēšanas trūkums ieviesa cita veida inženiertehnisko darbu, kas koncentrējas uz sistēmām, atbalsta struktūrām un ietekmi.

Sākotnējais progress bija lēnāks, nekā mēs gaidījām, nevis tāpēc, ka Codex nebija spējīgs, bet gan tāpēc, ka vide bija nepietiekami definēta. Aģentam trūka rīku, abstrakciju un iekšējās struktūras, kas bija nepieciešami, lai virzītos uz augsta līmeņa mērķiem. Mūsu inženieru komandas galvenais uzdevums kļuva nodrošināt, lai aģenti varētu veikt noderīgu darbu.

Praksē tas nozīmēja strādāt pēc “depth-first” principa: sadalīt lielākus mērķus mazākos veidošanas blokos (dizains, kods, pārskatīšana, testēšana u.c.), mudināt aģentu izveidot šos blokus un izmantot tos, lai atbloķētu sarežģītākus uzdevumus. Kad kaut kas neizdevās, risinājums gandrīz nekad nebija “pacenties vairāk.” Tā kā vienīgais veids, kā panākt progresu, bija panākt, lai Codex paveic darbu, cilvēku inženieri vienmēr iesaistījās uzdevumā un jautāja: “kādas iespējas trūkst, un kā mēs varam panākt, lai tās aģentam būtu gan saprotamas, gan izpildāmas?”

Cilvēki mijiedarbojas ar sistēmu gandrīz tikai caur uzvednēm: inženieris apraksta uzdevumu, palaiž aģentu un ļauj tam atvērt pull request. Lai pabeigtu PR, mēs norādām Codex lokāli pārskatīt savas izmaiņas, pieprasīt papildu konkrētas aģentu pārskatīšanas gan lokāli, gan mākonī, atbildēt uz jebkuru cilvēka vai aģenta sniegto atgriezenisko saiti un atkārtot procesu ciklā, līdz visi aģentu pārskatītāji ir apmierināti (faktiski tas ir Ralph Wiggum Loop⁠(atveras jaunā logā)). Codex tieši izmanto mūsu standarta izstrādes rīkus (gh, lokālos skriptus un repozitorijā iebūvētās prasmes), lai apkopotu kontekstu, neiesaistot cilvēkus kopēšanā un ielīmēšanā CLI.

Cilvēki var pārskatīt pull request, bet tas nav obligāti. Laika gaitā mēs esam novirzījuši gandrīz visu pārskatīšanas darbu uz aģentu savstarpēju apstrādi.

Palielinoties koda caurlaidspējai, par mūsu vājo vietu kļuva cilvēku kvalitātes nodrošināšanas kapacitāte. Tā kā fiksētais ierobežojums ir bijis cilvēka laiks un uzmanība, mēs esam strādājuši, lai aģentam pievienotu vairāk iespēju, padarot tādas lietas kā lietotnes lietotāja saskarni, žurnālus un lietotnes metriku tieši salasāmas Codex.

Piemēram, mēs padarījām lietotni palaižamu katram git darba kokam (worktree), lai Codex varētu palaist un vadīt vienu instanci katrai izmaiņai. Mēs arī integrējām Chrome DevTools protokolu aģenta izpildlaikā un izveidojām prasmes darbam ar DOM momentuzņēmumiem, ekrānuzņēmumiem un navigāciju. Tas ļāva Codex reproducēt kļūdas, validēt labojumus un tieši analizēt lietotāja saskarnes uzvedību.

Mēs darījām to pašu ar novērojamības rīkiem. Žurnāli, metrikas un izsekojumi ir pieejami Codex, izmantojot lokālu novērojamības kaudzi, kas ir īslaicīga jebkuram konkrētajam darbstāvam. Codex darbojas ar pilnībā izolētu šīs lietotnes versiju, ieskaitot tās žurnālus un metrikas, kas tiek izdzēstas, tiklīdz uzdevums ir pabeigts. Aģenti var veikt vaicājumus žurnālos, izmantojot LogQL, un metriku vaicājumus, izmantojot PromQL. Ja ir pieejams šāds konteksts, ir iespējams izpildīt tādus norādījumus kā "nodrošināt, lai pakalpojuma palaišana tiktu pabeigta ātrāk par 800 ms" vai "neviens no šo četru kritisko lietotāju ceļojumu posmiem nepārsniedz divas sekundes".

Mēs regulāri novērojam, ka atsevišķas Codex palaišanas strādā pie viena uzdevuma vairāk nekā sešas stundas (bieži vien, kamēr cilvēki guļ).

Konteksta pārvaldība ir viens no lielākajiem izaicinājumiem, lai aģenti būtu efektīvi lielu un sarežģītu uzdevumu veikšanā. Viena no pirmajām mācībām, ko apguvām, bija vienkārša: dod Codex karti, nevis 1000 lappušu instrukciju rokasgrāmatu.

Mēs izmēģinājām “vienu lielu AGENTS.md⁠(atveras jaunā logā)” pieeju. Tas neizdevās paredzamos veidos:

• Konteksts ir ierobežots resurss. Milzīgs instrukciju fails izspiež uzdevumu, kodu un attiecīgo dokumentāciju, tāpēc aģents vai nu palaiž garām galvenos ierobežojumus vai arī sāk optimizēt nepareizos.
• Pārāk daudz norādījumu liek zaudēt vadību. Kad viss ir “svarīgs”, nekas nav svarīgs. Aģenti galu galā sāk lokāli saskaņot paraugus, nevis apzināti virzīties.
• Tas uzreiz sairst. Monolīta rokasgrāmata pārvēršas par novecojušu noteikumu kapsētu. Aģenti nevar noteikt, kas joprojām ir patiess, cilvēki pārstāj to uzturēt, un fails klusi kļūst par pievilcīgu traucēkli.
• Ir grūti pārbaudīt. Viens vienīgs bloks nav piemērots mehāniskām pārbaudēm (pārklājums, aktualitāte, atbildība, krustsaites), tāpēc novirze ir neizbēgama.

Tā vietā, lai AGENTS.md uzskatītu par enciklopēdiju, mēs to uzskatām par satura rādītāju.

Repozitorija zināšanu bāze atrodas strukturētā docs/ direktorijā, kas tiek uzskatīta par sistēmas reģistru. Īss AGENTS.md (aptuveni 100 rindiņas) tiek ievietots kontekstā un galvenokārt kalpo kā karte ar norādēm uz dziļākiem patiesības avotiem citur.

Projektēšanas dokumentācija ir katalogizēta un indeksēta, tostarp verifikācijas statuss un pamatuzskatu kopums, kas definē "aģents pirmajā vietā" darbības principus. Arhitektūras dokumentācija⁠(atveras jaunā logā) sniedz augsta līmeņa pārskatu par domēniem un pakotņu slāņojumu. Kvalitātes dokuments novērtē katru produkta domēnu un arhitektūras slāni, izsekojot nepilnības laika gaitā.

Plāni tiek uzskatīti par pirmšķirīgiem materiāliem. Nelielām izmaiņām izmanto īslaicīgus vieglus plānus, bet sarežģītus darbus fiksē. izpildes plānos⁠(atveras jaunā logā) ar progresa un lēmumu žurnāliem, kas tiek pārbaudīti repozitorijā. Aktīvie plāni, pabeigtie plāni un zināmie tehniskie parādi ir saistīti ar versijām un atrodas vienkopus, ļaujot aģentiem darboties, nepaļaujoties uz ārējo kontekstu.

Tas nodrošina pakāpenisku atklāšanu: aģenti sāk ar nelielu stabilu sākumpunktu un tiek mācīti, kur meklēt tālāk, nevis tiek pārslogoti jau sākumā.

Mēs to īstenojam mehāniski. Atsevišķi linteri un CI uzdevumi pārbauda, vai zināšanu bāze ir aktuāla, savstarpēji sasaistīta un pareizi strukturēta. Regulāri strādājošs "doc-gardening" aģents pārbauda, vai dokumentācija nav novecojusi vai novecojusi un neatspoguļo reālo koda uzvedību, un atver pull request.

Attīstoties kodu bāzei, arī Codex sistēmai dizaina lēmumu pieņemšanai bija jāattīstās.

Tā kā repozitorijs ir pilnībā aģenta ģenerēts, tas vispirms ir optimizēts Codex lasāmībai. Tāpat kā komandas cenšas uzlabot sava koda pārskatāmību jaunajiem inženieriem, mūsu inženieru mērķis bija panākt, lai aģents varētu izprast visu biznesa domēnu tieši no paša repozitorija.

No aģenta viedokļa, viss, kam tas nevar piekļūt kontekstā, darbojoties efektīvi, faktiski neeksistē. Zināšanas, kas atrodas Google Docs, tērzēšanas pavedienos vai cilvēku galvās, nav pieejamas sistēmai. Tas redz tikai repozitorija vietējos versiju artefaktus (piemēram, kodu, marķējumu, shēmas, izpildāmos plānus).

Mēs uzzinājām, ka laika gaitā mums vajadzēja ievietot arvien vairāk konteksta repozitorijā. Tā Slack diskusija, kas saskaņoja komandu par arhitektūras modeli? Ja aģents to nevar atrast, tas ir nesaprotams tāpat kā tas būtu nezināms jaunam darbiniekam, kas pievienojas pēc trim mēnešiem.

Piešķirt Codex vairāk konteksta nozīmē sakārtot un atklāt pareizo informāciju, lai aģents varētu to izmantot loģiskai analīzei, nevis pārslogot to ar ad hoc norādījumiem. Tāpat kā tu iepazīstinātu jaunu komandas biedru ar produkta principiem, inženierijas normām un komandas kultūru (ieskaitot emocijzīmju izvēles), šīs informācijas sniegšana aģentam nodrošina labāk saskaņotu rezultātu.

Šis ierāmējums precizēja daudzus kompromisus. Mēs devām priekšroku atkarībām un abstrakcijām, kuras varēja pilnībā iekšēji apgūt un izprast repozitorijā. Tehnoloģijas, kuras bieži raksturo kā “garlaicīgas”, aģentiem ir vieglāk modelēt, pateicoties to kompozīcijai, API stabilitātei un pārstāvniecībai apmācību kopā. Dažos gadījumos bija lētāk aģentam no jauna ieviest funkcionalitātes apakškopas, nekā apiet publisko bibliotēku neskaidro augšupstraumes uzvedību. Piemēram, tā vietā, lai izmantotu vispārīgu p-limit-stila pakotni, mēs izstrādājām savu map-with-concurrency palīgfunkciju: tā ir cieši integrēta ar mūsu OpenTelemetry instrumentāciju, tai ir 100% testu pārklājums un tā darbojas tieši tā, kā to paredz mūsu izpildlaiks.

Iekļaujot vairāk sistēmas tādā formā, ko aģents var pārbaudīt, validēt un tieši modificēt, palielinās ietekme—ne tikai Codex, bet arī citiem aģentiem (piemēram, Aardvark) kas arī strādā pie koda bāzes.

Dokumentācija vien nespēj nodrošināt pilnībā aģenta ģenerētas koda bāzes saskaņotību. Nodrošinot invariantu ievērošanu, nevis mikropārvaldot īstenojumus, mēs ļaujam aģentiem ātri piegādāt, neapdraudot pamatus. Piemēram, mēs pieprasām, lai Codex analizētu datu struktūras pie robežas⁠(atveras jaunā logā), bet neesam noteikuši, kā tam jānotiek (modelim šķietami patīk Zod, bet mēs nenorādījām konkrētu bibliotēku).

Aģenti ir visefektīvākie vidēs ar stingrām robežām un paredzamu struktūru⁠(atveras jaunā logā), tāpēc mēs izveidojām lietotni, balstoties uz stingru arhitektūras modeli. Katrs biznesa domēns ir sadalīts noteiktā slāņu kopā ar stingri pārbaudītiem atkarību virzieniem un ierobežotu pieļaujamo malu kopu. Šie ierobežojumi tiek mehāniski ieviesti, izmantojot pielāgotus linterus (protams, Codex ģenerētus!) un strukturālos testus.

Zemāk redzamā diagramma parāda noteikumu: katrā uzņēmējdarbības jomā (piemēram, Lietotnes iestatījumi), kods var būt atkarīgs tikai “uz priekšu” caur noteiktu slāņu kopu (Types → Config → Repo → Service → Runtime → UI). Šķērsgriezuma aspekti (autentifikācija, savienotāji, telemetrija, funkciju karogi) tiek ievadīti caur vienu skaidri definētu saskarni: Providers. Viss pārējais ir aizliegts un tiek mehāniski īstenots.

Šāda veida arhitektūru parasti atliek līdz brīdim, kad pieejami simtiem inženieru. Programmēšanas aģentu gadījumā tas ir agrīns priekšnosacījums: ierobežojumi ir tie, kas ļauj nodrošināt ātrumu bez degradācijas vai arhitektūras novirzes.

Praksē mēs īstenojam šos noteikumus, izmantojot pielāgotus linterus un strukturālos testus, kā arī nelielu “gaumes invariantu” kopumu. Piemēram, mēs statiski nodrošinām strukturētu žurnālu veidošanu, nosaukšanas konvencijas shēmām un tipiem, faila lieluma ierobežojumus un platformai specifiskas uzticamības prasības, izmantojot pielāgotus lintus. Tā kā linti ir pielāgoti, mēs veidojam kļūdu ziņojumus, lai aģenta kontekstā ievietotu novēršanas instrukcijas.

Cilvēkam prioritāri pielāgotā darbplūsmā šie noteikumi var šķist pedantiski vai ierobežojoši. Ar aģentiem tie kļūst par reizinātājiem: kad tie ir iekodēti, tie tiek pielietoti visur vienlaicīgi.

Tajā pašā laikā mēs skaidri norādām, kur ierobežojumi ir svarīgi un kur tie nav svarīgi. Tas līdzinās lielas inženierijas platformas organizācijas vadīšanai: centrāli noteikt robežas, lokāli piešķirt autonomiju. Tev ļoti rūp robežas, precizitāte un atkārtojamība. Šajās robežās tu piešķir komandām—vai aģentiem—ievērojamu brīvību, kā risinājumi tiek izteikti.

Iegūtais kods ne vienmēr atbilst cilvēku stilistiskajām vēlmēm, un tas ir pieņemami. Kamēr izvade ir pareiza, uzturama un salasāma turpmākajām aģenta palaišanām, tā atbilst prasībām.

Cilvēka gaume tiek nepārtraukti integrēta sistēmā. Pārskatīšanas komentāri, pull request refaktorēšanai un lietotājiem redzamās kļūdas tiek fiksētas kā dokumentācijas atjauninājumi vai tieši iekodētas rīkos. Kad dokumentācija ir nepietiekama, mēs šo noteikumu ieviešam kodā.

Palielinoties Codex caurlaidspējai, daudzas tradicionālās inženierijas normas kļuva neefektīvas.

Repozitorijs darbojas ar minimāli bloķējošiem sapludināšanas vārtiem. Pull request ir īslaicīgi. Testa nestabilitātes bieži tiek risinātas ar atkārtotām palaišanām, nevis bezgalīgi bloķējot progresu. Sistēmā, kur aģenta caurlaidspēja ievērojami pārsniedz cilvēka uzmanību, labojumi ir lēti, bet gaidīšana ir dārga.

Tas būtu bezatbildīgi vidē ar zemu caurlaidspēju. Šeit bieži vien ir pareizā izvēle.

Kad mēs sakām, ka koda bāzi ģenerē Codex aģenti, mēs domājam visu, kas ir koda bāzē.

Aģenti veido šādus elementus:

• Produkta kods un testi
• CI konfigurācija un izlaišanas rīki
• Iekšējie izstrādātāju rīki
• Dokumentācijas un dizaina vēsture
• Novērtēšanas ietvari
• Pārskatīšanas komentāri un atbildes
• Skripti, kas pārvalda pašu repozitoriju
• Ražošanas informācijas paneļa definīciju faili

Cilvēki vienmēr paliek iesaistīti, bet strādā citā abstrakcijas līmenī nekā agrāk. Mēs nosakām darba prioritātes, pārvēršam lietotāju atsauksmes pieņemšanas kritērijos un pārbaudām rezultātus. Kad aģentam ir grūtības, mēs to uztveram kā signālu: identificējam, kas trūkst — rīki, aizsargmehānismi, dokumentācija — un ievadām to atpakaļ repozitorijā, vienmēr ļaujot pašam Codex uzrakstīt labojumu.

Aģenti tieši izmanto mūsu standarta izstrādes rīkus. Viņi apkopo pārskatīšanas atsauksmes, atbild tiešsaistē, ievieto atjauninājumus un bieži saplacina un sapludina savus pull request.

Tā kā arvien lielāka izstrādes cikla daļa tika iekodēta tieši sistēmā—testēšana, validācija, pārskatīšana, atgriezeniskās saites apstrāde un atkopšana—repozitorijs nesen sasniedza nozīmīgu slieksni, kur Codex var no sākuma līdz galam vadīt jaunu funkciju.

Ņemot vērā vienu uzvedni, aģents tagad var:

• Pārbaudīt pašreizējo koda bāzes stāvokli
• Atkārtot ziņoto kļūdu
• Ierakstīt video, kas parāda kļūmi
• Ieviest labojumu
• Pārbaudīt labojumu, darbinot lietotni
• Ierakstīt otro video, kas demonstrē risinājumu
• Atvērt pull request.
• Atbildēt uz aģenta un cilvēku atsauksmēm
• Atklāt un novērst būvniecības kļūmes
• Nodod cilvēkam tikai tad, kad nepieciešama spriestspēja
• Sapludināt izmaiņu

Šī uzvedība lielā mērā ir atkarīga no šī repozitorija konkrētās struktūras un rīkiem, un to nevajadzētu uzskatīt par vispārināmu bez līdzīgiem ieguldījumiem—vismaz pagaidām ne.

Pilnīga aģentu autonomija arī rada jaunas problēmas. Codex atkārto modeļus, kas jau pastāv repozitorijā — pat nevienmērīgus vai neoptimālus. Laika gaitā tas neizbēgami noved pie novirzēm.

Sākumā cilvēki šo problēmu risināja manuāli. Mūsu komanda agrāk katru piektdienu (20 % no nedēļas) pavadīja, sakopjot “MI drazu”. Kā jau bija gaidāms, tas nebija piemērots mērogošanai.

Tā vietā mēs sākām tieši repozitorijā iekodēt to, ko saucam par “zelta principiem”, un izveidojām regulāru sakopšanas procesu. Šie principi ir strikti, mehāniski noteikumi, kas nodrošina koda bāzes salasāmību un konsekvenci turpmākajām aģenta palaišanas reizēm. Piemēram: (1) mēs dodam priekšroku koplietojamām utilītpakotnēm, nevis individuāli veidotiem palīgrīkiem, lai invarianti būtu centralizēti, un (2) mēs nepārbaudām datus “YOLO stilā” – mēs validējam robežas vai paļaujamies uz tipizētiem SDK, lai aģents nevarētu nejauši balstīties uz uzminētām struktūrām. Regulāri tiek veikti fona Codex uzdevumi, kas meklē novirzes, atjaunina kvalitātes pakāpes un atver mērķtiecīgus pārfaktorēšanas pull request pieprasījumus. Lielāko daļu no tiem var pārskatīt mazāk nekā minūtes laikā un automātiski sapludināt.

Tas darbojas kā atkritumu savākšanas mehānisms. Tehniskais parāds ir kā aizdevums ar augstiem procentiem: gandrīz vienmēr ir labāk to nepārtraukti samazināt ar nelieliem maksājumiem, nekā ļaut tam uzkrāties un risināt to sāpīgos uzrāvienos. Cilvēka gaume tiek uztverta vienreiz un pēc tam nepārtraukti piemērota katrai koda rindiņai. Tas arī ļauj mums ik dienu pamanīt un novērst sliktus modeļus, nevis ļaut tiem izplatīties koda bāzē vairākas dienas vai nedēļas.

Šī stratēģija līdz šim ir labi darbojusies līdz iekšējai palaišanai un ieviešanai uzņēmumā OpenAI. Reāla produkta izstrāde reāliem lietotājiem palīdzēja nostiprināt mūsu ieguldījumus realitātē un virzīt mūs uz ilgtermiņa uzturēšanu.

Mēs vēl nezinām, kā arhitektoniskā saskaņotība attīstās gadu gaitā pilnībā aģentu radītā sistēmā. Mēs joprojām mācāmies, kur cilvēka spriestspēja sniedz vislielāko atdevi un kā šo spriestspēju kodēt, lai tā pieaugtu. Mēs arī nezinām, kā šī sistēma attīstīsies, jo modeļi laika gaitā kļūst arvien spējīgāki.

Ir kļuvis skaidrs: programmatūras izstrāde joprojām prasa disciplīnu, taču šī disciplīna vairāk izpaužas atbalsta struktūrās, nevis pašā kodā. Rīki, abstrakcijas un atgriezeniskās saites cilpas, kas nodrošina koda bāzes saskaņotību, kļūst arvien nozīmīgākas.

Mūsu sarežģītākie izaicinājumi tagad ir saistīti ar vides, atgriezeniskās saites cilpu un kontroles sistēmu izstrādi, kas palīdz aģentiem sasniegt mūsu mērķi: izstrādāt un uzturēt sarežģītu uzticamu programmatūru lielā mērogā.

Tā kā tādi aģenti kā Codex pārņem arvien lielāku daļu no programmatūras dzīves cikla, šie jautājumi kļūs vēl nozīmīgāki. Mēs ceram, ka dalīšanās ar dažām agrīnām atziņām palīdzēs tev saprast, kur ieguldīt savus pūliņus, lai tu vari vienkārši veidot.