tgindex

S0ER

описание

Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev

← к каналу@softwareengineervlog
10 447
подписчиков
Охват к подписчикам
56,5%
ERR
Реакции к просмотрам
0,92%
1 027 на 19 постов
Пересылки к просмотрам
1,05%
1 173
Постов в день
0,0
всего 20

Где отзываются чаще

доля реакций к просмотрам
  • 6 авг.Полезное: разраб сделал интерактивный мануал, который по шагам показывает, что происходит после нажатия Enter в адресной строке браузера. Внутри прям весь путь запроса: от интерпретации ввода и DNS до TLS, HTTP и рендеринга страницы. Всего 16 этапов и 124 подшага с анимациями и объяснениями. И да — всё на русском. Разбираемся 👌 @xor_journal3,18%
  • 5 авг.Ты ненастоящий программист! Это происходит снова и снова, и каждый раз одинаково. Я начал свою карьеру, когда уже были языки высокого уровня, но ООП еще только набирал обороты. Несмотря на то что новая парадигма быстор становилась мейнстримом и нужно было учиться новому, не утихали разговоры о том, что ООП никогда не заменит структурный подход, потому что «медленно», «сложно», «бессмысленно» и все «настоящие» программисты используют только структуры + ассемблер для оптимизации сложных участков, а все «ненастоящие» — этот ваш новомодный ООП. Потом похожая ситуация была с использованием фреймворков — «настоящие» программисты — это всегда про «хардкор», когда буквально из ничего можешь собрать работающую систему, при этом все, что облегчает твою работу, сразу переводит тебя в разряд нетрушных программистов. Потом фронтенд стал ненастоящим программированием, все по той же схеме — слишком легко, нет технической глубины и сложности. Правда, вопрос со сложностью со временем решили, современные фронтендеры должны хорошо знать браузерные оптимизации, внутреннюю работу V8 и много других «трушных» вещей. Теперь пришла пора ненастоящими программистами называть вайбкодеров и тех, кто использует ИИ в своей работе. Проблема в том, что софт постоянно становится сложнее, объемы растут, задачи сменяют друг друга все быстрее, и использовать старые методы никак не получится. Да, раньше было лучше, каждая строка кода была осмысленным актом искусства, а сейчас тонны типового кода, обернутые в библиотеки и фреймворки, — совсем не искусство, но обычная работа. Задача инженера — делать качественный софт, который решает запросы бизнеса, и можно долго спорить, насколько ИИ неидеален, насколько он может или не может закрыть все задачи разработки, но факт остается фактом — уметь использовать современные инструменты для создания программных систем — это обязанность каждого эксперта в своей области. Соглашусь с теми, кто говорит, что ИИ отчасти хайп. Маятник должен действительно сильно качнуться в сторону, прежде чем вернуться к состоянию равновесия. Сегодня ИИ пихают везде, где можно и нельзя, конференции забиты пустыми докладами, а бизнесу наперебой предлагают внедрение SDLC от самых опытных и умелых интеграторов ИИ. Часть этого хайпа спадет, пузырь лопнет, но ИИ не исчезнет из нашей жизни. Останутся задачи, которые быстрее решать, используя интеллектуальные инструменты, и это станет де-факто стандартом индустрии. Поэтому ничего не мешает подождать, когда все успокоится и индустрия финализирует стандарты использования ИИ, изучить только то, что надо, а не пытаться ловить весь хайп. Но есть нюанс, отложить на потом — накопить долг, поэтому базовые вещи, которые уже устоялись, лучше разбирать сейчас, чтобы в будущем не оказаться в ситуации, когда учить придется слишком много и "еще вчера".2,71%
  • 29 маяИИ база Ну что, дожили до того светлого будущего, когда все больше работодателей интересуются, умеет ли соискатель работать с ИИ. Сразу успокою, пока — это далеко ни каждый первый и даже ни каждый второй, поэтому есть время подготовиться и понять, что вообще могут спросить и как отвечать. Почему стали проверять знания ИИ? Тут все просто — строили, строили и наконец построили процессы, которые включают работу агентов как дополнительный инструмент для решения рабочих задач. Раньше джун мог выехать на одном языке и фреймворке, а теперь даже на старте ждут, что ты не просто пишешь код, а понимаешь, как подключить к этому делу LLM. Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии. Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу. Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь: Теория: - промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д. - контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д. - обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»); - архитектура агентов (включая команды агентов) Практика Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно: - построить структуру проекта c учетом spec-driven development, ADR и т.д.; - подобрать набор инструментов (в том числе MCP) и скиллов; - разбить задачу на этапы (планирование, проектирование, реализация, контроль); - решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен). И для общей статистики предлагаю поставить 💡 если в твоей компании уже просят использовать ИИ или на собесах задают вопросы по ИИ.2,12%
  • 25 июл.Закончилась эпоха Недавно Дядюшка Боб (автор книг "Чистый код", "Чистая архитектура" и т.д.) заявил, что вообще не читает код, который пишет LLM, вместо этого он использует ограничения в виде автоматизированных тестов и других проверок. Подобных заявлений с каждым днем становится все больше и количество будет только расти. Можно возразить, мол "а как же качество?". На самом деле за последние два года качество генерации сильно возросло, если грамотно гранулировать задачу, можно обойти многие ограничения ИИ (например, дублирование функций и классов, если их нет в контексте, и тому подобные вещи). Фокус ушел на AiSDLC и описание архитектуры проекта. Мне кажется, в моменте мы переживаем этап взросления разработки, когда от написания кода мы уходим к архитектуре и идеям. В этом смысле Роберт Мартин не изменяет своим принципам – он всегда топил за более высокоуровневый взгляд на программирование, и теперь ему стало делать это чуть проще. Но что будет с кодом? Мне кажется, что примерно то же, что произошло с ассемблером: как рабочий инструмент его мало кто использует, но интерес к пониманию того, как все работает, остался, многие смотрят видео по низкому уровню просто из любопытства, из-за того вайба, который дает погружение в инженерию. Поэтому код не исчезнет, просто заниматься им будут по желанию, из любопытства, а не потому что надо.1,76%
  • 9 июл.ИИ должен был помочь людям выполнять их работу лучше, а вместо этого приводит к усталости и выгоранию. Очень хорошо прочувствовал эту проблему на себе. Работаю с ИИ каждый день: формирую пул заданий, загоняю в оркестратор (это моя агентная система), через несколько часов проверяю сделанное, собираю список правок, снова запускаю агентную систему - и так по кругу. Проблема в том, что циклов исправления очень много. Причем это не моя личная проблема, появился даже новый термин - "ботситтинг" - это когда человек "нянчится" с LLM, чтобы получить результат. По статистике, на такие проверки и исправления у сотрудников уходит в среднем 6.4 часа в неделю, то есть почти целый рабочий день. Ситуация усугубляется тем, что сначала кажется, будто человек делает меньшую часть работы - просто правит результат ИИ, а потом ждет. Но на самом деле цикл довольно плотный, а сам момент "принятия решения" сильно выматывает психологически (делать рутинный код на порядок проще, чем быстро анализировать, находить проблемы, указывать, что нужно переделать). Если посмотреть на историю коммитов, кажется, что проект растет, но если смотреть на качество - значительная часть кода - это сплошные исправления. Причем я не могу назвать это "рефакторингом". Рефакторинг - это улучшение структуры без изменения функциональности. В моем случае каждое исправление - это изменение поведения, которое ИИ изначально реализовал неправильно. В итоге стал замечать, что устаю от принятия решений. Даже правильнее сказать от "скорости" принятия решений. Выматывает, что нельзя ни в чем быть уверенным, нужно все проверять и перепроверять, либо рискушь скатиться в "ботшитинг". Такое состояние называется "AI brain fry" - это когда нужно принимать бесконечные микро-решения, которые истощают когнитивные ресурсы. В результате падает КПД и возникает разрыв между тем, что я обсуждаю, и тем, что в итоге получаю. Пишут, что ИИ не только не сокращает объем задач, но и делает работу еще более интенсивной и сложной для человека. Можно возразить, что с людьми примерно так же - они ошибаются, переделывают и дорабатывают код. Но есть важнейший нюанс: люди делают это совсем в другом ритме. Машина же никогда не устает ошибаться. В итоге статистика удручающая: 48% разработчиков сообщают о ментальной усталости от работы с ИИ, 44% периодически чувствуют себя измотанными, а 19% уже вышли на уровень постоянного выгорания. При этом компании, уволившие сотрудников в надежде заменить их ИИ, вынуждены нанимать их обратно, так как модели не закрывают весь цикл разработки. Получается, я работаю не с кодом. Я работаю с системой, которая генерирует мне работу. И этой работы становится только больше. А вы говорите "ИИ скоро всех заменит". Сильно сомневаюсь.1,64%
  • 27 июл.Внимание, скам! Появился бот который выдает себя за бота моего канала. Я НИЧЕГО ЧЕРЕЗ БОТОВ НИКОМУ НЕ ПРОДАЮ. Жалуйтесь на скам если вам прелитит предложение на скидку от бота в телеге.0,97%
  • 15 июл.Отдельно хочу про "агентные циклы" (Loop Engineering) поговорить, этот термин ввел Андрей Карпаты в своих выступлениях. Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход. На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат. Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого. Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект. Поэтому я пошел другим путем: вместо того чтобы отказываться от циклов, я делаю их максимально короткими. Плюс ограничиваю количество итераций, а для вариативности решений запускаю несколько агентов с разными системными промптами параллельно, оркестрируя их через общий чат для сбора и сравнения результатов. Коммуникация в чате помогает понять не только "что" делают агенты, но и "почему" они это делают. Кроме чата каждый агент производит артефакты, которые далее могут использовать другими агентами. Если интересно, напишу отдельный пост про агентный харнес, который я использую. Понятно, что с позиции OpenAI, Anthropic и других разработчиков LLM методы, которые способствуют большему потреблению токенов, имеют большую привлекательность - в конце концов, их бизнес-модель строится на продаже токенов. Но для небольших исследований и малого бизнеса подходы с дроблением задач и короткими циклами - куда более эффективный метод, позволяющий сохранить качество кода, не сжигая бюджет и не допуская дрейфа агентов. Мне кажется, что сейчас ключевой навык инженера - не просто умение писать промпты, а способность декомпозировать задачу и настраивать агентную оркестрацию с короткими циклами так, чтобы каждый шаг давал предсказуемый результат. Это и есть та инженерия, которая нужна бизнесу. Но это на словах, на практике доверять агентам пока рано и методы разработки постоянно меняются, в поисках оптимальных решений.0,92%
  • 23 июл.Как же больно использовать API вызовы для Fable 5. Это стата из OpenCode Zen, у меня для ревью спеки используется Fable, а для написании спеки в части программных интерфейсов Kimi 2.7, на то чтобы Fable дал несколько замечаний улетает 4-5$ (по сути это один промпт). Другими словами - хочешь задать вопрос Fable плати 5$. Был бы я ИИ, зарабатывал бы на ответах в чате.0,92%
  • 20 июн.Два варианта. Один выбор. Допустим, у нас есть задача реализовать user story: Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены. Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так: async startLesson(userId: string, lessonId: string) { const user = await this.userRepository.findById(userId) const lesson = await this.lessonRepository.findById(lessonId) const subscription = await this.subscriptionRepository.findActiveByUser(userId) if (!subscription || subscription.expiresAt < new Date()) { throw new Error("No active subscription") } if (user.tokens < lesson.tokensCost) { throw new Error("Not enough tokens") } await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost }) await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() }) await this.analyticsService.track("lesson_started", { userId, lessonId }) } Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять: - Проверка подписки здесь, хотя должна быть в отдельном слое доступа. - Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос. - Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался. - Аналитика блокирует основной поток. - Нет уникального индекса на прогресс. Учитывая эти моменты, можно сделать более надёжную реализацию: async startLesson(userId: string, lessonId: string) { return this.unitOfWork.execute(async (uow) => { const user = await uow.users.findById(userId) const lesson = await uow.lessons.findById(lessonId) if (!user || !lesson) { throw new Error("User or lesson not found") } const accessResult = await this.accessService.checkAccess(user, lesson) if (!accessResult.allowed) { throw new Error(accessResult.reason) } const updateResult = await uow.users.updateOne( { _id: userId, tokens: { $gte: lesson.tokensCost } }, { $inc: { tokens: -lesson.tokensCost } } ) if (updateResult.modifiedCount === 0) { throw new Error("Not enough tokens") } return await uow.progress.create({ userId, lessonId, status: "started", startedAt: new Date() }) }) } Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности. Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work. Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс. Получается два разных варианта, оба рабочие. Но какой из них подойдет в конкретной ситуации - это решение, которое должен принять разработчик. Реальное программирование - это всегда компромисс между надёжностью, универсальностью и простотой. Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять новые проблемы и переписывать... Опять.0,90%
  • 10 апр.Последнее видео по промпт-инженерии далось с особой болью, раньше я бездумно использовал советы из интернета, которые определяли, что нормальный промпт - это когда ты задаешь роль, контекст, задачу, пример (строго в таком порядке) и добавляешь конкретные измеряемые критерии качества. Я использовал и мне казалось, что "Вау! Это работает". А потом я решил сделать ролик в котором показать "плохие" и "хорошие" промпты. Оказалось, что "плохие" промпты работают ничуть не хуже чем "хорошие", т.е. все это время я делал промпты не понимая, что делаю "шляпу". В итоге я собрал те моменты, которые реально дают изменения, перестал писать портянки текста, больше фокуса на примеры и техники размышления и вот здесь уже удалось показать разницу. А знаменитое "представь что ты программист" оказалась не такой полезной штукой, как я думал.0,87%
  • 25 июл.У Сбера есть интересный whitepaper где он описывает технологию разработки продукта с помощью агентных циклов. Можно сколько угодно не любить корпоратов, но игнорировать тренд, который формируется у нас на глазах - это просто глупо. Хотим мы этого или нет, но основой работы для инженеров - становится архитектура агентных циклов, умение выстраивать процессы, делать оценку качества, вносить и контролировать метрики качества. Это работает потому что бизнесу интересно выпускать фичи в 2-3 раза быстрее, даже за счет дополнительных издержек на производство этих фич. Некоторое время еще можно подождать, чтобы убедиться, что тренд устойчив, но, ИМХО, цикл ранних последователей уже скоро закончится.0,73%
  • 21 июл.Для того чтобы погонять Fable 5, пришлось вернуть подписку на Клода. В целом чувствуется, что модель сильнее Opus 4.8 (это проявляется в мелких деталях, подробнее писал в ИИ-лаборатории нашего клуба), но глобально ничего не меняется. Но вот что меня поразило, так это мои ощущения от использования Claude Code: как же я отвык от human in the loop, сидеть и постоянно контролировать - это не мое. У меня сейчас для работы сделано два оркестратора. Один реализует проектный SDLC, второй - общего назначения. Они связаны друг с другом и могут обмениваться заданиями и статусом выполнения, в общем агенте есть общий чат куда прилетают отчеты о выполнении. Развиваю проекты инкрементами, которые выглядят примерно так: $soerdev add spec "Новая фича" $soerdev refine spec $soerdev plan $soerdev run Это реализация цикла Human ON the loop. Логика такая: добавляем драфт спеки, обсуждаем детали, фиксируем план, запускаем цикл до выполнения критериев останова. В работу не вмешиваюсь, но вижу в чате и телеграм боте что происходит. И знаете что? Это реально удобно! Теоретически что-то подобное можно настроить и в CLI-агентах, но все равно придется допиливать харнес для отправки сообщений в телеграм, делать свой аналог гейтов, делать скилы и промпты. А так все зашито в оркестратор soerdev.0,55%