по правилам и инструкциям согласен, у меня тоже rules в проекте настроены и работают лучше промптов. в статью не вписал потому что это уже техническая мелочь, а статья больше про общие ощущения. но да, без них агент пишет много лишнего, это правда.
про документацию частично соглашусь, AI её достает нормально. но если я в стеке не разбираюсь, я не пойму что он что-то тонко напутал. поэтому и говорю что на знакомом стеке работает лучше.
а вот про безопасность не соглашусь. дело не в том что AI не знает, а в том что цена ошибки слишком высокая. я лучше потрачу время и напишу руками чем потом разбираться почему утекли ключи. это мой расчет, у вас может быть другой.
Шаблонную часть давно умеют инструменты, тут вы правы. Но они работают на уровне “сгенерируй мне CRUD по этой модели”. AI ушёл дальше: “сделай мне форму регистрации с валидацией телефона по российским правилам, с подтверждением через SMS, с проверкой что номер уникальный в БД, дизайн как у соседних форм в проекте”. Это уже не шаблон, это контекстная задача. Code generator такое не сделает, нужен разработчик. Или AI с агентским режимом.
Про “доделать руками” вы тоже правы. Я никогда не запускаю AI-код в продакшн не прочитав. Но скорость "AI сгенерил черновик я допилил" получается быстрее чем “я написал с нуля + сам же проверил”. Не всегда, но в большинстве случаев.
Про $200/мес. Согласен, это деньги. У меня окупается потому что объём задач большой, я соло-разработчик с несколькими продуктами. Если у вас один проект и времени хватает писать руками, экономика другая.
Финально: AI это не “хочу получить и сразу получаю”. Это “хочу получить, формулирую задачу, получаю черновик, дорабатываю”. Просто эта цепочка быстрее чем “хочу получить, пишу с нуля, проверяю”. Если у вас не получается быстрее — это не значит что AI бесполезен, это значит что ваши задачи другие, или промпты не отстроены, или стек неудобный для текущих моделей.
Trello это доска, ты сам её читаешь и сам делаешь выводы. Лира это не доска и не помощник, а директор. Она сама смотрит на происходящее в компании, сама принимает решения о приоритетах, сама пишет сотрудникам, сама напоминает обещания.
Гендир ставит цели. Дальше Лира работает с командой за него. Каждый день решает кому что важно сделать, кто буксует, что сказать кому в личке. Не “помощник” в смысле “помогаю человеку”, а “директор” в смысле “беру операционку на себя”.
Под капотом сейчас задачи, обещания, цели, граф знаний компании. В роадмапе подключение производственных данных, 1С, других источников, чтобы Лира видела не только что люди говорят в чате, но и что реально происходит в компании. Дальше она будет управлять не только людьми, но и процессами.
Это уже другая категория продукта чем Trello. И ниша другая.
Спасибо! Про electron-store вы правы, миграции у неё через migrations API делаются непрозрачно, особенно когда схема нетривиальная. Я как раз поэтому пока остался на своём readSessionFile/writeSessionFile пусть не атомарно, зато прозрачно. Возможно перейду на conf это младший брат electron-store от того же автора, без миграций вообще, и под мои задачи (один JSON со session-токеном) её более чем достаточно.
Винду пока не подписал это в очереди, но процесс получения EV-сертификата для российского юрлица в 2026 непростой, поэтому откладываю. Если у вас есть свежий опыт поделитесь, было бы полезно.
ConnectionService API действительно существует и именно для этого: интеграция с system dialer на Android. Никто не использует — потому что это адски сложно правильно реализовать. У ConnectionService очень много edge cases: разные OEM реализуют его по-разному (Samsung, Xiaomi, Huawei имеют свои quirks), нужно правильно обрабатывать lifecycle сервиса, нужны permissions которые пользователи часто отказываются давать (“Make and manage phone calls”). А ещё на Android нет аналога iOS VoIP push — на FCM data message нельзя гарантированно поднять foreground service за миллисекунды до показа звонка. Поэтому многие (включая меня в текущей версии ONEMIX) делают компромисс — обычные high-priority push с custom UI вместо нативной интеграции. Но согласен, что iOS-овская унифицированная лента звонков — это сильно лучше UX. У меня в roadmap есть пункт “разобраться с ConnectionService”, но руки пока не дошли. Если ты сам ковырял эту тему — интересно услышать что-то конкретное.
Справедливый вопрос. Полноценных дампов webrtc-internals с production я в статью не вставлял — это отдельный материал. Но из своих логов: timestamps от createOffer до первого ontrack у меня в среднем 700-1400мс на разных сетях. Цифры “8-12 секунд” в gather-then-send — это результат моих собственных тестов на старой реализации до перехода на trickle, на плохих мобильных сетях LTE с международным TURN. На хорошем Wi-Fi разница меньше — gather может занимать секунды 2-3. Если интересно — могу в отдельном посте/статье разобрать дампы webrtc-internals с трассировкой, это полезная тема.
по правилам и инструкциям согласен, у меня тоже rules в проекте настроены и работают лучше промптов. в статью не вписал потому что это уже техническая мелочь, а статья больше про общие ощущения. но да, без них агент пишет много лишнего, это правда.
про документацию частично соглашусь, AI её достает нормально. но если я в стеке не разбираюсь, я не пойму что он что-то тонко напутал. поэтому и говорю что на знакомом стеке работает лучше.
а вот про безопасность не соглашусь. дело не в том что AI не знает, а в том что цена ошибки слишком высокая. я лучше потрачу время и напишу руками чем потом разбираться почему утекли ключи. это мой расчет, у вас может быть другой.
Логично, статья как раз про то что 70% работы у меня с AI)
По делу пишете, со многим согласен.
Шаблонную часть давно умеют инструменты, тут вы правы. Но они работают на уровне “сгенерируй мне CRUD по этой модели”. AI ушёл дальше: “сделай мне форму регистрации с валидацией телефона по российским правилам, с подтверждением через SMS, с проверкой что номер уникальный в БД, дизайн как у соседних форм в проекте”. Это уже не шаблон, это контекстная задача. Code generator такое не сделает, нужен разработчик. Или AI с агентским режимом.
Про “доделать руками” вы тоже правы. Я никогда не запускаю AI-код в продакшн не прочитав. Но скорость "AI сгенерил черновик я допилил" получается быстрее чем “я написал с нуля + сам же проверил”. Не всегда, но в большинстве случаев.
Про $200/мес. Согласен, это деньги. У меня окупается потому что объём задач большой, я соло-разработчик с несколькими продуктами. Если у вас один проект и времени хватает писать руками, экономика другая.
Финально: AI это не “хочу получить и сразу получаю”. Это “хочу получить, формулирую задачу, получаю черновик, дорабатываю”. Просто эта цепочка быстрее чем “хочу получить, пишу с нуля, проверяю”. Если у вас не получается быстрее — это не значит что AI бесполезен, это значит что ваши задачи другие, или промпты не отстроены, или стек неудобный для текущих моделей.
Trello это доска, ты сам её читаешь и сам делаешь выводы. Лира это не доска и не помощник, а директор. Она сама смотрит на происходящее в компании, сама принимает решения о приоритетах, сама пишет сотрудникам, сама напоминает обещания.
Гендир ставит цели. Дальше Лира работает с командой за него. Каждый день решает кому что важно сделать, кто буксует, что сказать кому в личке. Не “помощник” в смысле “помогаю человеку”, а “директор” в смысле “беру операционку на себя”.
Под капотом сейчас задачи, обещания, цели, граф знаний компании. В роадмапе подключение производственных данных, 1С, других источников, чтобы Лира видела не только что люди говорят в чате, но и что реально происходит в компании. Дальше она будет управлять не только людьми, но и процессами.
Это уже другая категория продукта чем Trello. И ниша другая.
Спасибо! Про electron-store вы правы, миграции у неё через
migrationsAPI делаются непрозрачно, особенно когда схема нетривиальная. Я как раз поэтому пока остался на своёмreadSessionFile/writeSessionFileпусть не атомарно, зато прозрачно. Возможно перейду на conf это младший брат electron-store от того же автора, без миграций вообще, и под мои задачи (один JSON со session-токеном) её более чем достаточно.Винду пока не подписал это в очереди, но процесс получения EV-сертификата для российского юрлица в 2026 непростой, поэтому откладываю. Если у вас есть свежий опыт поделитесь, было бы полезно.
ConnectionService API действительно существует и именно для этого: интеграция с system dialer на Android. Никто не использует — потому что это адски сложно правильно реализовать. У ConnectionService очень много edge cases: разные OEM реализуют его по-разному (Samsung, Xiaomi, Huawei имеют свои quirks), нужно правильно обрабатывать lifecycle сервиса, нужны permissions которые пользователи часто отказываются давать (“Make and manage phone calls”). А ещё на Android нет аналога iOS VoIP push — на FCM data message нельзя гарантированно поднять foreground service за миллисекунды до показа звонка. Поэтому многие (включая меня в текущей версии ONEMIX) делают компромисс — обычные high-priority push с custom UI вместо нативной интеграции. Но согласен, что iOS-овская унифицированная лента звонков — это сильно лучше UX. У меня в roadmap есть пункт “разобраться с ConnectionService”, но руки пока не дошли. Если ты сам ковырял эту тему — интересно услышать что-то конкретное.
Справедливый вопрос. Полноценных дампов webrtc-internals с production я в статью не вставлял — это отдельный материал. Но из своих логов: timestamps от createOffer до первого ontrack у меня в среднем 700-1400мс на разных сетях. Цифры “8-12 секунд” в gather-then-send — это результат моих собственных тестов на старой реализации до перехода на trickle, на плохих мобильных сетях LTE с международным TURN. На хорошем Wi-Fi разница меньше — gather может занимать секунды 2-3. Если интересно — могу в отдельном посте/статье разобрать дампы webrtc-internals с трассировкой, это полезная тема.