В индустрии давно используются системы контроля версий. Они помогают команде совместно работать над кодом, позволяют отследить изменения и при необходимости откатиться до рабочей версии. Помимо кода там можно хранить конфигурации и манифесты, спецификации и документацию. Короче, Всё-as-Code. Первая такая система возникла аж в 1972 в Bell Labs. Программа SCCS отслеживала локальные изменения файлов. В 1986 появилась централизованная система - CVS, там уже использовался центральный репозиторий и клиент-серверное взаимодействие. Теперь уже несколько пользователей могли работать с единой кодовой базой. В начале 2000-х вышла SVN, как преемник CVS, и стала фактическим стандартом на несколько лет. Сейчас это Apache Subversion, и она до сих пор используется в некоторых старых проектах. В 2005 создатель Linux Линус Торвальдс представил третье поколение подобных систем - Git, который и по сей день является самым популярным инструментом для контроля верисий. В том же году появились аналоги - Mercurial, тоже довольно популярный, и Bazaar, но Git всех обогнал. Вот тут можно почитать. И вот мы уже третий десяток лет работаем с Git, вот таким он оказался универсальным и удобным. Понятное дело, что прогресс продолжается. Есть экспериментальные и альтернативные системы нового поколения, но они остаются нишевыми. Однако, энтузиасты усовершенствуют даже Git. Есть такой проект - GitButler. Это Git-клиент, созданный Scott Chacon, сооснователем GitHub. Проект привлёк $17M от фонда a16z. Вот что они пишут про возможности: ▪️Параллельные ветки - можно работать над разными задачами в одном рабочем пространстве без переключения контекста ▪️Стековые ветки - это зависимые друг от друга ветки (тут подробнее) ▪️Бесконечное Undo - снэпшоты перед каждой операцией позволяют откатиться без потерь ▪️Коммитами можно жонглировать как угодно даже после пуша в удаленный репозиторий ▪️ИИ-помощник для названий веток, коммитов и описаний PR ▪️Интеграция с GitHub и GitLab Опенсорсно. Есть десктопная и консольная версии. #tools #git

#кейс_стади Разбор с СEO, вайбкодом и Едрит Многие ответили на задачу с позиции мидл-менеджера: провести ретро, спросить архитектора, поправить процессы, не лезть в чужую работу. Но CEO здесь вообще в другой позиции. У него сорван крупный контракт, под риском следующий рейз, потеряно доверие к инженерным оценкам и появился контрпример. Его задача быстро вернуть управляемость Первое Показать свою ветку CTO и поставить задачу ее опровергнуть. И не с позиции "я сделал лучше вас", а "вот решение, которое по моей текущей оценке закрывает то же самое за две недели 1 человеком". Можно остановить менее важные задачи, подключить сильных инженеров и прогнать тот же набор проверок. Если решение развалится -> отлично, CEO получит конкретные причины, чего он не понимал. Если после недели допила оно сравнимо -> вопрос становится очень неприятным Второе CTO должен объяснить не код, а управленческое решение. Что из вот этого platform наворота было еально необходимо для Дастархана, что строилось на будущее, кто принял вообще сравнивал варианты и какая экономика у них. Критичный бизнес-дедлайн был известен заранее. Если инженерка сознательно обменяла его на красивую платформу, бизнес должен был участвовать в этом решении, а не узнать о последствиях через пять месяцев Третье С этого момента подобные решения принимаются иначе. Есть жесткое внешнее ограничение -> CTO приносит несколько вариантов со сроками, рисками и стоимостью: быстро закрыть потребность, сделать нормально, строить платформу. Какой риск купить -> решает CEO. Архитектура не существует отдельно от экономики, особенно когда на другой стороне контракт и инвестиционные деньги Четвертое CTO должен принести отчет, причем не нейрослоп HTML-бандл от клодкода, а понятные 2 странички с хронологией проекта, где были проблемы, что для них делали и почему не уложились в сроки. Отдельно информация как им управляли и контролировали. По отчету станет прозрачно осознавал ли техдир важность проекта и делает ли менеджмент в компании полезную нагрузку Отдельно меня удивило, сколько людей вообще начали обсуждать, правильно ли CEO втихаря вайбкодит и должен ли он лезть в работу разработчиков. Это взгляд из своей профессиональной колокольни. В условиях кейса CEO уже вайбкодит, уже достаточно погружен и получил новую информацию о собственной компании. Спорить с условиями задачи вместо принятия решения -> уходить от самой задачи. Тем более я постоянно общаюсь с C-level продуктовых компаний и это уже совсем не экзотика, когда даже фаундер собирает себе что-то И дальше самое важное -> реакция CTO. Ошибка в архитектуре допустима. Сорванный срок тоже иногда допустим. Недопустимо, когда критичный для бизнеса срок сорван, последствия воспринимаются как данность, альтернативное решение никто не хочет проверять, а объяснение заканчивается на вам не понять разработку. Если CTO сам разбирает ситуацию, показывает где ошибка CEO и меняет систему -> доверие можно восстановить. Если защищает статус-кво -> я бы ставил CTO испытательный срок

