Идем к еще одной причине из-за которой агенты уходят от IDE в сторону терминала или отдельного ПО. Она делится на два основных пункта:

Рынок. IDE в основном используют либо айтишники, либо преисполнившиеся вайбкодеры. Это довольно узкий рынок, а хотелось бы чтобы агентами пользовались и бухгалтеры и финансисты и т.д короче все кому агенты бы помогли, но при этом без кода. Поэтому мы либо делаем терминал (по словам главы Антропика, у них финансовый отдел с кайфом использует Claude Code) либо делаем уже приложение которое будет иметь доступ к файловой системе и может дергать терминальные команды.

Вендоры Ide. Microsoft создала двухуровневую систему для защиты VsCode: Copilot получает доступ к internal API, сторонние инструменты - нет. При этом сама VsCode это open-source, но делать форк это прям заеба, Cursor отстает от последних версий VsCode. У последних по слухам есть целая команда которая занимается исключительно слиянием upstream-изменений. Другими словами у них весь бизнес строится на кодовой базе, контролируемой конкурентом.

JetBrains же напротив пытаются сейчас сделать внедрение плагинов более простым, чтобы не было необходимости делать форк целой Ide. Не говоря уже про то, что ты еще попробуй тут сделать форк, у гугла еле получается, потому как Android Studio работает заметно хуже оригинальной idea (лично по моему опыту, у вас возможно он другой).

Сюда же и относится в целом привычка. Я вот как только не пытался, я не смог работать с VsCode, по сравнению с idea у него отвратительный UX. Держать же целую отдельную ide только для агента можно, но вообще не удобно.

Подводя итог, почему мы вероятнее всего не увидим новых агентов именно как ide. Делать свою ide дорого и рискованно. Ты не затащишь обычных пользователей, которые рот топтали работу с кодом в текстовый редактор с AI.

Попался рилс, в котором была надпись вайб фронтендера, вайб бэкендера и вайб мобильщика. В первом же комментарии чувак написал, что фронтенд и мобилка это одно и тоже. Сами догадываетесь что под комментарием началась священная война.

Однозначно ответить на вопрос правда ли это одно и тоже нельзя. Вот что я имею ввиду – однозначно можно сказать что фронт и бэк отличаются. У первых задача сделать понятный и быстрый интерфейс, у вторых быстро обработать данные и не проебать их.

Когда же мы сравниваем мобилку и фронт оказывается что в 90% случаев это одно и тоже. Если вы считаете, что это прям супер разные миры, вы вероятно не изучали современный фронт. И там и там это всегда про отправить запрос на бэк, и нарисовать интерфейс (разумеется декларативный), возможно какая-то минимальная логика еще.

Если вы даже на подходы посмотрите, то все best practice которые в 20-х годах на мобилке были ноу-хау, на фронте уже лет 6 как были базой. В мобилке почти все строится на подходах фронта, только улучшенных.

Можете конечно возразить что на мобилке нам доступны вещи типа файловой системы. С одной стороны да, с другой не очень то доступны, и с каждым релизом OS становится все недоступнее. На iOS вообще изначально не сильно от фронта отличалось.

Остаются 10% где реально прям есть отличие. Это уже касается работы с процессами, системными API (типа работы с камерой, гироскопа, шагомера т.д) или той же файловой системы. Правда все это используется, ну в 5% всех приложений. Ну и разумеется разница в доставке, на мобилке это прям геморрой со сторами, на фронте же в cdn закинул и готово.

Концептуально мобилка и фронт это одно и тоже, и со временем становится все более похожей. Вы что думаете, может все таки это совсем разные миры?

Вчера я впервые уперся в лимит рабочего Claude Code. Попытался за 4 часа сделать то, что обычно делают неделю. Нейронки на самом деле приучают тебя к work-life balance. Уперся в лимит, все иди отдыхай.

Конечно можно и руками добить, но руками это придется делать часа 2, а после восстановления лимитов уйдет минут 20. Речь даже не сколько про нейронки, сколько про нашу культуру.

Когда ты заебанный в край с синяками под глазами, значит ты хорошо поработал – работник месяца. Тот факт что мышление уставшего человека сравнимо с мышлением бухого, никого разумеется не волнует. При этом если ты овертаймишь ты молодец, а если придешь на работу бухой это увольнение.

Свежим ты можешь за час сделать то, что уставший будешь делать часов 6. Нейронки в этом плане ничего не меняют, они просто позволяют это заметить.

