Те що не зважаючи на потенційну і реальну велич міста воно справляє враження оркестру де в кожного окремі ноти, а дерижер не знає що грати і переодично просто ставить якись музон з телефона. Хочеться щоб приїзд до столиці був заворожуючим, а не як було що наче десь у Новій Каховці зійшов посеред нічого і то там чистіше було чи весь той треш який знаходився в межах кілометру від Хрещатика і всіх тих держ установ. Навіть не треба ту велич робити вона в місті є і так, але прибрати всю срань та не перенавантажувати інфраструктуру бездумною забудовою і вже буде круто.

Мало що таке ж нудне в житті як код ревью того що згерив аі, десь на рівні споглядання дефрагментації диску чи як сохне фарба.

LOL, тут ШИ выигрывает, неудивительно — у манки кодеров то.

Я не мав на увазі порівнювати манкі кодеров з ШІ. Просто який проект не візьми там завжди є частина яка нудна і тупа. От її добре скидувати на ШІ.

Title inflation

Ну це або планочку задрали, або вимоги раніше були низьки.

Дело не в Ши — от него больше проблем чем толку на данный момент.

Чому це? Як на мене всілякий манкі кодінг робить добре знаю не мало людей хто взагалі каже що майже не кодить ручками тільки підправляє.

Объективно причины на текущий момент
— экономика и спад доходов
— раздутые зарплаты девелоперов
— раздутые команды после ковида
— средний уровень синьора подупал

Що головна причина це економіка, а ніякий не ШІ це цілком згоден коли в ковідні роки заливали баблом то розмітали всіх на ринку. Про середній рівень не дуже зрозуміло.

Дуже важко було знайти в тексті як саме некомпетентність прикривалася АІшкою навіть довелося двічи пройтись по тексту і попросити геміні написати самарі з запитом знайти саме такі частини які про саме проблеми від зловживання АІ. Тобто текст і заголовок трохи окремі один від одного.

Але замість точкового фіксу людина з допомогою LLM дійшла до радикального рішення

Згадуються слова «Spirit of this machine, heed my will»

Оце талант розписати красиво фразу «ми почали більше доїти і меньше годувати». =)

Змінили методологію: Scrum → Kanban

Суть: відмовилися від двотижневих спринтів на користь безперервного потоку задач.

Але ж в канбані по суті нема фіксованих проміжків часу на який фіксується скоуп робіт. Це якийсь срамбан.

Результат: де ми опинилися

Цікава табличка, але коли бачиш покращення в х54 тут винакає прям ДУЖЕ багато питаннь. Так і по інших метриках кратне збільшення теж неоднозначне. Знаю певні способи як такого домогтися в метриках в той час як реальна розробка буде приблизно на тому самому рівні по швидкості. Приміром не запихуємо задачі на 10+ сторіпоінтів, а б’ємо на до 5, переносимо як умога швидше, а коли скажімо велика задача мала 10 пунктів дефінішен оф дан, а маленькі по 3 максимум то чисто статистично кількість реопенів буде меньша. Так само і інші метрики.
Пс
не сприймайте за критику тут насправді не мало ідей як переконувати людей які не хочуть кудись вникати що їдемо вірною дорогою. З цього боку це дуже цікавий текст.

Агентський пошук каже: дай агенту прості примітиви для пошуку/читання і він сам розбереться.

Якщо взяти як ті агенти робляться на опенаі апі то доволі легко впертися у стелю кількості токенів на запити чи кількість запитів на хвилину. Більше того він ще і на лету пише скрипти які парсять ті файли (скажімo xlsx) що теж віджирає певну кількість токенів. Так чи інакше у вас завжди контекст і модель то лише питання форматів як то все надавати.

більшість майбутніх систем будуватиметься навколо AI

Ви б поставили на це гроші? Бо я вже не раз і не два стикався з випадками коли той аі тулять де треба і не треба. Воно ще якось працює поки відносно дешево і лоад невеликий, але коли треба або багато запитів за хвилину чи якщо віднімуть розцінки (що як мені видається неминуче) то всі такі системи можуть постати перед ситуацією вибору «здохни або помри». Щось точно вистрилить і виживе та чи буде це більшість не певен.

В смысле платят половину реальной стоимости?

Що таке половина реальної вартості? Як ви таке рахуєте?

Я ж не говорю о выходе на фриланс. Тут ищут уже не клиента, а инвестора.

Інвестора у власне що саме?

А якщо і там непогано годують? Бо оце працювати на себе воно не завжди таке просте як дехто думає, знайти клієнта часто це окрема і доволі кропітка робота. Підозрюю саме тому така кількість вакансій lead generator

Це здається неминуча штука спочатку це робить хтось першим, а далі всі інші підхоплюють коли плюшки э, а негативу майже нема. В мене особисто нереально підгорає з того що всілякі сраті фітнесбраслети і годиники яким на мою думку не треба нічого окрім блютус лізуть в 100500 пермішенів ще і акаунт створити прив’язавши до номеру телефону.

Можливо, навіть створю сайт, який генеруватиме для мене промпт із порівняннями минулорічних моделей, про які вже встигли написати відгуки, з інформацією про дефекти, що з’являються з часом, перегрів і наявність bloatware.

