На связи @Menzorg Горишь идеей, но быстро выгораешь? Или, наоборот, погружаешься в код с головой, забывая о дедлайнах? Используя диалектику Гегеля, исследуем, как сосуществуют и борются две противоположности разработчика: жгучая мотивация и всепоглощающее состояние потока.
Настало время... интересных историй. Про то, как я заказал сайт и что из этого вышло. Спойлер — человек не справился, а нейросетка — да
Вайб‑кодинг (от англ. vibe coding) — новый способ программирования, где вместо ручного написания кода вы описываете задачу AI‑модели, а она генерирует код сама. Как метко заметил Андрей Карпати, один из пионеров этого подхода, «это не совсем программирование — я просто вижу что‑то, говорю что‑то, запускаю что‑то и копирую‑вставляю что‑то, и это в основном работает». В 2025 году вайб‑кодинг из эксперимента энтузиастов превратился в реальный инструмент: появились мощные облачные LLM, способные писать сложный код, и уже до 90% кода может создаваться с участием ИИ. Ниже — обновленный гайд, как начать вайб‑кодить, какие модели использовать и на что они способны, а также какие возможности открываются перед бизнесом.
WebAssembly являясь (относительно) молодой технологией уже довольно распространён в индустрии.
Тем не менее, почти все материалы в сети по теме рассматривают WASM как цель для компиляции других более высокоуровневых языков.
Информации же по работе с самим WebAssembly и написанию кода непосредственно на нем в сети крайне мало, а в рунете и подавно, что я и попробую исправить под катом.
Меня, как продакта, очень захватила идея: создавать прототипы для кастдева, проверки гипотез и вообще любой новой фичи без статьи в Confluence, груминга с командой и вороха тикетов в Jira. Сейчас на сборку прототипа у меня уходит день - и я хочу рассказать, как это устроено, готов от вас нахватать в панамку, сделать выводы и вайбить дальше, лучше и глубже!
Возможна ли искусственная жизнь? А искусственная эволюция? На эти вопросы здесь нет ответов, но если вам они интересны то заглянуть сюда стоит.
Дискуссии об ИИ и больших языковых моделях (LLM) в разработке часто скатываются в бинарные споры: «замена», «выживание», «деградация». LLM — не против нас, а с нами. Не угроза, а помощь в рутине. Не замена, а инструмент. При умелом использовании ИИ освобождает от рутины и ускоряет реализацию, но не отменяет глубокое понимание предметной области. Без навыка писать код и ясности, что и зачем ты делаешь — ИИ бесполезен. Важнее понять, как LLM усиливают нас, трансформируют работу и рождают новые практики.
Один из девелопер адвокатов Spring Framework, Ден Вега, на днях написал пост в одну запрещенную соцсеть, в котором изучал работу JEP 491 — Synchronize Virtual Threads without Pinning. Внезапно, эффект от JEP обнаружен не был, и автор предложил выяснить почему.
Эксперт сообщества Spring АйО, Александр Шустанов, не остался в стороне и выяснил где тут зарыта собака.
Всем привет! Обучение нейронных сетей с помощью обратного распространения ошибки (backpropagation) — это стандарт де‑факто. Но у него есть ограничения: память, последовательные вычисления, биологическая неправдоподобность. Недавно я наткнулся на интересную статью «NOPROP: TRAINING NEURAL NETWORKS WITHOUT BACK‑PROPAGATION OR FORWARD‑PROPAGATION» (Li, Teh, Pascanu, arXiv:2403.13 502), которая обещает обучение вообще без сквозного backprop и даже без полного прямого прохода во время обучения! Идея показалась захватывающей, и мы (я и ИИ‑ассистент Gemini) решили попробовать ее реализовать на PyTorch для MNIST.
В этой статье я хочу поделиться нашим путешествием: как мы пытались следовать описанию из статьи, с какими трудностями столкнулись, как анализ связанных работ помог найти решение (которое, правда, отличается от оригинала) и каких впечатляющих результатов удалось достичь в итоге. Спойлер: получилось интересно, совсем не так, как ожидалось, но результат превзошел ожидания от процесса отладки.
Дисклеймер 1: Это рассказ об учебном эксперименте. Результаты и выводы основаны на нашем опыте и могут не полностью отражать возможности оригинального метода при наличии всех деталей реализации.)
В этой статье я расскажу, как разрабатывал виртуальную машину на C#, столкнувшись с проблемами производительности и управления памятью, а также поделюсь опытом, который приобрел в ходе работы.
Мы посмотрим и на Корбена Далласа и Лилу из фильма «Пятый элемент», на сюжет из фильма «Люди в черном» и другие интересные арты, созданные LLM программно.
Допустим, мы художнику завязываем глаза, даем в руки кисть и краски и формулируем задание, согласно которому он должен на холсте всё это изобразить максимально точно.
То же самое мы можем проделать с LLM, дав инструкцию нарисовать заданный сюжет, а вместо кисти и красок будет код. Например, HTML5 и API canvas.
Выясняется, что среди моделей есть как аутсайдеры, провалившие задание, так и гении, впрочем, как и среди людей. А одна из них, по сравнению с другими, ну просто Леонардо да Винчи.
В первой части статьи мы рассмотрели общую семантику применения функции в различных языках программирования и реализацию императивного вызова функции в машинном коде в стековом и бесстековом вариантах. Теперь мы рассмотрим теорию и практику реализации императивного вызова функции в модели продолжений (continuations): что такое продолжения, зачем нужны явные и неявные продолжения, как при помощи продолжений реализовать различные используемые в языках программирования управляющие конструкции.
Для многих людей, занимающихся программированием, вызов функции воспринимается практически как синоним передачи управления с сохранением адреса возврата и выделением фрейма памяти в стеке. Это однако, не всегда верно и в практическом, и в теоретическом отношении. О семантике и прагматике вызова функций мы и поговорим в этой статье.
При написании своей VM для RISC-V возникла необходимость в тестировании.
Сначала я пытался писать юнит-тесты самостоятельно, но выходило, что я просто копирую логику из основной.
И по сути тестирую не соответствие спецификации, а соответствие моему пониманию.
Через некоторое время я наткнулся на официальный набор тестов для RISC-V и решил их использовать.
Это помогло найти несколько багов в моём коде.
Поскольку прошлая статья про «особенную» Java вызвала интерес, мы решили продолжить праздник. Настало время познакомить разработчиков С# с темной стороной любимой технологии — сегодня шатаем .NET!
Последние пару-тройку лет на конференциях все чаще я слышу жалобы знакомых в игрострое о том, что текущий вектор развития "современного C++" не соответствует потребностям игровой разработки. Реальные полезные нововведения фактически закончились с выходом C++17, а попытки внедрить C++20 часто заканчиваются обнаружением множества "гейзенбагов" и существенным снижением производительности - критичные для нас на 10-15% от сборки к сборке. Пошатавшись по разным игровым студиям, блин, скоро будет 15 лет как я тут, у меня таки немножечко есть, что вам рассказать.
Все современные студии, что крупнее двух с половиной землекопов, пишущие игры на плюсах, шарпе или чем-то близком - используют Visual Studio или переходят со своих поделок на Unreal/Unity, который так-то тоже плюсы, хоть и со странностями. Так исторически сложилось, что винда и майки были, есть и в ближайшем будущем горизонта лет десяти останутся самым крупным рынком ПК-консольных игр, а сами консоли давно стали "ну совсем ПК", но чтобы не терять эксклюзивы (и шекели) вендоры в этом не признаются никогда.
Мобилки, как-бы отдельно, и там свои свои покемоны Mac с Android, но в Visual Studio в том или ином виде создаются, дебажатся и оптимайзятся 95% игр, остальное - погрешность. С момента начала золотой эры игростроя (где-то в конце 90-х), большинство игр писались с учетом того, что они будут выпущены на ПК, под ПК понимается - под винду. И наследие многих A+-студий так или иначе связано с Microsoft, даже для не-Microsoft консолей и мобилок.
Я занимаюсь разработкой уже больше пятнадцати лет. Наверное, меня можно отнести к “прошлому” поколению разработчиков — тем самым старперам, которые вручную писали код на высокоуровневых языках вроде Java, PHP, JavaScript, Go. Уже давно замечаю за собой, что становлюсь всё более консервативным в вопросах выбора инструментов и технологий для проектов, за которые отвечаю. Поэтому к AI-хайпу, копилотам, агентам и прочему отношусь с осторожностью и скепсисом.
Но всё же решил попробовать — и делюсь с вами своими наблюдениями: что работает, а что нет.
Сразу скажу: мне в целом понравилось. Я бы даже сказал, что впечатлён.
Недавно посмотрел на ютубе видео, в котором поднимается проблема того, что на место классических программистов‑кодеров приходят «программисты»‑prompt‑инженеры.
Само видео мне не очень понравилось — путанное и цикличное повествование, бессмысленная картинка большую часть времени. Но под конец автор высказал ряд мыслей, которые вдохновили меня на написание статьи. Сами мысли я повторяю в конце статьи, но вот вам таймкод.
И рассуждения я начну с вопроса — «ну и в чем проблемы?»
После того как нам удалось сделать это с Node.js, занялись поиском следующей жертвы, которой после недолгих раздумий стал компилятор Go.
Полгода жестоких экспериментов и удивительный результат.
