2026 m. rugsėjo 2 d., trečiadienis
DI ir programavimas
Tiesiog naudoju DI, skaitau apie DI naudojimą programavime ir dalinuosi atradimais/pastebėjimais ir t.t.
-
Pi po truputį populiarėja ir yra turbūt vienas įdomesnių “agentų pakinktų” (agent harness), nes neateina iš DI korporacijų ir dėl to yra šiek tiek kitoks:
-
Atradau, kad Codex 5.6 luna dengia 90% mano poreikių, tai pagalvojau, kad lokalūs modeliai tikriausiai irgi veiks man. Pabandžiau leisti su pi+llama modelius lokaliai su integruota Intel vaizdo plokšte - 2-3 tokenai per sekundę. Ne kažką. Lauksime geresnio hardware’o. Kas tikrai smagu, kad išsibandyti lokalius modelius kaip niekada paprasta.
-
AI atrodo programuotojus priveda prie perdegimo: I’m done using AI, AI Coding is exhausting, Vetted AI code is hard to justify, AI Software Development – What Does The Data Say? (paskutinė nuoroda ne tiesiai veda apie tai, bet giliau galima rasti)
-
Viena iš to priežasčių, kad kodą vis tiek reikia suprasti, net jei DI padeda su kodo peržiūromis (Understanding is the new bottleneck, Triple agent code review, You can just choose how many bugs you want now. DI kodo prigeneruoja daug ir žmogus bandantis jį suprasti tampa butelio kakleliui procese. Ir tada kyla klausimai: o kiek kodo reikia suprasti, kaip AI gali padėti suprasti kodą ir t.t. Nes jei nesuprasi, tai tiesiog rizikuoji savo karjera (AI is removing the middle class of software engineering). Kad ir kaip dark AI factories atrodo patraukliai, bet net didžiausi proponentai atrodo sako, kad gal tai tiesiog dim factories ir vistiek žmogus kažkur lieka (Coding Agents Don’t Scale Themselves. Neither Do Your Teams, Human judgment doesn’t leave the software factory. It relocates.).
-
Ir atrodo, kad su DI galima dirbti dviem būdais, kurie baigiasi tuo pačiu: daug mažų PR’ų. Mano mėgstamas būdas skaldyti didelią užduotį su AI pagalba į mažas ir daryti jas po vieną (ir todėl padariau https://github.com/daliusd/taskey). Kitas variantas, duoti AI padaryti visą užduotį ir su AI pagalba suskaldyti į mažus peržiūrimus PR’us, kuriuos galima suprasti (Build Wide, Ship Narrow). Kuris būdas geresnis? Atsakymo dar neturiu - galbūt priklauso nuo užduoties tipo.
-
Pabaigai tiesiog smagu stebėti, kad net ir grandai susiduria su tais pačiais klausimas LIVE: Uncle Bob on Software Fundamentals in the Age of AI.