Было бы эффективней, но у нас госкомпания и всякие закупки делаются так долго, что пока совершается закупка средства могут быть уже неактуальны, у нас согласовываются закупки аж на след год. Но это одна причина, самая горькая. Вторая, что не хочется что-то навязывать, не смотря на бюрократию в финансовых вопросах, мы стараемся быть свободными в командах. Ну и я сам пользуюсь Cursor + Codex, для каких-то задач эффективен один инструмент, для каких-то другой, а скиллы переносимы, там разницы только в какие папочки ставить. И через мини утилиту, это делается в несколько кликов. С другой стороны есть rules, там уже не все так радужно.
Это тяжелый вопрос… Первая причина: компания к сожалению не оплачивает курсор всем, и настаивать на том, чтобы все за свои деньги покупали именно курсор по меньшей мере странно. Вторая причина: инструментов много, они конкурируют между собой и постоянно выходят очередные киллер фичи, как сообщество разработчиков мы не хотим застрять в одном решении, мы постоянно обсуждаем и сравниваем.
Да, это ровно причина, почему я не хочу строить процесс на одном “священном промпте”. Поэтому мне ближе схема, где всё детерминированное уезжает в скрипты, проверки и явные stop conditions, а LLM остаётся не источником истины, а интерфейсом к процессу: собрать контекст, объяснить блокер, предложить следующий шаг, помочь на развилке. Мне кажется, зрелость LLM-инструментов как раз будет не в том, что модель станет магически безошибочной, а в том, что вокруг неё появится больше инженерных ограничителей.
Так я как раз за деглорификацию LLM :) Если задачу можно прибить скриптом - пусть её прибивает скрипт. LLM остаётся для контекста, решений на развилках и объяснения, почему всё опять упёрлось в старый puppeteer.
Потому что сами практики часто не завязаны на один инструмент. Сегодня команда использует Cursor, завтра часть людей работает в Codex или Claude Code. Если skill описывает процесс, хочется переиспользовать его, а не писать под каждую IDE заново.
У меня похожая идея работает. Но с cursor вместо obsidian и кодекс, иногда запускаю обсидиан, для некоторых визуализаций. Давно использую, но репозиторий всегда отправляю на гитхаб. Свой комп хорошо, но он может сломаться и информация потеряться, это как голову потерять. Кодекс у меня тоже есть, его использую на том же проекте для некоторых специфичных задач по работе с текстом. Проблема кодекса, что он работает очень медленно, проблема курсора, что токены расходуются быстро, поэтому балансирую. Сейчас у меня codex подписка за 20 и курсор за 200, и да кодекс неисчерпаем, а 200 заканчиваются постоянно.
Спасибо за кейс. Вы пишете про риск потери промежуточных состояний при падении и что события обрабатываете раз в час. Как у вас устроены гарантии корректности end-to-end: какие семантики (exactly-once/at-least-once) реально получаются, как делаете дедупликацию/идемпотентность на стыке Flink → Iceberg/Trino → dbt (delete+insert), и как восстанавливаетесь после простоя (чекпоинты/offsets/повторный прогон) так, чтобы не «потерять» статусы?
Я не очень знаком с инфраструктурой Google Cloud, был один пет проект давно и немного забыл все, за 30 минут не поднял бы точно, а сервера на амнезии у меня давно используются для других нужд, поэтому мне было просто по клику получить новые креды и подключиться. Если бы я мог использовать гугл клауд, мне бы и не надо было стучаться из яндекс клауда, но там все по другому, вплоть до бд (firebase vs ydb). Если гипотеза выстрелит, то можно будет подумать над более целевым решением, может и без gemini, альтернативы есть.
хорошо бы, оформить приложение как сервис. было бы полезно. особенно, если вести общую базу сложности книг. можно было бы монетизировать на партнерке с kindle и audible
Я тоже подобную статью написал и тоже всю зиму грел дом. Окупается, но бассейн и прочая фигня не нужны. На кондиционере большие потери, почему просто вентиляторами теплый воздух не перегонять?
это басня и иногда имеет смысл. но есть и другие примеры: например, Ломоносов, Эйнштейн. бекендеры не рождаются бекендерами, это не передается по наследству, а учиться никогда не рано. Но главное, если разработчик надел на себя колпак фронтендера или бекендера и больше ничего слышать не желает, то это не разработчик, а переводчик с человеческого языка на компьютерный. Серьезный разработчик все равно так или иначе разбирается в смежных областях и разбирается в прикладных областях. Задачи в любой области бывают разной сложности, а с точки зрения бизнеса важно чтобы задачи решались как можно быстрее и как можно быстрее приносили деньги. и если в какой-то момент возникает перекос в задачах бекенд или фронтенд, если он кратковременный, то вопрос найма, а это тоже задача у которой есть цена или затраты обычно не стоит, а просто часть команды простаивает, а другая часть команды задерживает прибавление полезной ценности. Люди еще и болеют. И в такой момент фронтендер может решить пару простых задач с бекенда, чем поможет бизнесу, а еще его экспертиза будет расти по мере возникновения и решения таких задач и в пределе сравняется с эффективностью бекендера. Но в целом все зависит и от конкретных людей и от процессов в компании и в командах, наверное, там где применяется водопадная модель планирования мой подход будет иметь отрицательный эффект. А в мини продуктовых командах, где ценные фичи (которые приносят деньги) выпускаются по несколько в неделю это имеет смысл.
Было бы эффективней, но у нас госкомпания и всякие закупки делаются так долго, что пока совершается закупка средства могут быть уже неактуальны, у нас согласовываются закупки аж на след год. Но это одна причина, самая горькая. Вторая, что не хочется что-то навязывать, не смотря на бюрократию в финансовых вопросах, мы стараемся быть свободными в командах. Ну и я сам пользуюсь Cursor + Codex, для каких-то задач эффективен один инструмент, для каких-то другой, а скиллы переносимы, там разницы только в какие папочки ставить. И через мини утилиту, это делается в несколько кликов. С другой стороны есть rules, там уже не все так радужно.
Это тяжелый вопрос… Первая причина: компания к сожалению не оплачивает курсор всем, и настаивать на том, чтобы все за свои деньги покупали именно курсор по меньшей мере странно. Вторая причина: инструментов много, они конкурируют между собой и постоянно выходят очередные киллер фичи, как сообщество разработчиков мы не хотим застрять в одном решении, мы постоянно обсуждаем и сравниваем.
Да, это ровно причина, почему я не хочу строить процесс на одном “священном промпте”. Поэтому мне ближе схема, где всё детерминированное уезжает в скрипты, проверки и явные stop conditions, а LLM остаётся не источником истины, а интерфейсом к процессу: собрать контекст, объяснить блокер, предложить следующий шаг, помочь на развилке. Мне кажется, зрелость LLM-инструментов как раз будет не в том, что модель станет магически безошибочной, а в том, что вокруг неё появится больше инженерных ограничителей.
Так я как раз за деглорификацию LLM :) Если задачу можно прибить скриптом - пусть её прибивает скрипт. LLM остаётся для контекста, решений на развилках и объяснения, почему всё опять упёрлось в старый puppeteer.
Потому что сами практики часто не завязаны на один инструмент. Сегодня команда использует Cursor, завтра часть людей работает в Codex или Claude Code. Если skill описывает процесс, хочется переиспользовать его, а не писать под каждую IDE заново.
У меня похожая идея работает. Но с cursor вместо obsidian и кодекс, иногда запускаю обсидиан, для некоторых визуализаций. Давно использую, но репозиторий всегда отправляю на гитхаб. Свой комп хорошо, но он может сломаться и информация потеряться, это как голову потерять. Кодекс у меня тоже есть, его использую на том же проекте для некоторых специфичных задач по работе с текстом. Проблема кодекса, что он работает очень медленно, проблема курсора, что токены расходуются быстро, поэтому балансирую. Сейчас у меня codex подписка за 20 и курсор за 200, и да кодекс неисчерпаем, а 200 заканчиваются постоянно.
Спасибо за кейс. Вы пишете про риск потери промежуточных состояний при падении и что события обрабатываете раз в час. Как у вас устроены гарантии корректности end-to-end: какие семантики (exactly-once/at-least-once) реально получаются, как делаете дедупликацию/идемпотентность на стыке Flink → Iceberg/Trino → dbt (delete+insert), и как восстанавливаетесь после простоя (чекпоинты/offsets/повторный прогон) так, чтобы не «потерять» статусы?
Пока никаких вариантов не рассматривал, для теста гипотезы это не нужно. По результатам теста буду смотреть все варианты.
Я не очень знаком с инфраструктурой Google Cloud, был один пет проект давно и немного забыл все, за 30 минут не поднял бы точно, а сервера на амнезии у меня давно используются для других нужд, поэтому мне было просто по клику получить новые креды и подключиться. Если бы я мог использовать гугл клауд, мне бы и не надо было стучаться из яндекс клауда, но там все по другому, вплоть до бд (firebase vs ydb). Если гипотеза выстрелит, то можно будет подумать над более целевым решением, может и без gemini, альтернативы есть.
Сервис не упадет, а у функции выскочит исключение, которое сервис должен обработать.
Согласен, что стратегически это не годится, как продакшн решение, но чтобы по быстрому протестировать гипотезу, вполне.
Это же серверный код, вряд ли МТС как-то влияет на сервера яндекс, не через мобильную же дата центр подключен.
Да, умеет
а зарплата-то изменилась? в начале была затравка про 30тыс, но к концу эта тема так и не раскрылась.
браузер не запоминает, но JS с этим спраляется
хорошо бы, оформить приложение как сервис. было бы полезно. особенно, если вести общую базу сложности книг. можно было бы монетизировать на партнерке с kindle и audible
Я тоже подобную статью написал и тоже всю зиму грел дом. Окупается, но бассейн и прочая фигня не нужны. На кондиционере большие потери, почему просто вентиляторами теплый воздух не перегонять?
можно выключать, но это вручную, или от внешней погоды автоматику настроить.
я купил за 15тыс.
это басня и иногда имеет смысл. но есть и другие примеры: например, Ломоносов, Эйнштейн. бекендеры не рождаются бекендерами, это не передается по наследству, а учиться никогда не рано.
Но главное, если разработчик надел на себя колпак фронтендера или бекендера и больше ничего слышать не желает, то это не разработчик, а переводчик с человеческого языка на компьютерный. Серьезный разработчик все равно так или иначе разбирается в смежных областях и разбирается в прикладных областях. Задачи в любой области бывают разной сложности, а с точки зрения бизнеса важно чтобы задачи решались как можно быстрее и как можно быстрее приносили деньги. и если в какой-то момент возникает перекос в задачах бекенд или фронтенд, если он кратковременный, то вопрос найма, а это тоже задача у которой есть цена или затраты обычно не стоит, а просто часть команды простаивает, а другая часть команды задерживает прибавление полезной ценности. Люди еще и болеют. И в такой момент фронтендер может решить пару простых задач с бекенда, чем поможет бизнесу, а еще его экспертиза будет расти по мере возникновения и решения таких задач и в пределе сравняется с эффективностью бекендера. Но в целом все зависит и от конкретных людей и от процессов в компании и в командах, наверное, там где применяется водопадная модель планирования мой подход будет иметь отрицательный эффект. А в мини продуктовых командах, где ценные фичи (которые приносят деньги) выпускаются по несколько в неделю это имеет смысл.
А какие этот может иметь негативные последствия? У вас был опыт?