Под прошлым постом многие жаловались (один человек) что я убрал реакцию клоунов, которые всем так нравились. Короче смотрите, я в благодарность играть не буду, соберете под прошлым постом 500 звезд и мы в расчете, я верну их обратно (но не на всегда разумеется)

Самая ироничная вещь в нашей жизни это то, что наш организм нас постоянно просит быстрый дофамин, а главная база устойчивого счастья это научится получать кайф от долгого дофамина.

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

Что общего у бэкенд, мобильной и фронтенд разрабоки? Отсуствие желания жить в трезвом мире подумаешь ты, но нет!

Во всех этих областях хороший разработчик всегда держит в голове, что контекст пойдет по направлению в /dev/null (ну или нахер в простонародье).

В мобильной разработке Activity или UIViewController может быть уничтожена в любой момент. На фронте или компонент умирает в зависимости от фреймворка либо вся страница выгружается браузером.

На бэке при этом еще веселее ведь там еще больше контекстов про которые нужно не забывать: уровень запроса, уровень инстанса. В большом проекте инстанс приложения скорее всего будет запущен в кубере, а значит что также в рандомный момент будет прибит и запущен снова. Там же рядом идут и приколы что заранее ты не знаешь в какой именно инстанс пойдет запрос.

Как мне кажется все это сыграло не последнюю роль в популярности функционального программирования. Все best practice которые мы используем исходят из одного, контекст в котором исполняется твой код умрет в любой момент.

Что такое Task Queue?

В мобильной разработке бывает такая задача что нужно сделать какую-то работу в фоне. При этом нельзя просто взять и сделать ее в отдельном потоке, т.к процесс приложения может быть неожиданно прибит, нужна гарантия выполнения.

Для этого в мобильных системах есть специальные механизмы WorkManager в Android или BGTaskScheduler в iOS. Концептуально одинаковая идея, прописываем логику, задаем условия когда нужно сделать и затем система запустит эту задачу. Ну или не запустит, мобильная разработка хуле.

Ровно такие же задачи появляются и в бэкенд части. Нужно сделать после запроса какую-то работу, ассинхронно, например письмо отправить. Во время запроса ты это делать не будешь, нужно обрабатывать ретраи, ошибки, таймауты – запрос долгий получится. При этом мы не можем просто взять и запустить это в отдельном Executor ведь инстанс приложения также может быть неожиданно прибит. Сюда еще и накладываются приколы, что мы не можем контролировать нагрузку и может сложится что все задачи будут только на одном инстансе.

В итоге нужно сделать аналог WorkManager но на бэке, задачу нужно не потерять и сделать так, чтобы нагрузка распределялась равномерно. Для решения такой задачи есть Task Queue.

Суть в том, что мы сначала сохраняем данные для выполнения задачи в базу. Этим мы уже контролируем что задачу мы не потеряем. Затем отправляем событие в какую-то очередь часто это redis, но также используют Rabbit MQ или kafka. Далее есть воркер который случает очередь и берет таски на выполнение. При этом инстанс который сгенерил задачи и который ее затем исполняет может быть один и тот же.

После того как воркер сделал задачу он удаляет ее из очереди и помечает в базе как выполненную. Если упал по дороге эту таску позже возьмет другой инстанс.

Нет ну ты посмотри на них, стараешься делать полезные посты, что-то придумываешь, в итоге один комментарий и две реакции. Стоит просто запостить простую подводку про обезьянку и дофамин, так сразу невероятный отклик. Вы же сами меня подталкиваете к тому, что я буду кринжевать на полную.

Так блэт, клоунов я опять забираю. Начинаем аукцион, я их разблокирую только когда наберется под этим постом 2.5к звезд. В прошлый раз цена оказалась слишком низкой, поэтому мы повышаем ставки.

Вы не задаетесь вопросом, вот кто в РКН работает? Фанатики? Люди которые не понимают что делают? Или это как в Сталинские времена когда или ты выбиваешь признания, или сам едешь в лагерь?

У меня просто есть гипотеза, что возможно в РКН работают только удаленщики из какого-нибудь Бангладеша. Потому как работать на структуру которая буквально делает твою жизнь хуже это какая-то шиза.

Вот представь к тебе приходят из Негерии, о которой ты за жизнь лишь пару раз слышал краем уха, и предлагают тебе x5 к твоей текущей зарплате. На проекте придется разрабатывать нейронку по фильтрации трафика. Тебе на эту страну абсолютно похеру, ты не знаешь ни где она территориально расположена, ни как она вообще произносится. При этом ты получаешь просто страшный прирост к качеству жизни. Согласишься или нет?

Ну или я пытаюсь искать логику там, где ее быть не может.