Це доволі дохлий номер якщо тільки ви не збираєтесь на це витрачати більшість свого вільного часу бо один і той самий телефон (з точки зору назви моделі) на різні ринки може їти з різною начинкою в тому числі і по софту. Плюс зараз просто дофіга відгуків лівих.

Ваші приклади POST/GET/DELETE тут нерелевантні, бо мова йде про керування виконанням.

GET — повністю актуальний бо навіть в прикладі що я навів саме так вони це і роблять, ви без цього ніяк. Щоб керувати станом вам майже 100% треба буде знати в якому зараз стані задача
DELETE — чому ні якщо треба відмінити задачу
POST — можливо не треба якщо ми не створюємо саму задачу, але не рідко його використовують як для створення так і для апдейта просто в залежності чи надається ІД чи ні виконуються різні дії.

В даному випадку зміна стану — це фізично не просто оновлення поля, а цілий набір дій з «виконавцем» — чи то системний процес, джоба в k8s, чи ще щось.

Та в будь якому CRUD інтерфейсі частина яка U це завжди найбільший шматок коду. Хоча легко може бути і просто апдейтом десь в базі, а далі вже якийсь воркер підхопить зміни і або виконає або відправить запит на виконання. Те що далі може бути прорва роботи то інша тема, я лише про ту частину яка формує зовнішній інтерфейс.

З точки зору клієнта який є чи користувачем, що *натискає кнопку* «старт» або «пауза», чи автоматизацією, якій треба виконати *дію*, це не оновлення властивості, а конкретна дія — «почати виконання», «призупинити виконання», тощо.

Але ж в черзі у вас задачі будуть мати цілком конретні статуси щоб ваш код який їх виконує завжди знав на чому він зупинився і яка частина системи повинна далі з ним працювати.

Тобто в вас і у клієнта це дії, і на сервері — окремі функції під кожен перехід стану. Нащо між ними додавати штучну абстракцію через оновлення властивості? Що це дає практично?

Формально я не можу сказати чи один підхід кращий за інший, але якщо ми додаємо якісь дії в path частину url це певною мірою розходиться з тим до чого люди звикли. Приміром я завжди був противником додавати параметри пошуку в path бо воно хоча і працює, але варіантів імплементації так багато що кожен хто це буде потім підтримувати мусить вивчати з нуля реалізацію.

Інший аспект — наскільки очевидним буде такий АПІ для девелопера або для якого-небудь АІ агента. Коли читаєш окремі методи під типові дії — все видно відразу, а коли цілий набір доступних дій прихований під зміною властивостей — можуть виникати питання.

Вони у вас в будь якому випадку виникнуть при роботі з новим інтерфейсом

І ще одне — а що якщо нам знадобляться параметри у таких операцій — наприклад, причина зупинки чи паузи?

Та все що завгодно можна додати в body.

{
"status": "pause",
"desc": "reason" 
}

Ну десь в коді у вас буде if або по частині url або по атрибуту body ото і вся різниця за великим рахунком. Як вже казав вся складність так чи інакше буде лягати на state machine яка в ідеалі не має залежати від того в якому саме форматі прийшов запит. Чи це крон джоба, чи це виклик апі ендпоінта чи може евент в pub sub підході.

Так у вас так і так буде десь розгалуження логіки лише питання де саме. Так чи інакше доведеться реалізовувати state machine тут лише питання який інтерфейс взаімодії реалізувати.

Для мене значно очевиднішими були б такі ендпоінти

POST /api/v1/jobs/ + {body} return {job + id} (створюємо/додаємо задачу)
GET /api/v1/jobs/{id} return {job} (перевіряємо статус задачі)
PUT /api/v1/jobs/{id} + {body} return {job + id} (оновлюємо задачу можливо переведеням на паузу)
DELETE /api/v1/jobs/{id} return {job + id} (просто вертаємо об’єкт який видалили іноді це корисно чим просто вертати тільки хедер зі статусом)

Приблизно так і працює частина апі OpenAI припіром platform.openai.com/docs/api-reference/runs хоча і частина підходів зі статі теж має місце

ні, вже тошно від купи халтури зробленої на колінці за допомогою аі. Навіть коли вилазить якась реклама гри і ти розумієш що вони навіть трошечки не напружувались перевірити наскільки косячне це відео чи те що реклама і сама гра на різних планетах.

щось я пропустив цю тему з двушечкою. Про що це?

Ну от приміром давайте візьмемо щось супер типове — інтеграція з апі. Проте за умови що це не щось дуже популярне. Скажімо отаке doc.toasttab.com/...​devguide/apiOverview.html і дамо задачу написати інтеграцію по доках. Я по всякому пробував хрінь робить, не так щоб взагалі ніфіга не працювало, але до продакшен реді коду не дотягує.
Якщо ж описати прям супер точно по пунктах що треба зробити і в кілька ітерацій змін то ну я не знаю тоді в чому тоді плюха від АІ окрім кодогенерації (що не мало, але без того хто шарить що той код робить малокорисне) і те що він мені накидає трохи ідеї куди копати.

Що АІ скоро всіх замінить із нового.