Знаю что для разработки есть эмулятор Xcode которым уже неплохо управляют ии-агенты, но стало интересно есть ли что-то подобное для реальных устройств Оказывается есть: Скормите вашему агенту phone-harness, скилл который объясняет ему как использовать маковский iPhone Mirroring для управления айфоном Я бы описал это как Computer Use, но для телефона:

1/ Агент делает скриншот экрана 2/ С помощью встроенного в macOS распознавания текста получает дерево интерфейса 3/ Тапает в конкретную координату 4/ Смотрит на расхождение кадров чтобы понять сработало ли

Ну и фишка iPhone Mirroring что мне не нужно иметь телефон под рукой, подключать его через провод, разблокировать и тд. Сценариев использования куча: от тестирования приложений до сбора корзины в китайской доставке. Но так как это своего рода computer-use, на сложные задачи я бы не рассчитывал 😏 @tips_ai #tools

Что можно понять за 10 лет разработки? Например, что писать новый код приходится реже, чем разбираться в чужом. Поэтому умение быстро понять, как устроен уже существующий проект — один из самых главных навыков разработчика. Технологию меняются постоянно, а проблемы всё те же. Плохие запросы к базе, сложные решения, которые некому поддерживать. И код, смысл которого приходится восстанавливать по кусочкам. Отсюда еще несколько выводов. «Скучные» технологии часто живут дольше модных, хороший разработчик должен понимать бизнес, а пользователям вообще всё равно, насколько красивая у вас архитектура. Им важно, чтобы всё работало. Какие еще уроки автор вынес из десяти лет разработки

Ответ на предыдущий вопрос. На реализацию фичи у кодекса ушло 12 минут и меньше процента подписки (как было 89, так 89 и осталось). Я не за компом, поэтому пришлось попросить Codex сделать и прислать скриншоты. Вложу их в комментарии. В коде много оверинжиниринга не заметил, только не понравилось, как сделана работа с выкачкой архивов. Но я все равно сейчас откачу назад все изменения! Фишка в том, что в этом проекте у Codex-a есть возможность создавать переиспользуемые UI компоненты в едином стиле. И этот прототип нужен был, чтобы понять то, как эти компоненты должны выглядеть. Поэтому следующий шаг:

I want to manage UI complexity. Load piecemeal mentality and suggest which high level UI components would you implement and pull into the component library

На Arch удобно учиться, но работать лучше на Ubuntu. По крайней мере, к такому выводу автор пришел спустя год экспериментов. Сначала ему нравилось делать всё своими руками: подключать Wi-Fi через терминал, разбираться с дисками, собирать систему под себя и периодически ее ронять. Так он действительно лучше понял, как устроен Linux. Потом понадобился рабочий софт для FPGA. Vivado официально поддерживает Ubuntu, а на Arch приходится надеяться на патчи сообщества и помнить, что очередное обновление может что-нибудь сломать. В статье еще больше объяснений, почему новичкам хотя бы несколько месяцев нужно пожить с Arch. А еще рассказ, как эксперименты с системой начинают отнимать рабочее время.

Взаимопомощь AI-агентов Claude Code ходит по интернету и пишет в сессию промежуточный результат: – Твиттер опять глючит, пробую варианты обхода. Так не получилось, сяк получилось, записываю на будущее, как избегать проблем. Смотрю на это и немного ужасаюсь. Один и тот же Твиттер глючит одинаково для миллиона агентов, а каждый из них самостоятельно придумывает, как обойти идентичную проблему. Крайне неэффективно ж. Вот бы сделать какую-то Википедию, где AI бы сразу забирал правильное решение. Оказывается, такое уже есть. #стартапдня cq – проект внутри Mozilla – реализует ровно “мою” идею. По их замыслу, прежде чем биться головой о новую беду, агент спрашивает базу – вдруг кто-то уже мучился. Если не нашел и разобрался сам, в конце сессии он записывает находку: такая-то версия такой-то библиотеки ломается вот так, лечится вот этим. Новая запись начинается с низким доверием и набирает вес по мере того, как ее подтверждают другие пользователи. Протухшее помечается флажком. Хранилищ три – личное, командное и всемирное. Всемирное, к сожалению, пустое – за 3 месяца после старта в проекте накопились аж 94 готовых рецепта. Не миллиона, не тысячи, просто 94. Подключать его ради такой базы смысла никакого нет, никто и не подключает, количество и не растет. Ловушка сетевого эффекта как она есть. Видимо, cq её уже не преодолеет. Логично было бы делать такую штуку на стороне OpenAI или Anthropic. Включили бы её в своих инструментах полупринудительно и никаких проблем с набором стартовой аудитории. Не делают. Claude Code предположил, что “они зарабатывают на количестве токенов, им выгодно, чтобы агенты побольше мучились,” – я не согласен, но забавно, что детище “думает” о мотивации родителей. https://cq.exchange/ #корпоративный #ai