О, пост для прикрепления к заявлению о депортации - смело

Наблюдаю интересную метаморфозу спам ботов. Раньше это были шлюхоботы, которые были с аватаркой красивой девочки и зазывали тебя весело провести вечер. Сейчас же почти на каждый пост приходят эти "книголюбы", которых хлебом не корми дай поделится впечатлениями о прочитанном.

Вам как моей аудитории вероятно должно быть лестно. Ведь теперь они играют не на базовых потребностях, а на чем-то высоком. Но заебали они конечно знатно, наверное уже нужно какой-то фильтр настроить.

Что такое мониторинг?

У нас есть приложение и нужно как-то проверить, а оно вообще там живое нет? Желательно словить момент, когда оно не живое до того как это сделают пользователи. Народная мудрость: быстро поднятое не считается упавшим – тут работает прекрасно.

Если у нас один инстанс на бэке то никакой мониторинг не нужен, можно и по логам быстро понять, что что-то не так. Однако если у тебя сотни тысяч клиентов, а на бэке у тебя 10-ки разных сервисов по 5-6 инстансов каждый без грамотного мониторинга ты быстро дашь ебу.

Есть два основных типа мониторинга: pull и push.

Мобилки да и вообще весь фронтенд работает по типу push. Это когда мы агрегируем метрики локально и затем переодически отправляем их на бэк. Если же сети нет, ждем пока появится и отправляем позже.

Бэк почти всегда работает по типу pull. Это когда наше приложение также собирает метрики в памяти, затем какая-то сторонняя система сама дергает наш бэк и мы отдаем ей то, что насобирали.

Как это выглядит в коде. В мобилке и фронте чаще всего используют проприетарные SDK: типа Firebase Crashlytics, Apple MetricKit, Setry, Яндекс Метрика либо вообще пишут что-то свое. SDK в свою очередь отправляет метрику в какую-то TSDB (time series database).

На бэке почти всегда используется стандарт OpenTelemetry. Для любого языка есть SDK в котором ты объявляешь переменные (их три типа) и далее просто используешь их в коде. Затем ты делаешь какой-то endpoint типа "/metrics" в котором ты, используя тот же SDK, генеришь ответ в специальном формате. После уже какой-нибудь Prometheus дергает этот endpoint и уже сохраняет метрики в TSDB.

Далее мы уже идем в интерфейс который работает с TSDB и создаем какие-то алерты, строим графики, перегоняем данные в другие БД короче развлекаемся как хотим.

Итак, frostpunk 2.

Год назад делал прост про первый frostpunk. Первую часть я прям полюбил, проходил ее раз 5 наверное. Под конец прошлого года вторую часть наконец-то портировали на PS5 и я смог ее заценить. И честно говоря я был разочарован, она полностью потеряла ту атмосферу за которую я полюбил первую часть.

Вторая стала масштабнее, теперь ты не возводишь отдельные здания, а целые районы. Поселение теперь не одно, соответственно тебе приходится налаживать логистику между городами. Система политики усложнилась, теперь не ты принимаешь решение которое считаешь нужным, тебе это решение еще нужно продать парламенту, в котором есть разные фракции и кто-то будет за, кто-то против. Прикиньте при принятии закона кто-то может быть против, эх ну понавыдумывают же!

Геймплейно она стала разнообразнее, шире дерево технологий, больше типов зданий короче всего больше, но она потеряла ламповость. В первой части было маленькое поселение, где ты буквально мог на жителя тыкнуть и узнать что-то про него. Тебя не отпускало вот это ощущение, что вот этот городок это последнее убежище человечества и если вы не выживаете, не выживает никто. Вторая часть это потеряла, сложно словить это ощущение когда у тебя 3 города, и каждый уже чуть ли не мегаполис.

Это как знаете, устраиваешься в галеру, которая вот только только начала работать, где все говорят, что мы тут друганы, никого не обидим. И первое время там и правда круто и лампово. Через несколько лет компания разрастается и начинается какая-то дичь. Вот такая история и с frostpunk.

Короче я ее в итоге забросил, из-за ублюдской оптимизации. На 5-й плойке она под конец игры она стала страшно лагать, из-за количества зданий. При этом там не вау графика и видимо разработчики сильно торопились с портом.

Аааакция, я возвращаю реакцию клоунов на пару часов, попробуй успеть!

Кто отписывается после такого тот гей

Ну что, те кто хотел сделали каминг аут, поэтому давайте двигаться дальше.

Что такое RAG?

