Eволюция на ролята на инженера - От Vibe Coding към Agentic Engineering

nickyGV

New Member
принципно си много прав в случая , но да не забравяме , че и вайбкодинга хич не е лесна работа ако нямаш план и визия какво точно искаш. Повечето вайбкодери се провалят защото нямат визионерско мислене и като стигнат до някаква трудност да вземат важно решение се чудят какво да правят. Освен това правилата на ИИ се променят не с дни, а с часове. На всяка нова нишка ИИ ти дава различен вариант за код. ИИ е изключителен помощник , но никога не може да замени човешкия интелект. Доста често ми се случва да поправям ИИ като му напомням и откривам елементарни грешки които са от стратегическо значение в кодинга.
Ами към днешна дата ИИ успешно измества джуниър позициите, както и голяма част от мид такивата, най-вече тези, които са свързане с правене на таскове по задание - в смисъл, имаш разписана задача с дефинирано почти всичко в нея, от теб се иска да разпишеш кода - ИИ го прави в пъти по-бързо и по-добре. Затова и в момента на пазара се наблюдава едно разместнане на ролите - в момента се търсят главно синиър хора ориентирани към архитектура и визия за да задават правилния ритъм и на другия полюс са промпт ориентираните хора, които да вземат задачите на архитектите и да ги поднасят на ИИ по най-разбираемия за него начин, макар че и това вече умира, защото тествах в един проект да назнача агенти на всички нива: първо анализ на изискванията и дефиниране на архитектурата, тя се описва във файл във всички възможно аспекти и правила.

1777928257717.png


Създаваш един агент архитект, който се грижи да не се нарушават принципите заложени в архитектурния файл, един оркестратор, който е нещо като тийм лийд и дава задачите на разработчика. Разработчика работи в координация с контракт гарда за да сме сигурни, че няма да нарушаваме избраната структура, тъй като бекенда ще очаква от фърмуера точно определена такава. След имплементация на функционалност feature разработчика дава отчет на билд оркестратора за свършеното, билд оркестратора прави код ревю и ако има разминаване със изискванията връща да дооправяне. Когато билд оркестратора е доволен от свършеното предоставя на архитект гарда резюме на направените промени, сверява с файла с архитектурата дали някъде не бягаме от зададените критерии и ако всичко е ок казва - спазени са всички зададени правила и критерии и няма нарушения на избраната архитектура, можем да качваме. През целия този процес ти следиш тази комуникация между агентите и може своевременно да вмъкнеш някаква корекция. Така разпределени ролите и с делегиране на част от отговорностите всяка нишка има сравнително чист контекст и ясно дефинирана роля, която просто трябва да спазва. Разбира се, пак има някакви отклонения и проблеми, но са сравнително малко и честно казано ИИ съвсем успешно върши работата на малък екип на средно ниво. Но това разбира се е когато няма много тежка и оплетена бизнес логика, за която е необходимо огромен контекст за да се обхване на всички нива, тогава ИИ започва да се оплита, защото започва да скипва някои неща, които не смята за важни за да поддържа контекста си в някакви граници:)) Така че да - няма да измести човешкия интелект, но ще измести хората които просто пишат код по задание:) Разбира се това си е мое виждане на нещата, част от което е, че ерата на Скайнет наближава и в близките стотина години човекът вече може да не е на върха на хранителната верига:))

А, и пропуснах да отбележа и другата важна част от разработката, тестването. На същия принцип създаваш и един екип от qa които след завършване на разработката прави по зададен план всички възможни кейсове които мога да се получат, намират бъговете, сортират ги по критичност и поетапно ги затварят.


1777928856182.png


И вече накрая когато се качи за тестове нещата които излизат за дооправяне са доста малко. Схемата е малко скъпа на токени, но може да спести време и да предотврати навреме сериозни архитектурни грешки, които да доведат до проблеми в бъдеще.
 
Последно редактирано:
Ами към днешна дата ИИ успешно измества джуниър позициите, както и голяма част от мид такивата, най-вече тези, които са свързане с правене на таскове по задание - в смисъл, имаш разписана задача с дефинирано почти всичко в нея, от теб се иска да разпишеш кода - ИИ го прави в пъти по-бързо и по-добре.

