Вышел Go 1.26. Все написали, а я туплю
Если коротко: релиз не про синтаксический сахар, а про производительность, рантайм и инструменты для продакшена. Новый сверхбыстрый json так и не вышел из стадии experimental (там есть проблемы с памятью и обратной совместимостью)
Новый сборщик мусора Green Tea
В Go 1.26 по умолчанию включён новый сборщик мусора Green Tea. Он сканирует память пачками (по span’ам), лучше использует кэш CPU и умеет в векторизацию на amd64.
Ожидания команды - минус 10-40% накладных расходов GC в реальных приложениях. Особенно полезно для сервисов с высокой нагрузкой и большим количеством мелких объектов.
Быстрее cgo и syscalls
до 30% быстрее cgo-вызовы
около 9% ускорения системных вызовов
Быстрее мелкие аллокации
Для объектов размером 1-512 байт добавлены специализированные пути аллокации. В синтетических тестах до ~30% быстрее для маленьких объектов.
В реальных сервисах команда ожидает ~1% общего выигрыша.
new(expr)
Теперь new можно вызывать не только с типом, но и с выражением:
Удобно для optional-полей со ссылками (JSON, protobuf), когда нужно быстро создать *bool, *int и т.д. Без лишних временных переменных.
errors.AsType
Появилась type-safe альтернатива errors.As: errors.AsType.
без лишних переменных, быстрее, меньше аллокаций, + некоторые ошибки ловятся на этапе компиляции
bytes.Buffer.Peek
Метод Peek(n) позволяет посмотреть следующие N байт без сдвига буфера. Удобно для протоколов и парсеров.
Профилирование утечек горутин
Экспериментальный goroutineleak в runtime/pprof.
Теперь можно выявлять зависшие горутины в продакшене - не дедлок, а именно утечки, когда горутина навсегда блокируется, но процесс продолжает жить.
+ добавлены новые метрики по горутинам
В log/slog появился MultiHandler.
Теперь можно из коробки писать логи сразу в stdout и файл (или в несколько систем), без кастомных обёрток.
Reader-less crypto
Большинство функций в crypto-пакетах теперь игнорируют переданный io.Reader и используют системный источник случайности.
Это убирает зависимость от конкретной реализации и делает поведение стабильнее между версиями Go.
fmt.Errorf
Для строк без форматирования fmt.Errorf("x") теперь почти не отличается по аллокациям от errors.New("x").
Можно перестать думать над тем, какую функцию выбрать.
io.ReadAll
Переписан алгоритм роста буфера:
• примерно в 2 раза быстрее
• в 2 раза меньше памяти
Cross Join - канал о разработке
Если коротко: релиз не про синтаксический сахар, а про производительность, рантайм и инструменты для продакшена. Новый сверхбыстрый json так и не вышел из стадии experimental (там есть проблемы с памятью и обратной совместимостью)
Новый сборщик мусора Green Tea
В Go 1.26 по умолчанию включён новый сборщик мусора Green Tea. Он сканирует память пачками (по span’ам), лучше использует кэш CPU и умеет в векторизацию на amd64.
Ожидания команды - минус 10-40% накладных расходов GC в реальных приложениях. Особенно полезно для сервисов с высокой нагрузкой и большим количеством мелких объектов.
Быстрее cgo и syscalls
до 30% быстрее cgo-вызовы
около 9% ускорения системных вызовов
Быстрее мелкие аллокации
Для объектов размером 1-512 байт добавлены специализированные пути аллокации. В синтетических тестах до ~30% быстрее для маленьких объектов.
В реальных сервисах команда ожидает ~1% общего выигрыша.
new(expr)
Теперь new можно вызывать не только с типом, но и с выражением:
p := new(42)
Удобно для optional-полей со ссылками (JSON, protobuf), когда нужно быстро создать *bool, *int и т.д. Без лишних временных переменных.
errors.AsType
Появилась type-safe альтернатива errors.As: errors.AsType.
без лишних переменных, быстрее, меньше аллокаций, + некоторые ошибки ловятся на этапе компиляции
bytes.Buffer.Peek
Метод Peek(n) позволяет посмотреть следующие N байт без сдвига буфера. Удобно для протоколов и парсеров.
Профилирование утечек горутин
Экспериментальный goroutineleak в runtime/pprof.
Теперь можно выявлять зависшие горутины в продакшене - не дедлок, а именно утечки, когда горутина навсегда блокируется, но процесс продолжает жить.
+ добавлены новые метрики по горутинам
В log/slog появился MultiHandler.
Теперь можно из коробки писать логи сразу в stdout и файл (или в несколько систем), без кастомных обёрток.
Reader-less crypto
Большинство функций в crypto-пакетах теперь игнорируют переданный io.Reader и используют системный источник случайности.
Это убирает зависимость от конкретной реализации и делает поведение стабильнее между версиями Go.
fmt.Errorf
Для строк без форматирования fmt.Errorf("x") теперь почти не отличается по аллокациям от errors.New("x").
Можно перестать думать над тем, какую функцию выбрать.
io.ReadAll
Переписан алгоритм роста буфера:
• примерно в 2 раза быстрее
• в 2 раза меньше памяти
Cross Join - канал о разработке
🔥15👍7❤1
Пара человек меня спросили, буду ли я делать аналогичный канал на Max.
Нет, не буду.
Нет, не буду.
2👏92😁23❤13🤡10👍4😭3👎2🖕2🥰1😢1
Forwarded from Tuzov AI Lab
https://groups.google.com/g/golang-dev/c/4Li4Ovd_ehE
Кто-то залил CL (changelist, аналог Pull Request в системе Gerrit) в Go с тегом
Co-Authored-By: Claude Opus 4.5 в описании коммита. Ian Lance Taylor это заметил и поднял вопрос в рассылке golang-dev: а вообще есть ли политика по поводу AI-написанного кода? Авторские права, CLA — всё это висит в воздухе.Ответ Rob Pike:
> Это очень скользкая дорожка. Осторожнее с первым шагом. Рекомендую просто сказать: нет.
Через несколько дней Russ Cox написал огромный взвешенный ответ. И это, пожалуй, лучший текст о месте AI в разработке, что я читал за последнее время. Рекомендую вам ознакомиться с ним целиком лично.
Самый сочный кусок — про "танцующих слонов":
> Люди хвастаются кодовыми базами на сотни тысяч строк, которые никто никогда не смотрел, написанными в рекордные сроки. При ближайшем рассмотрении они неизменно оказываются скорее танцующими слонами, чем полезными engineering-артефактами.
То есть, они впечатляют, но только пока не присмотришься — слишком большие, медленные, много багов, и никто не знает как их поддерживать.
Его позиция: фундаментальные вещи software engineering не изменились. AI — это инструмент, как редактор или профайлер. Можно писать качественный код с помощью AI, но только если не отключать мозг. Контрибьютор всё так же обязан присылать код, который он сам проревьюил и обдумал — AI не снимает с тебя ответственности.
По авторским правам: Google's OSPO разобрался, используйте спокойно. Но интересно другое: Alan Donovan в треде заметил, что значительная часть CLs уже содержит LLM-сгенерированный код — авторы просто не признаются.
По
Co-Authored-By — убрать. Причина прямолинейная: это бесплатная реклама AI-компаниям, и ничего больше. Юридически строчка бессмысленна (AI не может быть автором по US copyright), информации не несёт — непонятно кто что написал, и даже как маркер использования AI не работает: модель сама непоследовательно решает, добавлять её или нет.————
Позиция Russ Cox мне близка, т.к. я лично сталкивался с подобными случаями даже на работе — когда разработчик перегибал с вайбкодингом. Работать с этим становится невозможно, проще переписать с нуля.
"Танцующие слоны" — это хорошее описание того, что происходит когда люди воспринимают AI как замену мышлению, а не как инструмент. Go team явно не собирается идти по этому пути
#goteam #llm #claude
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30❤7👍5💯3
Интересный хак для упрощения запросов Postgres
Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную
вот пример:
Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.
Но не суть, вам хочется один раз вычислить значение, без дублирования кода.
Это делается так
Т.е. мы выделяем расчеты в cross join lateral, давай получившимся полям человеческие имена. И хотя в целом строк больше, но меньше дублирования кода, в котором можно ошибиться, и читается это зачастую проще.
https://www.db-fiddle.com/f/wSnCfpqzZypaPXSnsVUaYi/0
🫥 Cross Join - канал о разработке
⠀
Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную
вот пример:
SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
FROM orders;
Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.
Но не суть, вам хочется один раз вычислить значение, без дублирования кода.
Это делается так
SELECT
o.item_name,
o.price,
o.quantity,
v1.subtotal, -- используем переменные
v2.tax,
v1.subtotal + v2.tax as grandtotal
FROM orders o
-- "Объявляем" subtotal
CROSS JOIN LATERAL (
SELECT o.price * o.quantity AS subtotal
) AS v1
-- "Объявляем" tax, используя subtotal
CROSS JOIN LATERAL (
SELECT v1.subtotal * 0.15 AS tax
) AS v2
Т.е. мы выделяем расчеты в cross join lateral, давай получившимся полям человеческие имена. И хотя в целом строк больше, но меньше дублирования кода, в котором можно ошибиться, и читается это зачастую проще.
https://www.db-fiddle.com/f/wSnCfpqzZypaPXSnsVUaYi/0
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Cross Join - канал о разработке
Канал о разработке Антона Околелова. Разрабочик/ex-тимлид Go, живу в Чехии. Мысли, новости, вопросы.
По вопросам рекламы @antonokolelov
По вопросам рекламы @antonokolelov
👍35❤10🔥5🥴2
Написал статью на хабр про cross join lateral, плюсаните плиз )
https://habr.com/ru/articles/1005138/
https://habr.com/ru/articles/1005138/
Хабр
Интересный хак для упрощения сложных SELECT в Postgres
Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную вот пример:...
🔥16
Сколько примерно процентов кода пишете с ии-агентами (cursor, claude code и т.д.)? Т.е. не копированием из чата chatGPT, а именно агент сам правит код по вашей просьбе.
Давайте замерим ситуацию на данный момент, через месяца три проведу опрос снова.
Давайте замерим ситуацию на данный момент, через месяца три проведу опрос снова.
Final Results
17%
> 90%
10%
70%
8%
50%
11%
30%
28%
< 10%
25%
мне посмотреть
Ну вот такая динамика получилась. Я пересчитал проценты, убрав "мне посмотреть", и построил график по времени.
За три месяца доля тех, кто не пишет или почти не пишет код с агентским ИИ сократилась с 60% до 38%
Доля тех, кто весь или почти весь код пишет через агента, выросла с 8.8% до 23.3%
Динамика бешеная. Что-то поменялось в моделях и инструментах, что этим наконец-то стало можно легко пользоваться.
Я лично почувствовал, что в последние месяцы матерюсь всё меньше и меньше (cursor + gpt 5.2)
При этом, важно! Хотя пишу много кода с агентом, но стараюсь тщательно проверять его высеры и просить подправлять какие-то места. Иначе код превратится в сраное глючное говно очень-очень быстро, потом ни человек, ни машина в этом не разберётся. Где-то недоделала, где-то недопоняла, и это как снежный ком.
Стараюсь делить задачи на мелкие, т.е. не совать сразу всё, а скармливать по чуть-чуть и ревьювить. Иначе слишком много кода проверять за раз. Хотя, курсор сам умеет строить план и т.д, и даже если план хороший - всё же небольшими итерациями намного быстрее и качественнее выходит.
Вот сырые данные, если кто захочет построить свой график.
8 декабря такие данные:
"> 90%" - 46
"70%" - 38
"50%" - 46
"30%" - 79
"< 10%" - 313
3 марта такие
"> 90%" - 100
"70%" - 58
"50%" - 47
"30%" - 61
"<10%" - 163
Жалко, конечно, что канал не очень многочисленный, и проголосвали далеко не все. Т.е. понятно, что это не статистика не разу. Но всё равно любопытно.
🫥 Cross Join - канал о разработке
⠀
За три месяца доля тех, кто не пишет или почти не пишет код с агентским ИИ сократилась с 60% до 38%
Доля тех, кто весь или почти весь код пишет через агента, выросла с 8.8% до 23.3%
Динамика бешеная. Что-то поменялось в моделях и инструментах, что этим наконец-то стало можно легко пользоваться.
Я лично почувствовал, что в последние месяцы матерюсь всё меньше и меньше (cursor + gpt 5.2)
При этом, важно! Хотя пишу много кода с агентом, но стараюсь тщательно проверять его высеры и просить подправлять какие-то места. Иначе код превратится в сраное глючное говно очень-очень быстро, потом ни человек, ни машина в этом не разберётся. Где-то недоделала, где-то недопоняла, и это как снежный ком.
Стараюсь делить задачи на мелкие, т.е. не совать сразу всё, а скармливать по чуть-чуть и ревьювить. Иначе слишком много кода проверять за раз. Хотя, курсор сам умеет строить план и т.д, и даже если план хороший - всё же небольшими итерациями намного быстрее и качественнее выходит.
Вот сырые данные, если кто захочет построить свой график.
8 декабря такие данные:
"> 90%" - 46
"70%" - 38
"50%" - 46
"30%" - 79
"< 10%" - 313
3 марта такие
"> 90%" - 100
"70%" - 58
"50%" - 47
"30%" - 61
"<10%" - 163
Жалко, конечно, что канал не очень многочисленный, и проголосвали далеко не все. Т.е. понятно, что это не статистика не разу. Но всё равно любопытно.
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥2🗿2
Вообще, надо разделять использование ИИ-агентов в стиле "чистый вайб-кодинг" и в стиле "проверяю код и отвечаю за него".
Потому что все применения чистого вайбкодинга далёкими от технического понимания происходящего людьми - это пока что "ааа! смотрите, я сделал прототип" или "ааа! смотрите, я сделал лендинг". Это охрененно круто, серьёзно, но пока что серьёзных штук с долгосрочной поддержкой вроде бы нет, или я о них не слышал.
Вообще, с трудом могу представить условную домохозяйку, которая будет чинить баги на проде из серии "сообщения из NATS не успевают разгребаться" или "postgres иногда подтормаживает по утрам". Или балансы неправильно посчитались, и надо разобраться, пофиксить и доначислить. "Эй, claude, разберись с багом и доначисли балансы, кому надо".
И совсем другое дело, когда опытный программист использует агента для многократного ускорения, особенно тех частей, где всё примерно понятно, и надо просто прописать код, с тестами и доками. Или даже полностью отдавать агенту задачу, но по частям и потом проверять результат.
На моей практике ошибки случаются, и довольно часто. Это или какой-то оверинжиниринг (обмазало мьютексами однопоточое приложение) или затаскивает какие-то странные технологии. Или (редко) галлюцинирует. Или просто немного неправильно поняло, что вообще надо сделать. Или делает слишком большие или сложные куски кода. И это, сука, как снежный ком. Даже если внимательно смотреть, в код иногда просачивается какое-то говно. А если это делает расслабленный укурок с помощью одного промпта, то проще поставить в казино, чем пилить стартап, - больше шансов на успех
Короче, я считаю, что домохозяйка-кодер - это пока что даже близко не реальность, что бы там ни говорили ребята из Антропика и OpenAI. А программист с многократным ИИ-ускорителем - это уже точно сегодняшний день. Но вайб-кодингом это не назвать.
Потому что все применения чистого вайбкодинга далёкими от технического понимания происходящего людьми - это пока что "ааа! смотрите, я сделал прототип" или "ааа! смотрите, я сделал лендинг". Это охрененно круто, серьёзно, но пока что серьёзных штук с долгосрочной поддержкой вроде бы нет, или я о них не слышал.
Вообще, с трудом могу представить условную домохозяйку, которая будет чинить баги на проде из серии "сообщения из NATS не успевают разгребаться" или "postgres иногда подтормаживает по утрам". Или балансы неправильно посчитались, и надо разобраться, пофиксить и доначислить. "Эй, claude, разберись с багом и доначисли балансы, кому надо".
И совсем другое дело, когда опытный программист использует агента для многократного ускорения, особенно тех частей, где всё примерно понятно, и надо просто прописать код, с тестами и доками. Или даже полностью отдавать агенту задачу, но по частям и потом проверять результат.
На моей практике ошибки случаются, и довольно часто. Это или какой-то оверинжиниринг (обмазало мьютексами однопоточое приложение) или затаскивает какие-то странные технологии. Или (редко) галлюцинирует. Или просто немного неправильно поняло, что вообще надо сделать. Или делает слишком большие или сложные куски кода. И это, сука, как снежный ком. Даже если внимательно смотреть, в код иногда просачивается какое-то говно. А если это делает расслабленный укурок с помощью одного промпта, то проще поставить в казино, чем пилить стартап, - больше шансов на успех
Короче, я считаю, что домохозяйка-кодер - это пока что даже близко не реальность, что бы там ни говорили ребята из Антропика и OpenAI. А программист с многократным ИИ-ускорителем - это уже точно сегодняшний день. Но вайб-кодингом это не назвать.
💯41❤4👍1
Господи свят, теперь даже в консольный докер впилили AI
Пишешь
Пишешь
docker ai, и потом просто русским текстом пишешь, что тебе нужно, например "удали старые имиджи, которые не используются". И он делает там какие-то свои докерные команды, типа docker image prune с нужными параметрами🤯31😁19🤣10🗿3❤2🔥1
P.S. Ждём, когда с кубером можно будет поговорить. Не надо этих конфигов, хельмов всяких. Просто говоришь ему "там чё-то прод упал, почини". Или просто "сделай заебись". И ждёшь
🤩39😁11🔥5😎1
Программист - это мешок угля. По крайней мере, я на это надеюсь.
В тыща семьсот каком-то году Уатт сильно усовершенствовал паровой двигатель, он стал намного эффективнее, и потребление топлива на единицу мощности сильно снизилось. Все современники ожидали постепенного падения цен на уголь - и правда, нафига теперь столько угля.
Однако выяснилось, что произошло ровно наоборот. Об этом написал Джевонс, в честь которого и назвали этот парадокс.
"Изобретение Уатта сделало уголь намного более выгодным источником энергии, что привело к широкому применению паровых машин в промышленности. Это, в свою очередь привело к росту потребления угля, хотя потребность в угле для отдельной машины и снизилась. На основании этого наблюдения Джевонс утверждал, что увеличение эффективности использования топлива имеет тенденцию увеличивать, а не снижать общее его подтребление".
Потом еще экономисты подметили, что помимо всего прочего, повышение производительности ускоряет экономический рост, дополнительно увеличивая спрос на ресурс.
В общем, если программист - это как мешок угля, то согласно парадоксу Джевонса, повышение эффективности программистов с помощью ИИ может привести к тому, что программисты будут востребованы еще больше.
Это при условии, конечно, что технологии не разовьются настолько, что домохозяйка сможет написать сложную систему (банк там или биржу) за 5 минут, но пока что до этого далеко.
В тыща семьсот каком-то году Уатт сильно усовершенствовал паровой двигатель, он стал намного эффективнее, и потребление топлива на единицу мощности сильно снизилось. Все современники ожидали постепенного падения цен на уголь - и правда, нафига теперь столько угля.
Однако выяснилось, что произошло ровно наоборот. Об этом написал Джевонс, в честь которого и назвали этот парадокс.
"Изобретение Уатта сделало уголь намного более выгодным источником энергии, что привело к широкому применению паровых машин в промышленности. Это, в свою очередь привело к росту потребления угля, хотя потребность в угле для отдельной машины и снизилась. На основании этого наблюдения Джевонс утверждал, что увеличение эффективности использования топлива имеет тенденцию увеличивать, а не снижать общее его подтребление".
Потом еще экономисты подметили, что помимо всего прочего, повышение производительности ускоряет экономический рост, дополнительно увеличивая спрос на ресурс.
В общем, если программист - это как мешок угля, то согласно парадоксу Джевонса, повышение эффективности программистов с помощью ИИ может привести к тому, что программисты будут востребованы еще больше.
Это при условии, конечно, что технологии не разовьются настолько, что домохозяйка сможет написать сложную систему (банк там или биржу) за 5 минут, но пока что до этого далеко.
🔥20👍15❤3🥴1
Forwarded from Голландский Rust-ист
Исходный код Claude был слит в сеть через source map в их npm пакете.
Вайб есть - приватности нет.
Ребята запушили source map файл в npm пакет @anthropic-ai/claude-code (заметил Chaofan Shou). 59,8 мб файл.
С помощью него можно восстановить исходники в оригинальном состоянии, уже есть на GitHub:
• Репо 1
• Репо 2
Голландский Rust-ист - канал о веб разработке
Вайб есть - приватности нет.
Ребята запушили source map файл в npm пакет @anthropic-ai/claude-code (заметил Chaofan Shou). 59,8 мб файл.
С помощью него можно восстановить исходники в оригинальном состоянии, уже есть на GitHub:
• Репо 1
• Репо 2
Голландский Rust-ист - канал о веб разработке
🔥13
Рубрика "помогаю друзьям найти работу". Великий интернет, откликнись
Есть один правильный пацан Теймур, фронтендер с 2020 года. Опыт реальный, не накрученный, что сейчас важно. Помимо всего прочего волонтёрил фронтом на проекте "Лиза Алерт" (!)
Что умеет (цитата из резюме):
"Основной стек — React, TypeScript,
JavaScript; разрабатываю корпоративные платформы, административные интерфейсы и
сложные SPA с интеграцией по REST API. Работал с архитектурой frontend-модулей,
производительностью, тестированием, CI/CD, сложными формами, аналитикой и
legacy-рефакторингом. Помимо frontend-задач, интересуюсь смежными инженерными
областями: автоматизацией, backend-интеграциями, Python и AI-инструментами."
Удалёнка
В общем, время сейчас дурное, нужна помощь зала. За найм пожму виртуальную руку. За репост знакомым/эйчарам мысленно поставлю лайк. Даже два
Кто не наймёт, тот дурак
Пишите ему сразу напрямую в тг - @yellow_ears
Есть один правильный пацан Теймур, фронтендер с 2020 года. Опыт реальный, не накрученный, что сейчас важно. Помимо всего прочего волонтёрил фронтом на проекте "Лиза Алерт" (!)
Что умеет (цитата из резюме):
"Основной стек — React, TypeScript,
JavaScript; разрабатываю корпоративные платформы, административные интерфейсы и
сложные SPA с интеграцией по REST API. Работал с архитектурой frontend-модулей,
производительностью, тестированием, CI/CD, сложными формами, аналитикой и
legacy-рефакторингом. Помимо frontend-задач, интересуюсь смежными инженерными
областями: автоматизацией, backend-интеграциями, Python и AI-инструментами."
Удалёнка
В общем, время сейчас дурное, нужна помощь зала. За найм пожму виртуальную руку. За репост знакомым/эйчарам мысленно поставлю лайк. Даже два
Пишите ему сразу напрямую в тг - @yellow_ears
1👍17❤10🥱2
Когда пишешь код агентом, даже если тщательно смотрел код и, допустим, просил что-то исправить, то есть погрузился - это вообще не тоже самое, что писать код самому. Когда пишешь всё сам - это как-то лучше прошивается в мозгу.
И вот, когда надо найти ошибку на проде - тратишь время на то, чтобы разобраться в каких-то деталях. Это как будто код писал коллега, который ушел в отпуск за день до релиза. Т.е. ты ревьювил, обсуждал и вроде в курсе происходящего, но блин.
Кроме того, если просить саму LLM помочь с поиском проблем, выясняется, что теперь уже у нейронки не хватает контекста о проекте в целом и его нюансах. А объяснять времени нет.
В итоге поиск проблем превращается в нервотрёпку.
А как у вас?
И вот, когда надо найти ошибку на проде - тратишь время на то, чтобы разобраться в каких-то деталях. Это как будто код писал коллега, который ушел в отпуск за день до релиза. Т.е. ты ревьювил, обсуждал и вроде в курсе происходящего, но блин.
Кроме того, если просить саму LLM помочь с поиском проблем, выясняется, что теперь уже у нейронки не хватает контекста о проекте в целом и его нюансах. А объяснять времени нет.
В итоге поиск проблем превращается в нервотрёпку.
А как у вас?
💯56👍10👎1
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Тимлид как громоотвод для чужой неэффективности
Прочитал недавний пост Сережи Щербинина про то, как сверху вниз в тимлидов стекает хаос, а им это сливать некуда и надо превратить субстанцию в конфету https://t.me/bvevvs/1358
Я должен сделать дисклеймер, что я (да и он) не утверждаю, что это всегда так и там наверху бестолковые сидят, а одни тимлиды — соль земли и всех спасают. Нет, нередко бывает, что тимлиды сами с менеджментом своей команды не справляются даже при благополучных внешних условиях.
Однако как же мне понравилась цитата:
«Во многом именно поэтому слой маленьких руководителей в крупных системах так быстро выгорает. Не потому что они слабее других и не потому что им рано дали ответственность. А потому что на них очень удобно складывать всё то, что компания не хочет чинить у себя в конструкции. Пока наверху обсуждают зрелость процессов, синергию функций и качество управления изменениями, где-то внизу конкретный тимлид в очередной раз пытается сделать так, чтобы команда просто могла нормально работать.»
Ставь 💯, если узнал в этом тимлиде себя или товарища.
Ставь ⚡️, если ты сам складываешь всё подряд в тимлидов, ведь это и правда удобно.
Ставь 😱, если в тебя самого уже столько напихали сверху, что ты не складываешь в тимлидов, а оно само выпадает.
Прочитал недавний пост Сережи Щербинина про то, как сверху вниз в тимлидов стекает хаос, а им это сливать некуда и надо превратить субстанцию в конфету https://t.me/bvevvs/1358
Я должен сделать дисклеймер, что я (да и он) не утверждаю, что это всегда так и там наверху бестолковые сидят, а одни тимлиды — соль земли и всех спасают. Нет, нередко бывает, что тимлиды сами с менеджментом своей команды не справляются даже при благополучных внешних условиях.
Однако как же мне понравилась цитата:
«Во многом именно поэтому слой маленьких руководителей в крупных системах так быстро выгорает. Не потому что они слабее других и не потому что им рано дали ответственность. А потому что на них очень удобно складывать всё то, что компания не хочет чинить у себя в конструкции. Пока наверху обсуждают зрелость процессов, синергию функций и качество управления изменениями, где-то внизу конкретный тимлид в очередной раз пытается сделать так, чтобы команда просто могла нормально работать.»
Ставь 💯, если узнал в этом тимлиде себя или товарища.
Ставь ⚡️, если ты сам складываешь всё подряд в тимлидов, ведь это и правда удобно.
Ставь 😱, если в тебя самого уже столько напихали сверху, что ты не складываешь в тимлидов, а оно само выпадает.
Telegram
#безвотэтоговотвсего
Тимлид как громоотвод для чужой неэффективности
Одна из самых невеселых ролей в очень больших компаниях - это маленький тимлид, на которого в какой-то момент начинает стекаться вообще все, что система не смогла нормально решить сама. Снаружи это редко так…
Одна из самых невеселых ролей в очень больших компаниях - это маленький тимлид, на которого в какой-то момент начинает стекаться вообще все, что система не смогла нормально решить сама. Снаружи это редко так…
💯29😱1
Капец, блин. Мороженка тестирования.
Вы наверняка слышали про пирамиду тестирования. Самые прошаренные слышали про кубок тестирования.
Но, держу пари, вы никогда не слышали про
• мороженку тестирования
• вулкан
• песочные часы
• соту
и т.д.
Тут можно посмотреть
Короче, имхо не надо вообще забивать себе голову этой хренью. Всё просто: e2e - это дорого и медленно, но тестирует прям конкретно реальность. Unit-тесты быстрые и дешевые, но мало проверяют и часто выкидываются при рефакторинге. Интеграционные тесты где-то посередине.
И при разработке надо найти баланс, в каждой ситуации он тупо свой. Имхо просто не надо следовать какой-то дебильной форме, которую кто-то пытался высосать из пальца, изо всех сил делая умное лицо
🫥 Cross Join - канал о разработке
⠀
Вы наверняка слышали про пирамиду тестирования. Самые прошаренные слышали про кубок тестирования.
Но, держу пари, вы никогда не слышали про
• мороженку тестирования
• вулкан
• песочные часы
• соту
и т.д.
Тут можно посмотреть
Короче, имхо не надо вообще забивать себе голову этой хренью. Всё просто: e2e - это дорого и медленно, но тестирует прям конкретно реальность. Unit-тесты быстрые и дешевые, но мало проверяют и часто выкидываются при рефакторинге. Интеграционные тесты где-то посередине.
И при разработке надо найти баланс, в каждой ситуации он тупо свой. Имхо просто не надо следовать какой-то дебильной форме, которую кто-то пытался высосать из пальца, изо всех сил делая умное лицо
⠀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12😁6💯4❤1
Forwarded from do...while...ai (Gregory is typing...)
Вайбкодинг продакш-решений не для всех
Наконец-то я услышал от мэтров (в данном случае — самих Антропиков) смелое заявление, что вайб-кодинг — это, в общем-то, не для всех. Особенно, когда речь идёт о production-grade системах.
То есть если ты настоящий разработчик — это нормально делать прод-решение. А если ты...ну, скажем, вафелька, то, в принципе, ты можешь вайб-кодить, но не нужно обманывать себя и других тем, что ты трушный разработчик (что бы это ни значило). Причем, докладчик четко объясняет почему так: не будучи доменным экспертом ты просто не сможешь задать правильные вопросы, чтобы получить правильные ответы и результаты. Это, кстати, касается всего, что связано сейчас с AI.
Но здесь есть несколько оговорок:
1) При должном усердии и старании (и задавании правильных вопросов для самообучения) люди смогут прокачаться как разработчики, то есть стать ими. По мне так вайб-кодить — это как читать Stack Overflow на скорости 30x.
2) Абсолютно нормально делать "не production-grade" тулзы, всякие автоматизации вокруг своей жизни и других людей, ассистентов и прочих телеграм-ботов. Просто нужно, чтобы все пользователи понимали и оценивали потенциальные риски.
Сам доклад здесь: https://youtu.be/fHWFF_pnqDk?is=omcRDEePMgq210up
Выступлению, оказывается, уже 8 месяцев, что по меркам сегодняшних скоростей — это "средневековье". Но я с удовольствием послушал его от начала до конца (без суммаризаций и вот этих вот всех NotebookLM).
Наконец-то я услышал от мэтров (в данном случае — самих Антропиков) смелое заявление, что вайб-кодинг — это, в общем-то, не для всех. Особенно, когда речь идёт о production-grade системах.
То есть если ты настоящий разработчик — это нормально делать прод-решение. А если ты...ну, скажем, вафелька, то, в принципе, ты можешь вайб-кодить, но не нужно обманывать себя и других тем, что ты трушный разработчик (что бы это ни значило). Причем, докладчик четко объясняет почему так: не будучи доменным экспертом ты просто не сможешь задать правильные вопросы, чтобы получить правильные ответы и результаты. Это, кстати, касается всего, что связано сейчас с AI.
Но здесь есть несколько оговорок:
1) При должном усердии и старании (и задавании правильных вопросов для самообучения) люди смогут прокачаться как разработчики, то есть стать ими. По мне так вайб-кодить — это как читать Stack Overflow на скорости 30x.
2) Абсолютно нормально делать "не production-grade" тулзы, всякие автоматизации вокруг своей жизни и других людей, ассистентов и прочих телеграм-ботов. Просто нужно, чтобы все пользователи понимали и оценивали потенциальные риски.
Сам доклад здесь: https://youtu.be/fHWFF_pnqDk?is=omcRDEePMgq210up
Выступлению, оказывается, уже 8 месяцев, что по меркам сегодняшних скоростей — это "средневековье". Но я с удовольствием послушал его от начала до конца (без суммаризаций и вот этих вот всех NotebookLM).
YouTube
Vibe coding in prod | Code w/ Claude
Presented at Code w/ Claude by @anthropic-ai on May 22, 2025 in San Francisco, CA, USA.
Speakers:
Erik Schulntz, Member of Technical Staff at @anthropic-ai
Speakers:
Erik Schulntz, Member of Technical Staff at @anthropic-ai
👍14❤5
Провалы вайб-кодинга
Подборка задокументированных случаев, когда ПО, написанное с помощью ИИ, давало сбои в боевых условиях. Каждый случай подкреплён ссылкой на источник.
https://crackr.dev/vibe-coding-failures
P.S. люди, правда, тоже роняют прод ещё как :)
Подборка задокументированных случаев, когда ПО, написанное с помощью ИИ, давало сбои в боевых условиях. Каждый случай подкреплён ссылкой на источник.
https://crackr.dev/vibe-coding-failures
P.S. люди, правда, тоже роняют прод ещё как :)
crackr.dev
Vibe Coding Failures: Documented AI Code Incidents
A curated directory of real-world incidents where AI-generated code failed in production.
😁10👍3🔥3