До IT я поработал и инженером-конструктором в машиностроении, и инженером-проектировщиком в строительстве. Меня велосипедами не испугать. Какой хрени я только не реализовывал, от геокуполов до плавающих экскаваторов. Моя работа всегда была реализовывать фантазии, там постоянно приходится изобретать.
2021 год
Я уже в IT с полной уверенностью, что я — инженер всего. И тут же попал в секту свидетелей фреймворков. Хожу на все конференции в Москве, Питере. Меня там облизывают, поят пивом, дарят мерч. Интересные спикеры. Глеб в курилке увлечённо рассказывает про React. Прихожу обратно на работу, приношу новые знания. Смотри! вышел redux! Я теперь пишу на TS!
Мой начальник, он же CEO, опытный архитектор с огромным опытом разработки, на это только плевался. Всегда предлагал написать всё своё. Порывался всё переписать: фреймворки, базы данных, чуть ли не языки программирования. Я был в ужасе.
Проходит время, год примерно 2024. Я в свой Pet по своей воле завожу наши рабочие велосипеды. Например, MemoDb — самописная база данных in-memory + реактивный транспорт. Там всё шикарно. Она летает как никто, никакой редис не нужен. Система плагинов, например OLAP куб для мгновенных отчётов, транспорт через сокеты, вся клиентская обвязка. Ни одной зависимости. Ничего лишнего. Всё работает как часы. А самое главное, я всё в ней знаю, потому что писал сам. Я в восторге.
Я полностью перешел на BDD (Bicycle Driven Development). Пока индустрия спорит о паттернах, у меня свой манифест. Да, есть DDD (Deadline Driven Development — разработка «петух клюнул») или AOD (Ass Oriented Development — больше бумаг, чище жопа). Но мой выбор — велосипеды. Я начинаю велосипедить всё.
2025 год
Пришли AI-агенты и заявили мне человеческим языком: «Слышь, инженер, нам твои велосипеды в контекстное окно не впихиваются. Мы знаем весь StackOverflow, а твою MemoDb — нет. Либо выкатывай в open-source под наших краулеров, либо пиши как все».
Я с ними борюсь. Я борюсь с агентами, уговариваю, заставляю писать как я хочу. Сто раз повторённые «ПЛАГИН ДОЛЖЕН БЫТЬ УНИВЕРСАЛЬНЫМ ДЛЯ ВСЕХ ТИПОВ ИГР! Хватит генерить под каждую логику отдельный костыль!»
Пришлось внедрять правила, упаковывать всё в SDD (Spec-Driven Documentation). Нейронки сами выбирали какой-то дикий формат спек, но уверяли меня: «Капитан, всё норм, нам правда так удобней, мы на 146% опережаем рынок».
А ещё эти скобочки в JSX после Return бесят. Вот прям после генерации React компонентов иду и удаляю их. Они потом смотрю сволочи опять их поставили. Но это моя борьба. Таков путь.
2026 год
Мне уже всё равно, делайте как хотите. Любите свои Tailwind, yaml, спеки и эти поганые скобочки. Да пофиг. Главное, что всё работает. Да и в код я уже не смотрю, и честно признаться, я в те древние времена, когда ещё люди писали код руками, писал его хуже.
Но, как ни странно, велосипедов ни стало меньше. Каждая кухарка теперь действительно пишет велосипед на C++. И кухарки все кругом. Мир сошёл с ума. Зачем мне брать какую-то библиотеку? Я напишу свою за несколько часов. Я уже не помню, когда я подбирал какую-то библиотеку. Я пишу на разных языках программирования и даже не знаю, какие библиотеки и фреймворки у них существуют. Произошёл кембрийский взрыв, большой взрыв велосипедов. Выглядит кошмарно. Цирк уродов, ползают какие-то многоножки с хоботом на спине и половыми органами на носу, и пищат «Убейте меня». Мы находимся здесь.
Я думаю, 99,9999 этих мутантов вымрут уже завтра. Но именно в этом бульоне родится что-то принципиально новое. Грёбаные велосипеды — это и есть прогресс.
Комментарии (47)
AngryEvilCookie
19.06.2026 13:53От того что каждая кухарка будет на с++ вайбкодить ничего полезного не выйдет. "Зачем мне брать какую-то библиотеку? Я напишу свою за несколько часов." Конечно, конечно. Зачем писать что-то когда есть готовое? Вот вы с агентами боролись, но почему? Вся статья кричит "все делаем с нуля, велосипеды рулят". Но где же фраза "я написал гптчат за вечер, все резко и дерзко"? Призывать все с нуля будут только глупцы, а не архитекторы с кучей стажа. Действительно умные люди уже давно все сказали, читайте Брукса, сами знаете какую книгу. Переиспользование уже созданного это один из двигателей прогресса.
digrobot
19.06.2026 13:53Переиспользование уже созданного это один из двигателей прогресса
Двигатель, за счет экономии времени, но есть и минусы :
- несмотря на огромное коммьюнити и сотни контрибьюторов, безопасность все равно под вопросом (регулярно всплывает "срочно обновите React, и openssl, и openssh, и докер, и nginx, и ядро, и еще чего-нибудь"), и нередко дырка в какой-то фиче, которую 95% не используют
- не растут твои компетенции, когда используешь чужой код, ведь, как правило, не нужно понимать, как он работает. многие современные разработчики не знают, как выглядит сырой HTTP, потому что они просто используют либу
- привыкаешь к чему-то не самому удобному и красивому, за счет его массовости, глаз замыливается, и уже не возникает мыслей, что можно сделать лучше, соответственно, что-то лучшее и не появляетсяAngryEvilCookie
19.06.2026 13:53Если мне нужно вывести элементарный грид и кнопку, то я не буду писать их заново сам, это полный бред. Newtonjson миллионы пользовались/пользуются и будут пользоваться. Да мне плевать как он что делает, главное что делает. Зачем мне знать как работает сырой хттп? Может ещё знать как куда чего в памяти прыгает? Зачем, если я калькулятор детский делаю? Программирование это борьба со сложностью, инкапсуляция позволяет ее уменьшить. Это не просто так один из главных принципов ООП. А тут велосипеды предлагают, действительно чего это я.
Вы пишите "не смотря на огромное коммунити", так даже огромное коммунити не может справится, а тут речь про соло велики на колене. Смешно. Прогресс появляется, когда нет готовой реализации под твою задачу и ты ее уже пишешь сам, при этом зачастую базируясь на наработках других людей и это нормально. Вот как раз большинство новых алгоритмов и программных продуктов так и возникает.
alexac
19.06.2026 13:53Инкапсуляция уменьшает сложность только локально. И только если используется хороший четкий контракт, который не нарушается, и не течет. Проблема в том, что для сторонних решений никто не предоставляет гарантии на то, что контракт есть, он хороший, он соблюдается, и не течет имплементацией наружу. Зато почти всегда сторонняя библиотека оказывается более универсальная, чем требуется для задачи, и привносит дополнительную сложность если не ради этой ненужной универсальности, то как минимум необходимостью эту библиотеку как-то к себе приносить, следить за обновлениями, обнаруженными уязвимостями, etc.
А потом в сторонней библиотеке всплывает критичный баг или просто странное недокументированное поведение, и приходится лезть внутрь и разбираться в большом количестве незнакомого кода, чтобы понять, что происходит, и как заставить это работать нужным образом.
Kobagugi
19.06.2026 13:53Обычно ценность стандартных инструментов начинаешь понимать только после пары лет поддержки собственного велосипеда в проде
VladKapitan Автор
19.06.2026 13:53Ну это смотря как написать. Если что-то всплывает потом взял, да дописал. Ну и свои всегда весят меньше, бегают быстрей, делают только то что требуются.
Darkness_Paladin
19.06.2026 13:53Переиспользование уже созданного это один из двигателей прогресса.
Дешёвое переиспользование. Не в смысле именно денег, а вообще.
Daddy_Cool
19.06.2026 13:53Зачем писать что-то когда есть готовое
1. Обычно нужно с перламутровыми пуговицами.
2. Возможности своего кода знаешь. Даже так ЗНАЕШЬ. А в чужом... не знаешь какие там грабли и сколько их. Речь не об ошибках, а просто надо читать доки, разбираться что там имел ввиду автор, что-то будет неочевидно, и т. п...
egranty
19.06.2026 13:53А Эволюция именно так и происходит. Каждая мутация организма является “велосипедом”, но именно так из одноклеточных появилось всё богатство и многообразие Природы.
Некоторыефреймворки(динозавры) господствовали миллиарды лет, а потом вымерли, из-за неспособности адаптироваться к изменившимся условиям.
Другие (акулы, крокодилы, jQuery), незначительно адаптируясь, умудряются выживать миллиарды лет. Но они уже не господствуют, а просто занимают свою (пока свободную) нишу. Очередной “велосипед” может запросто потеснить их.
FixicusMaximus
19.06.2026 13:53Зачем мне брать какую-то библиотеку? Я напишу свою за несколько часов. Я уже не помню, когда я подбирал какую-то библиотеку. Я пишу на разных языках программирования и даже не знаю, какие библиотеки и фреймворки у них существуют.
Ох уж эти джаваскриптезеры. Они походу реально думают, что кроме их дырявого веба больше ничего не существует.
Kobagugi
19.06.2026 13:53То же самое происходит в питоне и го, дело не в языке, а в современной культуре разработки и низком пороге входа
iRupert
19.06.2026 13:53Прочитал статью спасибо, но так и не понял гравийный велосипед покупать или кросс-кантри?
supercat1337
19.06.2026 13:53Библиотеки без зависимостей, написанные прямыми руками, и с документацией - норм велосипеды. Ничего против не имею.
A-Dobrii
19.06.2026 13:53а время потраченое на написани этой библиотеки?
а ошибки которые в этой библиотеке есть, и которые будут найдены, в проде?
а отсутвеие документации - и невозможность работать с этой библиотекой другим?
"Библиотеки без зависимостей, написанные прямыми руками, и с документацией " -
существует, направо от сферического коня метрового диаметра в музее идеального
AlexSky
19.06.2026 13:53Чувак постоянно велосипедит и думает, что все вокруг делают то же самое.
За 20+ лет работы нигде такого не видел, всегда начинают с поиска подходящей либы и делают свой велосипед, только если ничего подходящего не нашлось.
Kobagugi
19.06.2026 13:53Сильно зависит от культуры в компании. В геймдеве или эмбедде кастомные велосипеды до сих пор встречаются на каждом шагу
TimsTims
19.06.2026 13:53всегда начинают с поиска подходящей либы и делают свой велосипед, только если ничего
Да, и так появляются либы в npm которые выполняют функции сложения и вычитания, на которые потом миллионы зависимостей подвязываются.
ImagineTables
19.06.2026 13:53Но, как ни странно, велосипедов ни стало меньше. Каждая кухарка теперь действительно пишет велосипед на C++. И кухарки все кругом. Мир сошёл с ума. Зачем мне брать какую-то библиотеку? Я напишу свою за несколько часов.
Конечно, легко во всём винить себя, но ещё легче —
Неда ФландерсаКомитет.Я давеча спросил у железного дурака, как сделать хороший синглтон. (Я понимаю, что «хороший синглтон» это как «вкусное дерьмо», но иногда просто хочется
поесть в «Макдональдсе»сделать по-настоящему удобный интерфейс к логгеру). Он мне выдал из своей базы код CRTP singleton mixin с бойлерплейтом для использования. Я попросил вариант без бойлерплейта (и без макросов!), и он выдал the passkey idiom. В принципе, это оказалось то, что мне нужно. Следующий вопрос был: какая пара классов в стандартной библиотеке C++ за это отвечает. Ответ: никакая. Даже в boost¹ и loki нет готовых к использованию классов. Бери готовый текст и копипасть в проект.Получается, если человек хочет сделать без велосипедов, даже если он преодолевает свою неприязнь к стандартной библиотеке C++, всё равно оказывается, что нельзя. А у меня теперь есть ещё одно дополнение к header-only library с гордым именем
CppUtils.h.Я хочу сказать, что больша́я доля вины за то, что человечество реюзает код через базу данных чатботов, а не через библиотеки, лежит не на тех, кто даёт, а не тех, кто НЕ даёт.
¹Тем самым, boost вновь доказал свою квантовую природу. Если в нём есть нужный функционал (которого нет в
std), тебе говорят: «Ну так, а что ты хочешь. boost это же почти стандартная библиотека». А если в нём нет чего-то важного (как, например, the passkey idiom), тебе говорят: «Ну так, а что ты хочешь. boost это же всё-таки не стандартная библиотека, как авторы захотели, так и сделали». Очень удобно.
d3d14
19.06.2026 13:53На самом деле это хорошо. Это смена парадигмы. Зачем мне tailwind, если агент прекрасно напишет кастомный css, под заданный мной дизайн? Зачем тащить в проект JS-фреймворк, если агент легко пишет чистый javascript код? Профессия фронтендера уходит в прошлое.
900k
19.06.2026 13:53А чистый JavaScript код думаете будет более понятный, быстрый и компактный?
d3d14
19.06.2026 13:53Смотря для кого. Для агента - скорее да. Фреймворки же написаны для облегчения разработки людьми, и нужны они людям.
900k
19.06.2026 13:53Хорошо, а если просто все перевести в 0 и 1, это тоже будет более понятно агенту?
Flux82
19.06.2026 13:53И Вы, и Ваш оппонент - утрируете. Есть уровень абстракции библиотеки. Выше абстракция - проще типовые случаи, больше спрятано под капотом. Но нетиповые случаи могут породить монструозные конструкции. Вот у вас и получается шкала влево-право от 0/1 к фреймворку для всего. Точка оптимума на этой шкале у разных людей разная, а у моделей она влево явно смещена.
900k
19.06.2026 13:53В чем я утрирую? Я только вопрос задал, чтобы на определенные мысли натолкнуть. По факту теперь, в чистом JS нет шаблонизатора и роутера, ХТПП клиента с интерцепторами. Это все типовые случаи.
LLM работает в категориях мыслей людей и для них фреймворки тоже порой нужны.d3d14
19.06.2026 13:53Отвечу на вопрос. 1\0 - нет, для агента хуже, т.к. ему придется выступать в роли компилятора, для чего он не предназначен (хотя может).
С фреймворками такие вопросы - что если агент хуже знает этот фреймворк (менее распространен, или эта версия фреймворка не входила в обучающий датасет)? Можно конечно скормить ему спецификацию, это управление через контекст. А языки программирования в у него зашиты в весах, они для него более "органичны" и "интуитивны".в чистом JS нет шаблонизатора и роутера, ХТПП клиента
Для специфических вещей, конечно, имеет смысл использовать специализированные библиотеки. (Хотя я, помниться, работал с шаблонам в JS через html тег <template>. Но не претендую на истину, не фронтовик)
900k
19.06.2026 13:53Ну по крайней мере, на моем опыте, для написанного мною фреймворка он пишет код достаточно быстро и корректно, ну тут еще зависит наверное от того как фреймворк соот-ет паттернам. К чему это я, для хорошего LLM не проблема на ходу научиться фреймворка, насчет траты токенов – не знаю как будет
d3d14
19.06.2026 13:53Аналогично, у меня есть свой PHP-фреймворк и для него по спецификации он тоже хорошо пишет. Я не утверждаю категорично, скорее поднимаю вопрос - а нужны ли теперь будут все эти фреймворки?
900k
19.06.2026 13:53Я считаю, что разработка должна продолжаться без LLM, быть LLM independent. Недавний пример с Fable тому подтверждение
Kobagugi
19.06.2026 13:53Своя in-memory бд это весело, пока ты не уволишься и следующему бедолаге не придется поддерживать этот шедевр без документации
VladKapitan Автор
19.06.2026 13:53Уже давно не бывает кода без документации. У меня даже легаси проекты написанные на перфокартах спеками обложены, запустил реверс инженерного агента, и всё, код даже уже не важен, хоть в другой язык его конвертни
LinkToOS
19.06.2026 13:53Надо замкнуть цепочку, чтобы водопад велосипедов, вместе с отзывами велосипедистов, возвращался обратно в ИИ. Это запустит эволюционный отбор велосипедов. Тогда следующие рожденные велосипеды будут иметь правильную наследственность.
nickolaym
19.06.2026 13:53У велосипеда обычно очень маленький фактор автобуса.
Собственно, тупые иишницы прямо об этом и говорят. Вот уйдёт ракитектор, и кто и как будет сопровождать проект? Джун полезет на стековерфлоу, хоть с иишницей, хоть человеческим голосом живых человеков спросит, а никто и не знает...
sse
19.06.2026 13:53В пределе при использовании ЛЛМ разница между велосипедом и библиотекой исчезает: хорошо насмотренная модель просто напишет вам точно тот же код, что в библиотеке, другой, но такой же, и код будет двуедин - как бы велосипед, но как бы и библиотека
materiatura
На ум пришла такая паралель: лет 10 назад, пришла тема 3D-принтеров, и радостные прогнозы, мол, скоро и заводы будут не нужны, каждая хозяйка напечатает себе новую сковородку прямо на кухне, ну и прочее. Аддитивные технологии, мол, будущее уже здесь. Улеглось как-то, затихло.
Dev2Dev_J
3Д принтеры сейчас набирают популярность локально, особенно на предприятиях, поэтому я бы не сказал,что тема затихла.
Rsa97
Ну так это же классическая кривая новых технологий (кривая Гартнера).
И часто какая-то область содержит комбинацию технологий, каждая из которых имеет свою кривую. В результате получаем сложную кривую, на которой то подъём, то спад, то короткое плато.