Я из того типа людей, которые могут иметь одни и те же обои на компьютере годами (и да, они мне не надоедают!)
Прошлые мои обои красовались на моем и рабочем ноутбуках 5 лет подряд, КАРЛ!
Сегодня настало время их сменить. Однако теперь новые обои — моя собственная работа! От этого вдвойне приятнее.
⬇️ Ниже делюсь ими с вами. ⬇️
Пусть и вас радуют.
Прошлые мои обои красовались на моем и рабочем ноутбуках 5 лет подряд, КАРЛ!
Сегодня настало время их сменить. Однако теперь новые обои — моя собственная работа! От этого вдвойне приятнее.
Пусть и вас радуют.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍5⚡3❤3😱1
5 ошибок из-за которых не получают оффер
Всем доброго времени суток!
Мне недавно пришлось искать стажера в свою команду. Последний раз стажера нанимал года 3 назад. В этот раз осталось противоречивое впечатление. Казалось бы: рынок найма сейчас на низах, вакансий мало, людей много, конкуренция среди кандидатов большая. Такие условия должны привести к повышению качества hard-skills и уровню подготовки (привет инфляция навыков). Но, к сожалению, многие ведут себя так, как лет 5 назад, когда при дефиците кадров брали всех подряд без разбора.
Я выделил 5 распространенных ошибок кандидатов уровня inter/junior/middle, из-за которых их не взяли.
Универсальное CV.
Кандидат отправляет одно и тоже резюме на разные вакансии не адаптируя его (например у него написано, что есть опыт Java разработки, однако подается он на go-разработку или на тестировщика. А в резюме про это ни слова!). В 2026 году 90% откликов и резюме в больших компаниях проходят отбор сначала через ML. Несовпадение резюме и отклика на вакансию уменьшают шанс рассмотрения кандидата. Но даже после прохождения ML отбора, если правильно не расставить акценты и не выделить ключевые достижения/навыки/технологии/фреймворки, интересующие нанимающего менеджер, резюме будет просто проигнорировано.
Медленный коддинг и незнание синтаксиса языка.
В 2026 году требования к стажерам/джунам более жесткие чем 5 лет назад: никто не собирается учить писать код. Этому учат в университете, на курсах, или самостоятельно. Придти на собеседование по python и не знать как объявить класс или придти на go разработку и не суметь дождаться ответа из горутины — red flag, после которого дальше разговаривать не будут. Сейчас надо владеть языком программирования и уметь на нем писать код быстро! Если не хватает практики — ищите ее сами: leetcode, opensource, pet проекты, … Набивайте руку!
Не подготовиться к собеседованию.
Понятно, что нельзя быть готовым ко всему, но как правило вопросы на собеседование вытекают из описания вакансии и технологий, с которыми придется работать. Пару видео на ютубе и статей закрывают 80% вопросов. Однако кандидаты пытаются выехать «на харизме».
Несистемный подход.
Что я имею ввиду — собеседование это не экзамен в университете. Интервьюеру не так важен правильный ответ, как увидеть ход мыслей кандидата, подход к решению задачи/вопроса, увидеть как он справляется. Лучше проговаривать в слух мысли, чем молчать и потом давать отрывистые несвязанные ответы. Если у кандидата в голове каша, то и решения будут примерно такие же.
Наконец моя «любимая рубрика» — фродеры.
Я честно не знаю, что у этих людей в голове, и на что они рассчитывают. Может быть они себе представляют это как идеальный план как всех провести, но на практике это выглядит просто ужасно… Когда кандидат выдает ответ из нейронки, а потом не может его объяснить… Мало того, что они отнимают время на интервью, так еще и подрывают свою репутацию навсегда! Компания вносит таких людей в черный список (да-да, есть такие списки), и, скорее всего, в будущем HR даже не будут разговаривать с ними. А с учетом того, что Big Tech компаний в России не так уж и много, податься потом будет некуда…
Несмотря на непростое время, сейчас хорошему кандидату с должным уровнем подготовки попасть в IT не труднее чем 5 лет назад. Главное будьте честными:)
Всем доброго времени суток!
Мне недавно пришлось искать стажера в свою команду. Последний раз стажера нанимал года 3 назад. В этот раз осталось противоречивое впечатление. Казалось бы: рынок найма сейчас на низах, вакансий мало, людей много, конкуренция среди кандидатов большая. Такие условия должны привести к повышению качества hard-skills и уровню подготовки (привет инфляция навыков). Но, к сожалению, многие ведут себя так, как лет 5 назад, когда при дефиците кадров брали всех подряд без разбора.
Я выделил 5 распространенных ошибок кандидатов уровня inter/junior/middle, из-за которых их не взяли.
Универсальное CV.
Кандидат отправляет одно и тоже резюме на разные вакансии не адаптируя его (например у него написано, что есть опыт Java разработки, однако подается он на go-разработку или на тестировщика. А в резюме про это ни слова!). В 2026 году 90% откликов и резюме в больших компаниях проходят отбор сначала через ML. Несовпадение резюме и отклика на вакансию уменьшают шанс рассмотрения кандидата. Но даже после прохождения ML отбора, если правильно не расставить акценты и не выделить ключевые достижения/навыки/технологии/фреймворки, интересующие нанимающего менеджер, резюме будет просто проигнорировано.
Медленный коддинг и незнание синтаксиса языка.
В 2026 году требования к стажерам/джунам более жесткие чем 5 лет назад: никто не собирается учить писать код. Этому учат в университете, на курсах, или самостоятельно. Придти на собеседование по python и не знать как объявить класс или придти на go разработку и не суметь дождаться ответа из горутины — red flag, после которого дальше разговаривать не будут. Сейчас надо владеть языком программирования и уметь на нем писать код быстро! Если не хватает практики — ищите ее сами: leetcode, opensource, pet проекты, … Набивайте руку!
Не подготовиться к собеседованию.
Понятно, что нельзя быть готовым ко всему, но как правило вопросы на собеседование вытекают из описания вакансии и технологий, с которыми придется работать. Пару видео на ютубе и статей закрывают 80% вопросов. Однако кандидаты пытаются выехать «на харизме».
Несистемный подход.
Что я имею ввиду — собеседование это не экзамен в университете. Интервьюеру не так важен правильный ответ, как увидеть ход мыслей кандидата, подход к решению задачи/вопроса, увидеть как он справляется. Лучше проговаривать в слух мысли, чем молчать и потом давать отрывистые несвязанные ответы. Если у кандидата в голове каша, то и решения будут примерно такие же.
Наконец моя «любимая рубрика» — фродеры.
Я честно не знаю, что у этих людей в голове, и на что они рассчитывают. Может быть они себе представляют это как идеальный план как всех провести, но на практике это выглядит просто ужасно… Когда кандидат выдает ответ из нейронки, а потом не может его объяснить… Мало того, что они отнимают время на интервью, так еще и подрывают свою репутацию навсегда! Компания вносит таких людей в черный список (да-да, есть такие списки), и, скорее всего, в будущем HR даже не будут разговаривать с ними. А с учетом того, что Big Tech компаний в России не так уж и много, податься потом будет некуда…
Несмотря на непростое время, сейчас хорошему кандидату с должным уровнем подготовки попасть в IT не труднее чем 5 лет назад. Главное будьте честными:)
❤9💯9🔥3🤡3👍2⚡1👀1
Решил, что в моем курсе по Go тема gRPC недостаточно подробно раскрыта, так как эта тема довольно большая. Сделал отдельный курс, посвященный исключительно gRPC и Protobuf. В него лег мой личный опыт работы с gRPC на протяжении 5 лет.
К тому же, как оказалось, многие Go-разработчки все еще обходят gRPC стороной со словами: "Ой там сложно все и непонятно с этим protoc... Я лучше на REST API Gin сервер подниму". Постарался разрушить миф о сложности работы с gRPC и снизить порог входа. Курс будет полезен тем, кто еще не работал с gRPC, а также тем, кто уже с ним работает, но чувствует, что не выжимает из него максимум.
Модули про Protobuf бесплатные!
Please open Telegram to view this post
VIEW IN TELEGRAM
Stepik: online education
Leoscode! gRPC в Go — от протоколов до production
Этот курс — системное погружение в gRPC и Protobuf на Go. Вместе мы пройдем путь от эволюции API до реализации unary и streaming RPC.
Разберем генерацию кода, устройство серверов и клиентов. Узнаем какие инструменты сейчас принято использовать, какие фишки…
Разберем генерацию кода, устройство серверов и клиентов. Узнаем какие инструменты сейчас принято использовать, какие фишки…
🔥19👍8❤3🏆1
Люблю хардкорные статьи по устройству Go под капотом.
Недавно нашел реально классную статью по аллокациям памяти в Go. А сегодня вышел ее перевод на Habr.
Пополнил свою коллекцию еще одной ссылкой😁
Недавно нашел реально классную статью по аллокациям памяти в Go. А сегодня вышел ее перевод на Habr.
Пополнил свою коллекцию еще одной ссылкой😁
Хабр
Выделение памяти в Go
Эта статья посвящена языку программирования Go 1.24 , работающему на Linux на архитектуре ARM . Она может не охватывать специфические для других операционных систем (ОС) или аппаратных архитектур...
🔥13👍4
За это время столько всего произошло: встретил множество интересных людей, некоторых из них уже нет в Ozon, а некоторые в других командах/отделах. А я с ностальгией вспоминаю, как мы собирались в баре и обсуждали разные истории из нашей повседневной работы, как затаскивали проекты, которые казались «невозможными».
При мне Ozon кратно вырос и многое что поменялось внутри. Жаль я не смог придти еще на пару годиков раньше😅
Это были невероятно долгие и насыщенные 5 лет с одной стороны, и при этом они как-будто пролетели незаметно…
В самом начале я был уверен, что не задержусь в Ozon более чем на 2 года, а теперь я не знаю, а где может быть лучше..?
Некоторые скажут, что 5 лет не много: вот мол люди по 20-30 лет на одном заводе работали… Но мне кажется, что в современных реалиях это много.
А вы сколько уже работаете в текущей компании?
P.S. фото сделано ровно 5 лет назад после первого рабочего дня в офисе
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18🎉7🆒3👍2
Protobuf & Edition
После долгих лет стабильности proto3 protobuf наконец-то сменил парадигму и перешёл на Edition — набор настраиваемых фич. Теперь новые возможности можно добавлять эволюционно, не ломая обратную совместимость. А это значит, что теперь начнут активно появляться новые фичи protobuf (я на это надеюсь).
А вот
- field_presence — настраиваемая модель поведения, позволяет контролировать, было ли поле действительно задано или нет (теперь optional не нужны получается); (с 2023 уже работает)
- enforce_naming_style — позволяет валидировать имена полей, сообщений и перечислений в .proto-схемах по единому стилю: код даже не сгенерируется, если названия не по канону (теперь не получится игнорировать линтеры);
- default_symbol_visibility — задаёт видимость сообщений/перечислений, позволяя точнее контролировать, что именно экспортируется наружу, а что остаётся внутренней деталью схемы; Капец какая нужная фича в больших API!
- Opaque API в Go — сгенерированные protobuf-сообщения перестают быть «раскрытыми» структурами с публичными полями и превращаются в более закрытый API. Opaque API отвязывает код пользователя от внутреннего устройства сгенерированного кода. А это значит, что protobuf runtime и protogen могут дальше развиваться, оптимизировать все подряд, не ломая при этом пользовательский код (и они уже это сделали).
Звучит все здорово, но для внедрения в production меня останавливают две вещи:
1. Руками править сотни proto файлов — занятие неблагодарное. Парни из Google обещали сделать утилиту для миграции на edition — prototiller, но её так и нет :) AI в целом с нормальным промтом справляется, но хотелось бы официальной утилиты.
2. Для работы с proto в production я использую Buf, который все еще не поддерживает edition 2024. Парни там обещают скоро добавить поддержку, но официальной даты релиза нет…
Локально я с этим поигрался, жду впервую очередь поддержку в Buf. Уже сейчас можно мигрировать на edition 2023, сохранив обратную совместимость (добиться того же поведения, что и в proto2/proto3 и подготовится к переходу на 2024).
После долгих лет стабильности proto3 protobuf наконец-то сменил парадигму и перешёл на Edition — набор настраиваемых фич. Теперь новые возможности можно добавлять эволюционно, не ломая обратную совместимость. А это значит, что теперь начнут активно появляться новые фичи protobuf (я на это надеюсь).
Edition 2023 — это просто разделение фичей proto2 и proto3 с возможностью настройки их глобально или локально (для конкретного сообщения/поля).А вот
Edition 2024 уже приносит несколько важных изменений:- field_presence — настраиваемая модель поведения, позволяет контролировать, было ли поле действительно задано или нет (теперь optional не нужны получается); (с 2023 уже работает)
- enforce_naming_style — позволяет валидировать имена полей, сообщений и перечислений в .proto-схемах по единому стилю: код даже не сгенерируется, если названия не по канону (теперь не получится игнорировать линтеры);
- default_symbol_visibility — задаёт видимость сообщений/перечислений, позволяя точнее контролировать, что именно экспортируется наружу, а что остаётся внутренней деталью схемы; Капец какая нужная фича в больших API!
- Opaque API в Go — сгенерированные protobuf-сообщения перестают быть «раскрытыми» структурами с публичными полями и превращаются в более закрытый API. Opaque API отвязывает код пользователя от внутреннего устройства сгенерированного кода. А это значит, что protobuf runtime и protogen могут дальше развиваться, оптимизировать все подряд, не ломая при этом пользовательский код (и они уже это сделали).
Звучит все здорово, но для внедрения в production меня останавливают две вещи:
1. Руками править сотни proto файлов — занятие неблагодарное. Парни из Google обещали сделать утилиту для миграции на edition — prototiller, но её так и нет :) AI в целом с нормальным промтом справляется, но хотелось бы официальной утилиты.
2. Для работы с proto в production я использую Buf, который все еще не поддерживает edition 2024. Парни там обещают скоро добавить поддержку, но официальной даты релиза нет…
Локально я с этим поигрался, жду впервую очередь поддержку в Buf. Уже сейчас можно мигрировать на edition 2023, сохранив обратную совместимость (добиться того же поведения, что и в proto2/proto3 и подготовится к переходу на 2024).
🔥5❤3👍3🆒2
🌍 Мир становится многополярным, а это значит, что надо становиться многоканальным.
Я очень трепетно отношусь к своем каналу, честно. Каждый пост здесь — это частичка моей души и вдохновения. На поток такое тяжело поставить...
Мне бы очень не хотелось потерять своих дорогих подписчиков, если вдруг ИНТЕРНЕТ все же станет ИНТРАНЕТОМ😐 .
В общем, я завел канал в...🥁
💙 https://vk.com/leoscode
Подписывайтесь, будем на связи!
Я очень трепетно отношусь к своем каналу, честно. Каждый пост здесь — это частичка моей души и вдохновения. На поток такое тяжело поставить...
Мне бы очень не хотелось потерять своих дорогих подписчиков, если вдруг ИНТЕРНЕТ все же станет ИНТРАНЕТОМ
В общем, я завел канал в...
Подписывайтесь, будем на связи!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14😢6🤡5🔥3🆒2👍1😁1👨💻1
НАПИСАНИЕ HIGHLOAD СЕРВИСОВ ОСТАВЛЯЕТ СЛЕД...
2 года я проектировал сервисы на Go, которые должны были держать 200k+ RPS и иметь время ответа менее 50ms в 99p.
При таких условиях недостаточно написать просто рабочий код, он должен быть потреблять как можно меньше ресурсов. В общем, вырабатывается привычка экономить «каждый байт и аллокацию».
На другом проекте (не highload) как-то раз мне попадает на код ревью MR. В глаза сразу бросается стандартное преобразование слайса байт в строку:
Я сразу пишу в комментариях: «тут можно сделать дешевое преобразование через unsafe»
Разработчик отвечает: «а как это сделать и зачем?»
И тут я понял сразу 2 вещи:
Во-первых далеко не все Go-разработчики работали с unsafe (оно и понятно, не все разрабатывают highload-решения).
Во-вторых, разработчик задал верный вопрос: «Зачем?». Действительно, преждевременные оптимизации скорее мешают, чем помогают. Тем более в сервисе с 1-5 rps…
В общем, свою привычку "оптимизировать все сразу" я отбросил. Но мне все не давало покоя, что какие-то хаки остаются скрытыми от публичных глаз…
Поделюсь одним из неочевидных здесь👉
В Go на каждую аллокацию в куче вызывается функция mallocgc, которая имеет определенную скрытую от наших глаз логику. Когда в одном цикле мы выделяем 1000+ объектов, overhead от mallocgc становится заметным...
Хорошо, а есть более прозрачный способ решить проблему с множеством аллокаций? Да, начиная с версии Go 1.20 появились арены (но все еще как экспериментальная фича):
В итоге такой Hack-аллокатор даже без unsafe дает буст...
P.S. Про unsafe рассказываю на курсе в своем бесплатном уроке
2 года я проектировал сервисы на Go, которые должны были держать 200k+ RPS и иметь время ответа менее 50ms в 99p.
При таких условиях недостаточно написать просто рабочий код, он должен быть потреблять как можно меньше ресурсов. В общем, вырабатывается привычка экономить «каждый байт и аллокацию».
На другом проекте (не highload) как-то раз мне попадает на код ревью MR. В глаза сразу бросается стандартное преобразование слайса байт в строку:
str := string(bytes)
Я сразу пишу в комментариях: «тут можно сделать дешевое преобразование через unsafe»
Разработчик отвечает: «а как это сделать и зачем?»
И тут я понял сразу 2 вещи:
Во-первых далеко не все Go-разработчики работали с unsafe (оно и понятно, не все разрабатывают highload-решения).
Во-вторых, разработчик задал верный вопрос: «Зачем?». Действительно, преждевременные оптимизации скорее мешают, чем помогают. Тем более в сервисе с 1-5 rps…
В общем, свою привычку "оптимизировать все сразу" я отбросил. Но мне все не давало покоя, что какие-то хаки остаются скрытыми от публичных глаз…
Поделюсь одним из неочевидных здесь
В Go на каждую аллокацию в куче вызывается функция mallocgc, которая имеет определенную скрытую от наших глаз логику. Когда в одном цикле мы выделяем 1000+ объектов, overhead от mallocgc становится заметным...
type MyStruct struct {
someFields [64]byte
Value bool
}
func simpleAllocate(n int) []*MyStruct {
result := make([]*MyStruct, 0, n)
for range n {
result = append(result, &MyStruct{Value: true})
}
return result
}BenchmarkAllocate/100/Simple-10 655094 1872 ns/op 8896 B/op 101 allocs/op
BenchmarkAllocate/1000/Simple-10 67028 18604 ns/op 88192 B/op 1001 allocs/op
BenchmarkAllocate/10000/Simple-10 5565 201100 ns/op 881925 B/op 10001 allocs/op
BenchmarkAllocate/100000/Simple-10 526 2377439 ns/op 8802821 B/op 100001 allocs/op
func hackAllocate(n int) []*MyStruct {
var (
result = make([]*MyStruct, n)
resultV = make([]MyStruct, n)
)
for i := range n {
resultV[i].Value = true
result[i] = &resultV[i]
}
return result
}BenchmarkAllocate/100/Hack-10 1657069 754.9 ns/op 7424 B/op 2 allocs/op
BenchmarkAllocate/1000/Hack-10 162456 7304 ns/op 73728 B/op 2 allocs/op
BenchmarkAllocate/10000/Hack-10 17347 70141 ns/op 737284 B/op 2 allocs/op
BenchmarkAllocate/100000/Hack-10 1492 763791 ns/op 7307279 B/op 2 allocs/op
Хорошо, а есть более прозрачный способ решить проблему с множеством аллокаций? Да, начиная с версии Go 1.20 появились арены (но все еще как экспериментальная фича):
func arenaAllocate(mem *arena.Arena, n int) []*MyStruct {
result := arena.MakeSlice[*MyStruct](mem, n, n)
for i := range n {
s := arena.New[MyStruct](mem)
s.Value = true
result[i] = s
}
return result
}BenchmarkAllocate/10000/Simple-10 6948 161145 ns/op 881920 B/op 10001 allocs/op
BenchmarkAllocate/10000/Hack-10 27702 43448 ns/op 737280 B/op 2 allocs/op
BenchmarkAllocate/10000/Arena-10 4921 219361 ns/op 729991 B/op 2 allocs/op
В итоге такой Hack-аллокатор даже без unsafe дает буст...
P.S. Про unsafe рассказываю на курсе в своем бесплатном уроке
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
go/src/runtime/malloc.go at 07f0c2074c257e7f89a52152f451c66e7f762481 · golang/go
The Go programming language. Contribute to golang/go development by creating an account on GitHub.
👍13🔥6❤3🆒1
Наблюдая год за всей этой историей с AI агентами в разработке понял, что прогресс слишком быстрый и виден на лицо.
Забавный факт из моих наблюдений на работе: Senior+ разработчики, использующие AI агенты в работе выходят на сверх продуктивный уровень генерируя тонны хорошего кода и готовых решений, на которые раньше могли уйти месяцы.
При этом продуктивность разработчиков уровня Junior/Middle использующие AI не изменилась, а вот качество решений как будто хуже, если бы они сами писали… (не говорю что у всех так, но как есть).
Выходит, что AI агенты это именно инструмент. И в руках профессионалов оно генерирует огромный “value”🙂
Решил, что пора тоже втягиваться и начать все это дело изучать. Буду переодически делиться тем, что узнал и использую для обучения.
Сегодняшняя попытка зарегистрировать аккаунт в Claude провалилась об верификацию по номеру телефона… У меня есть зарубежные номера, но они все не подходят. Проблема не у меня одного (issue свежий). Навайбкодили получается😐
Пока что штудирую документацию Claude. Из того что вынес:
- как и у всех LLM — большой контекст проблема. Нужно держать его как можно меньше, используя разные «хаки» с инструкциями, файлами, скилами.
- Claude довольно умная, чтобы самостоятельно решать задачи. Главное — четко и кратко сформулировать цель и дать необходимый контекст и критерии для самостоятельной проверки решения.
В общем, к Claude надо относиться как к новому разработчику в команде и делегировать ему, используя документации и регламенты.
Пошел дальше читать документацию…
Забавный факт из моих наблюдений на работе: Senior+ разработчики, использующие AI агенты в работе выходят на сверх продуктивный уровень генерируя тонны хорошего кода и готовых решений, на которые раньше могли уйти месяцы.
При этом продуктивность разработчиков уровня Junior/Middle использующие AI не изменилась, а вот качество решений как будто хуже, если бы они сами писали… (не говорю что у всех так, но как есть).
Выходит, что AI агенты это именно инструмент. И в руках профессионалов оно генерирует огромный “value”🙂
Решил, что пора тоже втягиваться и начать все это дело изучать. Буду переодически делиться тем, что узнал и использую для обучения.
Сегодняшняя попытка зарегистрировать аккаунт в Claude провалилась об верификацию по номеру телефона… У меня есть зарубежные номера, но они все не подходят. Проблема не у меня одного (issue свежий). Навайбкодили получается
Пока что штудирую документацию Claude. Из того что вынес:
- как и у всех LLM — большой контекст проблема. Нужно держать его как можно меньше, используя разные «хаки» с инструкциями, файлами, скилами.
- Claude довольно умная, чтобы самостоятельно решать задачи. Главное — четко и кратко сформулировать цель и дать необходимый контекст и критерии для самостоятельной проверки решения.
В общем, к Claude надо относиться как к новому разработчику в команде и делегировать ему, используя документации и регламенты.
Пошел дальше читать документацию…
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
[BUG] Phone verification · Issue #34229 · anthropics/claude-code
Preflight Checklist I have searched existing issues and this hasn't been reported yet This is a single bug report (please file separate reports for different bugs) I am using the latest version...
🔥9❤5👍3🆒2
Мой первый удачный опыт вайбкодинга Agent Driven Development
Пока возился с активацией аккаунта Claude, вспомнил, что у меня есть подписка ChatGPT, и решил пока потестировать Codex на реальной задаче.
Взял go-ycsb: нужно было разделить адаптеры для Scylla и Cassandra и обновить драйверы до последних версий (точнее перейти на новые, но не суть). Эту задачу я уже делал сам — потратил около часа, включая погружение в проект. Потом стало интересно: а как с этим справится Codex?
Решил не мелочиться и начать с режима планирования. Сначала попросил его собрать Architecture.md, чтобы модель поняла структуру проекта. Потом, скорее для учебных целей, добавил ещё SKILL brainstorming. И тут был первый приятный сюрприз: нейронка начала задавать очень хорошие уточняющие вопросы, о которых я сам на старте даже не подумал.
Да, для такой простой задачи это уже был overengineering. Но как первый опыт — очень ценный.
Что понравилось больше всего: Codex не ограничился только кодом. Он поправил документацию, сохранил совместимость API, ничего не сломал, прогнал всё в Docker и ещё написал тесты. И вот тут стало особенно интересно, потому что мой собственный вариант был слабее: я не сохранил обратную совместимость и не обновил документацию с интеграционными тестами.
В итоге на всё ушло около полутора часов в спокойном режиме. Если честно сравнивать результаты, то я справился примерно 60-80%, а Codex на все 100% по полноте выполнения задачи.
После этого у меня довольно простой вывод: начинать использовать AI в разработке можно с более простых сценариев — ревью, планирование, архитектурные заметки, документация, проверки на совместимость, актуализация тестов. Это позволит привыкнуть к экосистеме AI агентов и появится понимание как с этим всем работать.
Кстати, у нас в команде мы уже договорились прогонять ревью через AI и сейчас тестируем разные open-source модели. Нейронки правда бывают более дотошными и внимательными, чем человек, особенно в рутинных проверках. Нас они уже несколько раз выручали.
На следующей неделе буду тестировать Claude (все-таки у нее больше комьюнити и прикольных фич).
Кто уже гуру вайбкодинга, поделитесь своими успешными (и не очень) кейсами.
Пока возился с активацией аккаунта Claude, вспомнил, что у меня есть подписка ChatGPT, и решил пока потестировать Codex на реальной задаче.
Взял go-ycsb: нужно было разделить адаптеры для Scylla и Cassandra и обновить драйверы до последних версий (точнее перейти на новые, но не суть). Эту задачу я уже делал сам — потратил около часа, включая погружение в проект. Потом стало интересно: а как с этим справится Codex?
Решил не мелочиться и начать с режима планирования. Сначала попросил его собрать Architecture.md, чтобы модель поняла структуру проекта. Потом, скорее для учебных целей, добавил ещё SKILL brainstorming. И тут был первый приятный сюрприз: нейронка начала задавать очень хорошие уточняющие вопросы, о которых я сам на старте даже не подумал.
Да, для такой простой задачи это уже был overengineering. Но как первый опыт — очень ценный.
Что понравилось больше всего: Codex не ограничился только кодом. Он поправил документацию, сохранил совместимость API, ничего не сломал, прогнал всё в Docker и ещё написал тесты. И вот тут стало особенно интересно, потому что мой собственный вариант был слабее: я не сохранил обратную совместимость и не обновил документацию с интеграционными тестами.
В итоге на всё ушло около полутора часов в спокойном режиме. Если честно сравнивать результаты, то я справился примерно 60-80%, а Codex на все 100% по полноте выполнения задачи.
После этого у меня довольно простой вывод: начинать использовать AI в разработке можно с более простых сценариев — ревью, планирование, архитектурные заметки, документация, проверки на совместимость, актуализация тестов. Это позволит привыкнуть к экосистеме AI агентов и появится понимание как с этим всем работать.
Кстати, у нас в команде мы уже договорились прогонять ревью через AI и сейчас тестируем разные open-source модели. Нейронки правда бывают более дотошными и внимательными, чем человек, особенно в рутинных проверках. Нас они уже несколько раз выручали.
На следующей неделе буду тестировать Claude (все-таки у нее больше комьюнити и прикольных фич).
Кто уже гуру вайбкодинга, поделитесь своими успешными (и не очень) кейсами.
GitHub
GitHub - pingcap/go-ycsb: A Go port of Yahoo! Cloud Serving Benchmark (YCSB)
A Go port of Yahoo! Cloud Serving Benchmark (YCSB) - pingcap/go-ycsb
❤7🔥5🆒4👍3