ИИ няма детерминистичен аутпут. Със сегашната архитектура технически никога няма как да има.

Колкото и добре да разпишеш задачата никога няма да имаш консистентен отговор ако минеш 10,000 пъти през един и същ пайплайн. Ако ще 1,000,000 файла да му разпишеш под формата на markdown. ;)

Джуниъра може да се научи и да стане мид. После senior. С всяка изминала година аутпута му става по-детерминистичен.

С други думи казано: talent tends to gravitate over time (не ми идва на български).
 
@nickyGV

Този пост ми напомни на видео от Dan Martell от преди няколко седмици – 99% of People Have No Idea What’s About to Happen With AI...


Level 1 – AI Assistants - Повечето хора са тук. ChatGPT, Claude, Gemini помагат с отделни задачи, но ти вършиш основната работа.
Level 2 – AI Agent Operators - Даваш цел на AI и той сам планира, изпълнява, тества и ти връща готов проект. Ти си само oversight / project manager.
Level 3 – AI Organizations - Цяла виртуална компания от sub-agents, които работят заедно 24/7. Един планира, друг кодира, трети тества, четвърти прави review. Ти само задаваш визията.

Това, което разказваш, е чист Level 3 в действие. Сам си си построил цяла виртуална компания – архитект гард, който пази принципите, оркестратор като тийм лийд, девелопър с контракт гард, билд оркестратор за ревю и накрая QA екип, който вдига всички кейсове... Това вече не е просто AI помага с тасковете, а AI върши работата на цял малък екип на средно ниво...

И точно тук ми се иска да тествам нещо. MetaGPT и ChatDev са ранни и много чисти примери за Level 3 – симулират пълна софтуерна компания с агенти в роли (PM, Architect, Engineer, QA). Но аз искам да го пробвам с локални модели.... Вместо един cloud модел да ползвам няколко различни локални LLMs, fine-tuned на различни base модели и с различни специализации...

Единият да е по-силен в reasoning и планиране – да държи архитектурата и да пази правилата от архитектурния файл. Другият да е специализиран в код – да имплементира, дебъгва и да спазва контрактите. И двата да се състезават с различната си логика... единият предлага решение, другият го критикува или дава алтернатива, после се връщат пак... Резултатът трябва да е по-високо качество и по-малко халюцинации, защото няма един модел, който да мисли по един и същи начин. Плюс пълна поверителност – всичко локално...

Същото може да се направи и за QA частта – няколко QA агента с различни модели, които атакуват проблема от различни ъгли...

Това според мен е истинският agentic engineering на следващо ниво. Не един AI, а цял диверсифициран екип от локални агенти с различни личности и логики, които си сътрудничат и се предизвикват взаимно...

ПП Интересно ми дали някой от форума е тествал вече нещо такова с локални модели или все още сте на cloud?

И как се справяте с тежката и оплетена бизнес логика, където контекстът става прекалено голям?
 
Последно редактирано:
@nickyGV

Този пост ми напомни на видео от Dan Martell от преди няколко седмици – 99% of People Have No Idea What’s About to Happen With AI...


Such hype. Much nonsense. 🤷‍♂️

Level 1 – AI Assistants - Повечето хора са тук. ChatGPT, Claude, Gemini помагат с отделни задачи, но ти вършиш основната работа.
Level 2 – AI Agent Operators - Даваш цел на AI и той сам планира, изпълнява, тества и ти връща готов проект. Ти си само oversight / project manager.
Level 3 – AI Organizations - Цяла виртуална компания от sub-agents, които работят заедно 24/7. Един планира, друг кодира, трети тества, четвърти прави review. Ти само задаваш визията.

Това, което разказваш, е чист Level 3 в действие. Сам си си построил цяла виртуална компания – архитект гард, който пази принципите, оркестратор като тийм лийд, девелопър с контракт гард, билд оркестратор за ревю и накрая QA екип, който вдига всички кейсове... Това вече не е просто AI помага с тасковете, а AI върши работата на цял малък екип на средно ниво...

