DeepSeek Coder и CodeLlama действительно уже не самые актуальные. Упомянул их в контексте исследования ByteDance (https://arxiv.org/pdf/2501.15134), где они экспериментировали с разными размерами моделей для оптимизации latency/quality трейдофа. Сейчас, конечно, все переходят на GPT-5, Claude 4, Gemini Pro для критических проверок.
P.S. Да, статью помогал структурировать Claude, но весь фактический материал — из публичных рейсов компаний. В эпоху AI было бы странно не использовать его для улучшения текста, как мы используем IDE для написания кода :) Мы внедрение только начали и этот анализ проводился как изучение best-practices дабы не наступать на чьи-то грабли. Статья с нашими результатами будет как наберётся достаточное количество данных для анализа результатов.
Вы абсолютно правы насчёт статических анализаторов — SonarQube, ESLint и прочие действительно отлично справляются с базовыми проблемами. И по стоимости они часто выгоднее. Ключевое отличие AI-систем — контекстное понимание кода за счёт использования RAG (подробнее описал в ветке выше).
Но вы правы — с концептуальными архитектурными проблемами AI пока справляется плохо. Он не скажет "эта микросервисная декомпозиция избыточна" или "этот bounded context нарушает DDD принципы". Оптимальная стратегия сейчас: SonarQube для базовых проверок + AI для контекстного анализа + человек для архитектурных решений. Это даёт лучший ROI.
Вы абсолютно правы — базовые проверки форматирования и простые баги типа null dereference действительно эффективнее решаются детерминированными инструментами.
Я привёл упрощённые примеры для наглядности, можно их немного усложнить:
1. Контекстно-зависимые проблемы
# Линтер не увидит проблему:
def process_payment(amount, user_id):
if amount > 1000:
notify_admin(user_id) # AI: "А где проверка прав пользователя?"
return charge_card(amount)
2. Бизнес-логика и edge cases В ByteDance 40% полезных комментариев AI касались именно логических ошибок: "При таком условии заказ может быть обработан дважды" или "Этот расчёт не учитывает часовые пояса".
3. Security beyond SAST AI находит проблемы типа "Этот endpoint раскрывает внутреннюю структуру БД через error message" — формально код корректен, но есть риск.
Вы правы насчёт "плохо развитого линтинга" — часто команды сначала внедряют AI, а потом понимают, что 30% его работы можно заменить правильно настроенным ESLint + Prettier + SonarQube. Всегда как в пирамиде потребностей нужно двигаться снизу вверх: сначала линтеры, дальше уже надстройка над ними.
Из нашего опыта и кейсов в статье складывается такая картина: AI берёт на себя рутину (те самые скобочки, null pointer, очевидные проблемы безопасности), освобождая время для того самого ценного обмена опытом.
Например, в Microsoft отметили интересный эффект — когда разработчики перестали тратить время на поиск тривиальных ошибок, качество дискуссий в ревью значительно выросло. Вместо "забыл проверку на null в строке 42" обсуждают "а почему мы выбрали именно такой паттерн для этой задачи?".
Google пошёл дальше — их ML-suggested edits покрывают только 7.5% комментариев, остальные 92.5% остаются за людьми. При этом экономия времени колоссальная, потому что эти 7.5% — самые времязатратные и скучные проверки.
Поэтому вижу это как "И-И", а не "ИЛИ-ИЛИ": AI для рутины + люди для менторинга и архитектурных решений = больше времени на действительно важные обсуждения.
Это легко объяснимо. Нейронки не умеют думать (то, что называется думать сейчас, по факту это простое построение логических цепочек на основе опыта), поэтому они хорошо решают чётко поставленные задачи.
Нет, это как раз пример антипаттерна, который я привожу как "так делать НЕ надо" :)
У нас противоположный подход — AI-инструменты доступны всем, но использование полностью добровольное. Никаких KPI на процент AI-кода нет.
Более того, мы явно говорим команде: если AI мешает или замедляет — не используйте. Некоторые наши senior'ы после экспериментов вернулись к классической разработке, и это нормально. Зато junior'ы активно используют для boilerplate кода и изучения незнакомых частей кодовой базы.
Главная метрика для нас — это качество конечного продукта и удовлетворенность разработчиков, а не процент использования инструмента.
Но, в целом, каждый специалист (не только разработчик, но и QA, аналитик, продакт) может найти кусок работы, который AI может выполнить быстрее и не хуже.
А, я имел ввиду другое место. Тем не менее ничего страшного, если хэндлер не сразу прочитает обновление. Я не считаю это критичным, но буду рад, если Вы объясните мне если я не прав.
DeepSeek Coder и CodeLlama действительно уже не самые актуальные. Упомянул их в контексте исследования ByteDance (https://arxiv.org/pdf/2501.15134), где они экспериментировали с разными размерами моделей для оптимизации latency/quality трейдофа. Сейчас, конечно, все переходят на GPT-5, Claude 4, Gemini Pro для критических проверок.
P.S. Да, статью помогал структурировать Claude, но весь фактический материал — из публичных рейсов компаний. В эпоху AI было бы странно не использовать его для улучшения текста, как мы используем IDE для написания кода :) Мы внедрение только начали и этот анализ проводился как изучение best-practices дабы не наступать на чьи-то грабли. Статья с нашими результатами будет как наберётся достаточное количество данных для анализа результатов.
Вы абсолютно правы насчёт статических анализаторов — SonarQube, ESLint и прочие действительно отлично справляются с базовыми проблемами. И по стоимости они часто выгоднее. Ключевое отличие AI-систем — контекстное понимание кода за счёт использования RAG (подробнее описал в ветке выше).
Но вы правы — с концептуальными архитектурными проблемами AI пока справляется плохо. Он не скажет "эта микросервисная декомпозиция избыточна" или "этот bounded context нарушает DDD принципы".
Оптимальная стратегия сейчас: SonarQube для базовых проверок + AI для контекстного анализа + человек для архитектурных решений. Это даёт лучший ROI.
Вы абсолютно правы — базовые проверки форматирования и простые баги типа null dereference действительно эффективнее решаются детерминированными инструментами.
Я привёл упрощённые примеры для наглядности, можно их немного усложнить:
1. Контекстно-зависимые проблемы
2. Бизнес-логика и edge cases
В ByteDance 40% полезных комментариев AI касались именно логических ошибок: "При таком условии заказ может быть обработан дважды" или "Этот расчёт не учитывает часовые пояса".
3. Security beyond SAST
AI находит проблемы типа "Этот endpoint раскрывает внутреннюю структуру БД через error message" — формально код корректен, но есть риск.
Вы правы насчёт "плохо развитого линтинга" — часто команды сначала внедряют AI, а потом понимают, что 30% его работы можно заменить правильно настроенным ESLint + Prettier + SonarQube. Всегда как в пирамиде потребностей нужно двигаться снизу вверх: сначала линтеры, дальше уже надстройка над ними.
Из нашего опыта и кейсов в статье складывается такая картина: AI берёт на себя рутину (те самые скобочки, null pointer, очевидные проблемы безопасности), освобождая время для того самого ценного обмена опытом.
Например, в Microsoft отметили интересный эффект — когда разработчики перестали тратить время на поиск тривиальных ошибок, качество дискуссий в ревью значительно выросло. Вместо "забыл проверку на null в строке 42" обсуждают "а почему мы выбрали именно такой паттерн для этой задачи?".
Google пошёл дальше — их ML-suggested edits покрывают только 7.5% комментариев, остальные 92.5% остаются за людьми. При этом экономия времени колоссальная, потому что эти 7.5% — самые времязатратные и скучные проверки.
Поэтому вижу это как "И-И", а не "ИЛИ-ИЛИ": AI для рутины + люди для менторинга и архитектурных решений = больше времени на действительно важные обсуждения.
Это легко объяснимо. Нейронки не умеют думать (то, что называется думать сейчас, по факту это простое построение логических цепочек на основе опыта), поэтому они хорошо решают чётко поставленные задачи.
Нет, это как раз пример антипаттерна, который я привожу как "так делать НЕ надо" :)
У нас противоположный подход — AI-инструменты доступны всем, но использование полностью добровольное. Никаких KPI на процент AI-кода нет.
Более того, мы явно говорим команде: если AI мешает или замедляет — не используйте. Некоторые наши senior'ы после экспериментов вернулись к классической разработке, и это нормально. Зато junior'ы активно используют для boilerplate кода и изучения незнакомых частей кодовой базы.
Главная метрика для нас — это качество конечного продукта и удовлетворенность разработчиков, а не процент использования инструмента.
Но, в целом, каждый специалист (не только разработчик, но и QA, аналитик, продакт) может найти кусок работы, который AI может выполнить быстрее и не хуже.
Добрый день.
Это скриншот свёрстанной HTML странички, которую я использую как шаблон для подобных диаграмм. Обошлось без дизайнеров :)
Согласен, иногда возможно, но как универсальное решение нельзя рассматривать.
Это только при маршалинге. А вот если у вас анмаршалинг, то Вы не сможете понять: Вам не передали значение совсем или передали, но пустое.
дистрибутив нет, а вот то, что его раздувает там работает — тот же systemd и прочее
большую проблему доставляет то, что все это жрет оперативку
Для чего в Get bool? Ведь если элемент не найден, то мы и так nil возвращаем, по нему и понятно
Можно ли добавить go tools: dep init?
я же показал, все слушают updateChannel и потом уже вызывают функцию обрабатывающую конкретное сообщение
Через вебхук однозначно лучше. Но мне кажется, что все горутины должны обрабатывать все типы сообщений.
во всех горутинах и все
Зачем для каждого вида сообщений отдельная горутина?
Сам по себе он не должен меняться, только есть скеил делать
Понял, спасибо. Да, не гарантируется, но к счастью с таким пока не сталкивался, но буду иметь в виду.
Почему же? Там всегда есть корректный указатель, старый или новый. Начальный задается еще до старта сервера: https://github.com/GoWebProd/goDNS/blob/master/src/server/main.go#L78
А, я имел ввиду другое место. Тем не менее ничего страшного, если хэндлер не сразу прочитает обновление. Я не считаю это критичным, но буду рад, если Вы объясните мне если я не прав.