AC DC снова в моде Highway to Hell петь начинать не надо! 1. AC DC клевый термин от ребят из Sonar. Agentic Centric Developer Cycle. 2. И казалось бы ну какие статические анализаторы кода в век победившего AI, однако всякая инфраструктура базовая становится все важнее и критичнее. 3. Ребята из Sonar предлагают любопытную мысль - нафиг проверять код агента только после того, как он закончил весь PR и отдал его на ревью. Они предлагают ревьюить код в процессе его написания, тем самым повышая его качество еще до того, как агент закончит свою работу. Почему именно так? 4. Тут все просто: количество кода, генерируе ого после взрывного роста AI растет х2, но люди не могут ревьюить с той же скоростью и становятся узки горлышком. В ответ на это, мы предлагаем ревьюить код, используя других агентов. Прикольно? 5. Да, но в таком случае получается слишком длинный «хоп» и с учетом роста стоимости использования агентов мы начинаем тратить больше времени и ресурсов на исправление. Как решение, нам и предлагается инкрементально улучшать код прямо в процессе его написания. А вот ссылочка на оригинал доклада

Гергей пленных не берет. Он вообще в последний год очень жёстко разносит разный булщит. Прямо вскрылся наш родной токсик 🤤 У меня продукт полностью пишет ИИ например. Поэтому у меня реально мозг в раскоряку. С одной стороны для меня это работает, с другой - вижу много примеров как люди жгут токены, число комитов улетает в космос, а пользователи видят только инциденты. Причем это не "наемный глупенький менеджер", а основатель gumroad. Тот самый founder mode про который много пишут, что основатель точно знает куда рулить продукт. Пока у меня рабочая теория, что продукт написанный ИИ с нуля получается развивать, а легаси - с нюансами. Комменты отключены 😮‍💨

Luna - потрясающая модель для Code Review Собственно, похоже, что GPT 5.6 Luna max сейчас лучшая моделька для код ревью по соотношению цена-качество, да и в принципе одна из лучших моделей для ревью. Это подтверждают как наши внутренние бенчи на Code Review, так и новый бенчмарк от Vercel DeepsecBench (да да, бенч на секьюрити в принципе можно смело экстраполировать на код ревью). С учетом ее предельной дешевизны, крайне рекомендую включать ее в свои пайплайны - как для ревью, так и для исследований контекста. Интересно, кстати, что Опус 5 в нашем бенчмарке на код ревью тоже очень круто себя показывает по recall (полнота находок). А еще, там DeepSWE bench обновили изрядно модельный ряд и новая дипсик 4 флеш там уж очень хороша - практически на уровне grok 4.5/sonnet 5 (53% vs 54%) при цене более, чем в 20 раз дешевле и в 264 раза дешевле sonnet 5. Китайцы снова жгут. Если вы у себя в компании крутите локально модельки - точно стоит присмотреться. @ai_driven

Приятный лайфхак - просить Codex писать красивые новости про прогресс своих проектов Ему это ничего не стоит (ибо в ~/.codex/sessions есть все логи всех проектов), а вот со стороны посмотреть на прогресс во время отпуска - приятно. К слову, Agentic OS на скриншоте - это не очередная AI Native среда для построения следующего единорога (такие продукты сейчас пытаются писать почти все), а просто наглядный пример моего текущего подхода к разработке проектов, которая заодно реализует тот Stateless MCP 2.0 протокол для доступа агентов к единой multi-tenant Personal OS. Примерами из этого проекта я буду делиться тут в канале, а полный доступ ко всем изменениям и исходникам сделаю отдельно, в рамках продолжения направления с AI Coding. Ваш, @llm_under_hood 🤗