И точно тук ми се иска да тествам нещо. MetaGPT и ChatDev са ранни и много чисти примери за Level 3 – симулират пълна софтуерна компания с агенти в роли (PM, Architect, Engineer, QA). Но аз искам да го пробвам с локални модели.... Вместо един cloud модел да ползвам няколко различни локални LLMs, fine-tuned на различни base модели и с различни специализации...

Единият да е по-силен в reasoning и планиране – да държи архитектурата и да пази правилата от архитектурния файл. Другият да е специализиран в код – да имплементира, дебъгва и да спазва контрактите. И двата да се състезават с различната си логика... единият предлага решение, другият го критикува или дава алтернатива, после се връщат пак... Резултатът трябва да е по-високо качество и по-малко халюцинации, защото няма един модел, който да мисли по един и същи начин. Плюс пълна поверителност – всичко локално...

Същото може да се направи и за QA частта – няколко QA агента с различни модели, които атакуват проблема от различни ъгли...

Това според мен е истинският agentic engineering на следващо ниво. Не един AI, а цял диверсифициран екип от локални агенти с различни личности и логики, които си сътрудничат и се предизвикват взаимно...

Рийзънинга, оркестрацията и харнесите просто натискат с повече compute и се опитват да решат проблем, който е фундаментален.

Не са "ъпгрейд". Приеми го като отпимизация, но не е следващата архитектура, която да замени трансформърите.

Изчакай няколко години. Трябва да минем през world models и още 2-3 тъпотии преди всички да се усетят, че невронни мрежи с трансформъри не е достатъчно.

ПП Интересно ми дали някой от форума е тествал вече нещо такова с локални модели или все още сте на cloud?

От няколко седмици разцъквам с М5 Pro Max. Вървят повечето опен сорс модели, но нямат нищо общо с лидерите що се отнася перформънс.

Надявам да се докопам до десетина Mac Mini с М5, когато ги пуснат и да ги навържа заедно. Apple вече има Thunderbolt 5, който поддържа RDMA. На практика ги превръща в малък суперкомпютър отпреди 7-8г.

За предпочитане да не ги купувам аз, защото поне към днешна дата не успявам да използвам на 100% дори Claude план за $200 и започвам да мисля, че няма смисъл.

Също разгледай платформите, където можеш да тестваш много от опен сорс моделите на достъпни цени. Ако стигнеш определен бюджет за да оправдаеш local inference тогава инвестирай в хардуер.

Или ако имаш някакво изискване от институция данните да са локални. Компании като Cloudflare спазват бумащината на ЕС и имат сървъри тук. Предлагат и къстъм сделки. Доста модели имат https://developers.cloudflare.com/workers-ai/models/

И как се справяте с тежката и оплетена бизнес логика, където контекстът става прекалено голям?

Ако контекста ти е прекалено голям бъркаш някъде.

Не се заблуждавай, че моделите поддържат 1,000,000 токена контекст. При тежка сесия перформънса пада с 30-80% в зависимост какво правиш.

С процеса по-долу ми отнема по 20-30 минути на фичър и още 40-тина да минат всички линтери и тестове (които са 100% детерминистични).

Задачите трябва да са пръснати на възможно най-малки откъси. При започване на нова задача винаги с абсолютно чист контекст.

Разделил съм на микросървиси. В проекта за хостинга са 21 + инфраструктурата, която върви в к8с и още няколко serverless. Около 3,000,000 реда са. Ако е в монорепо и го накарам да изяде всичко ще се задави и ще започне да бълва глупости. ;)

Каквото е най-важно конкретно за сървиса, по който работя седи в README.md (както би работил и с хора). Нямам 500 файла за всяка тъпотия. Давам му достъп през MCP до UI-a с Playwright, OpenApi схемата, базата, един Django сървис, който отговаря за миграциите натам да се оправя.

Преди мърдж на PR има пайплайн под формата на github action, който прави review и ако е ок ми го изпраща за мърдж.

По принцип би трябвало да са разделени на още по-малки части, защото архитектурата използва евенти с pgevent и най-добре consumers/producers да са отделно ама не ми се занимава все още.

Това е от дев средата, където е просто Docker. За всеки има схема достъпна през MCP,

Screenshot 2026-05-09 at 16.34.37.pngScreenshot 2026-05-09 at 18.37.28.pngScreenshot 2026-05-09 at 18.21.44.png
 

Горе