RAG (Retrieval Augmented Generation) – переводится букально как генерация с дополнением извлечением. Чего извлекается, дополняется и генерируется давайте раскидаем.

Самая дефолтная задача для RAG это сделать ИИ бота который например отвечает по документации вашего продукта. Базовая LLM очень хорошо умеет работать с текстом, выдавать суть генерить примеры и не огрызается. Однако есть проблема, LLM ничего не знает о нашем продукте. Есть два путя как решить эту проблему:

1. Дообучить модель
2. Взять вообще всю доку по нашему проекту и отправлять ее на каждый запрос

Как сказал бы солист группы Бредорс, шо то очень хорошо, шо это не то чтобы круто. В первом это просто прям дорого, во втором случае зависит от размеров доки, но даже если дока небольшая точность ответов скорее всего будет так себе. Поэтому на сцену выходит RAG.

Что если не отправлять нейронке не всю доку, а только релевантные страницы? И LLM будет отвечать точнее, и мы не потратим кучу токенов и деняк на дообучение. Как это сделать?

Берем нашу доку, режем на части, затем отправяем в embedder. Embedder – модель которая из текста нашей доки сделает числовые вектора, грубо говоря вектора смыслов. Далее эти вектора мы кладем в специальную векторную базу, которая умеет круто их индексировать.

Далее происходит следующее, мы получаем запрос от пользователя, преобразуем вопрос в вектора при помощи того же Embedder'а затем используя этот вектор запроса находим ближайшие вектора в нашей векторной базе. Так как речь идет именно о смысловых векторах, но вероятнее всего полученные вектора будут ближе к тому о чем спрашивает пользователь. Векторая база рядом с векторами также хранит и текст из которых этот вектор был получен, поэтому мы в итоге получаем части текста нашей доки – чанки.

Далее из текста запроса и чанков мы генерим промпт для LLM. При обновлении доки мы должны опять нарезать ее на части и отправить в Embedder, т.е проиндексировать короче. Таким образом убиваем двух зайцев и модель не нужно дообучать и токенов много не тратится.

Разумеется в теории все просто но на практике начинаются приколы: как подобрать Embedder, какую базу выбрать, какие параметры для базы подобрать, какую модель выбрать и еще куча всего. Также желательно иметь свой бенчмарк с запросами ответами чтобы от версии к версии проверять не ухудшилась ли выдача системы.

Все же слышали что AI сейчас очень сильно меняет профессию разработчика, сейчас покажу как это происходит.

Раньше:
– Фронтенд: идем в бэк, получаем json, рисуем списочки и красим кнопки
– Бэкенд: получаем запрос, идем в БД получаем данные, делаем json отдаем клиенту

Сейчас:
– Фронтенд: идем в бэк, получаем json, рисуем списочки и красим кнопки
– Бэкенд: получаем запрос, идем в LLM получаем json, отдаем его клиенту

Web1.0 Web2.0 Web3.0

В начале 2000-х интернет был в некотором смысле гораздо более децентрализованный. У многих был личный сайт/блог на какой-нибудь CMS или своем хостинге. Форумы были разбросаны по всему интернету, не было одной точки входа. Чтобы что-то найти, нужно было прям искать, эдакий аналог закрытого клуба. Если тебя не пригласили то ты скорее всего так и не узнаешь о существовании этого сайта/блога и т.д. Это был Web1.0.

Затем пришли соцсети, мессенджеры и крупные платформы. Все они централизовали интернет. Удобство всегда побеждает. Зачем тебе хостить свой блог и бороться с CMS, если ты можешь в две кнопки зарегаться в условном твитере и сразу получить большую аудиторию? Это Web2.0.

Ну и Web 3.0, который базируется на базе блокчейна. Никому не доверяем все пидорасы доверяем только коду и математике простых чисел. Web 3.0 должен был прийти на смену злым корпорациям! Но так и не стрельнул, по крайне мере пока. Потому как чаша весов на которой с одной стороны централизация, а с другой удобство никуда не делась. Насколько я знаю все еще нет платформы построенной на Web 3.0 и при этом, чтобы она была удобной для обычного пользователя, а не гика.

И вот я думаю, с этими лютыми блокировками вероятнее всего будет два исхода. Первый мы вернемся опять в Web1.0, я думаю у многих айтишных блогеров проскакивает мысль, что лучше уже сделать свой сайт или приложение, чем переходить в макс. Второй мы перейдем в Web 3.0, который по задумке можно заблокировать только если вообще уже все провода обрубить по стране. Этот вариант выглядит нереалистичным, с другой стороны сейчас даже бабушки научились с впн работать...