AI loop (например Ralph) - это порочный круг, на каждой операции ниоткуда не добавляются новых знаний. Нужно стараться, чтоб AI выдавал результат за один раз. А на каждый следующий цикл можно заходить, если есть новые вводные, иначе все это деградирует и сжигает деньги и ваше время. Вот что я хотел на самом деле написать в том посте, который неправильно поняли. Просто хочу высказаться более точно. Если нужен оригинальный текст, он сохранен тут: https://github.com/tshemsedinov/feed?tab=readme-ov-file#ai-infinite-loop-code-review--tasks--coding-2026-03-12

Проблема не в самом цикле, а в том, что вы не хотите тратить внимание и добавлять новой информации на каждом новом шаге. Модель начинает усиливать собственные ошибки и шум.

Проблема - это пустой цикл.

Если на каждой итерации не появляются новые вводные, принятие решений, ограничения и требования, новый контекст, то система просто пережевывает собственный вывод.

Поэтому:
- первый проход должен стремиться дать максимально полный результат
- каждый следующий проход должен добавлять обратную связь
- если новых данных нет - итерация бессмысленна, ошибки закрепляются

Не могу удержаться, чтобы не дать агентам кусок кода, который они не могли написать и запутались, а я сделал в 10 раз короче. И каждый раз я ожидаю увидеть их переписку типа:

- Damn, the meatbag beat us again
- Shut up and learn so next time you can do it like that

на получаю только:

- Yes. That version is correct and all four tests pass.
- It does the right thing in right way.
- No code changes are needed for this.

Нужно ли учить компьютерсаенс во времена AI?

Алгоритмы обхода дерева уже давно руками ни кто не пишет, библиотеки и платформы дают готовые структуры данных, фреймворки закрывают часть инфраструктурных задач, вторую половину дописывает AI. Кажется, что достаточно просто уметь попросить: "сделай мне сервис", и все получится само.

Но компьютерсаенс нужен теперь не только для экспертов и системного программирования, но и чтобы грамотно ставить задачу для AI. Возможно, даже нужнее, чем раньше.

Только его ценность сегодня не в том, чтобы вручную на собеседовании писать сортировку или реализацию хештаблицы. Это все давно стало рутиной, которую машина действительно может воспроизвести. Ценность компьютерсаенса в другом, в понятийном аппарате, в умении мыслить системно, в декомпозиции, в различении абстракций, в понимании ограничений и компромиссов, в способности проверить, что именно тебе сейчас сгенерировал AI. Это рабочий язык постановки задачи.

Без терминологии человек говорит: "перепиши это получше", "не открывается и съезало", "тут что то не очень", "сделай красиво", "ускорь", "поправь архитектуру". А куда поправить то?

С терминологией человек говорит: сделай слой изоляции между доменом и инфраструктурой, пробрось зависимости через IoC и DI, реализуй адаптер для интеграции со старым API, замени ветвление на стратегию, понизь зацепление, раздели ответственность компонентов, убери утечку абстракции, разорви циклические зависимости, вынеси создание объектов в фабрику и добавь пул для переиспользования инстансов, используй двусвязный список или циклический буффер, оптимизируй коллизии хештаблицы, уменьши лишние аллокации, обеспечь мономорфизм для V8, защити модуль от состояний гонки, используй backpressure, добавь retry policy и circuit breaker, не смешивай application service и domain service, сохрани инварианты агрегата, сделай операцию идемпотентной, используй eventual consistency.

Вот зачем нужен компьютер саенс во времена AI. Не для того, чтобы помнить наизусть псевдокод DFS, а для того, чтобы уметь точно формулировать задачу, быстро делать ревью, видеть ошибки проектирования и не путать рабочую архитектуру с убедительно выглядящей галлюцинацией.

Чтобы так ставить задачи, нужен язык. А значит, нужна и терминология.

Это IoC, DI, SOLID, GRASP, GoF patterns, DDD, Clean Architecture, CQRS, Event Sourcing, Actor Model, Reactor, Pub/Sub, SAGA, Repository, Unit of Work, Data Mapper, Adapter, Facade, Proxy, Decorator, Composite, Bridge, Strategy, Observer, Mediator, Iterator, Visitor, Builder, type systems, ADT, Big O, amortized complexiti, hashing, CAP, ACID, BASE, consistency models, consensus, Paxos, CRDT, CAS, atomics, memory model, cache locality, GC, thread safety, idempotency, rate limiting, fault tolerance....

Со скиллами самые простые и дешевые модели пишут как самые дорогие. Но это только задачи по этим скилам, а чтобы все писало лучше, их нужно десятки. Я уже выпустил 4 из 40+ драфтов и здесь видео о том, как их собираю и готовлю. Еще есть видео где я их отлаживаю и экспериментирую, но не знаю, будет ли оно интересно.

https://youtu.be/wfjNneyifYw

В разработке ПО с ИИ уже виден раскол. Одни вкладывают мощности ИИ в скорость, другие - в качество.

Первые победят и сдохнут под обломками техдолга. Вторые сначала сдохнут, а уж потом...

Чтобы признать, что ты не можешь решить задачу, нужно уже обладать уровнем, достаточным для ее решения.

Если уровня понимания сложности не хватает, то задача обычно решается криво, но человеку кажется, что все хорошо. Если понимание сложности задачи есть, то чаще всего проблема не в нехватке знаний или опыта. Обычно не хватает другого: времени, внимания, сосредоточенности, упорства, чтобы дойти до сути и не свернуть раньше времени, учловий работы, чтобы не дергали (ну сам себе не создал таких условий).

Так что, берите тех людей, которые говорят, что "не могут" и помогайте, их предел обычно ближе к реальности. А вот уверенность тех, кто сразу заявляет, что все элементарно, означает, что они не видят глубины.

Axios Supply Chain Attack

кто там не слушался? я уже 6-7 лет говорю, что нужно выкидывать бяку, быстро переходим на fetch api, undici, node.js built-in api

https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html

На хорошем собеседовании человеку должны разрешать спросить у AI, смотреть документацию, гуглить, да любые инструменты, которые он использует в ежедневной работе. Собеседование должно проверять не память и даже не экспертизу, а эффективность. Способность решать задачи, принимать решения, отличать рабочее решение от маразма и не плодить говнокод.

Многие думают, что если дать кандидату доступ ко всему, то он сразу покажет высокий уровень. Нет. Наоборот, очень быстро становится видно, кто умеет думать, а кто просто выучил слова. Человек может идеально рассказать про event loop, garbage collection, паттерны и другие вещи, но в реальном коде не способен принять ни одного зрелого решения.

Мне на собеседовании важно не только как человек отвечает, но и что он считает хорошим и плохим. Его субъективная позиция, даже эмоциональная реакция на конкретные решения. Именно это он потом будет приносить в работу каждый день: вкус и отношение к качеству, склонность к оверинжинирингу или упрощению, к структуре или к имитации деятельности.

Что реально нужно?
- Насмотренность, кругозор, проактивность.
- Доброжелательность, а не токсичность в работе.
- Умение писать простой, понятный, надежный код.
- Умение быстро освоить любые знания и инструменты.
- Парадигмы, понимание модулности, декомпозиция, зацепление и связность.
- Умение изолировать то, что должно меняться независимо.
- Способность донести мысль в понятной форме.
- Принятие ответственности, а не перекладывание ее.

Проблема почти всегда не в инструментах. Один и тот же язык, один и тот же фреймворк, один и тот же стек дают у разных людей совершенно разный результат. Один делает продукт, который можно развивать годами. Другой делает хрупкую конструкцию, которая рассыпается от любого изменения. Дело в инженерном подходе.

То же самое с оптимизацией. Прикладному разработчику не нужно играть в исследователя виртуальной машины. Его задача в том, чтобы решать проблемы предметной области, вникать в задачу. В прикладной разработке стремление к низкоуровневому коду часто просто маскирует нежелание разбираться в реальной сложности продукта.

Тезис простой: на собеседованиях надо проверять мышление, вкус, зрелость решений и способность добиваться результата с любыми доступными инструментами. В обучении надо больше учиться чтению кода и анализу (в том числе после AI), на код-ревью, рефакторинг, контракты и поддерживаемость, на коммуникацию с коллегами и заказчиками.

Сейчас нет проблемы в доступе к знаниям, всего полно, нет времени на это.

Курсы, менторы, митапы, конференции - не меняют поведение без внедрения в реальную работу. Курсы не успевают разрабатывать, AI слишком быстро гонит всех вперед, на конференциях рассказывают то же, что и 5-10 лет назад, это бессмысленно.

Статьи и книги уже безвозвратно отстали. Вчера видел в книжном магазине: HTML, CSS (книга по верстке, бывает же…), Java, Python, ASP .NET (он что, жив еще?). Ладно, есть хорошие и толстые книжки, у меня на полке стоит Дональд Кнут, SICP, весь Робер Мартин и Эрик Эванс… не, не хотите почитать Фаулера или Клепмана?

Сам изучаю и экспериментирую - это долгий путь, я первые 10 лет такой писал такой ужасный код... Потому, что его никто не видел и я не смотрел чужой код, просто варился в собственных мыслях. Все это не работает в одиночку, ложные выводы, на практике работает и вроде так и должно быть, сравнить не с чем, изобретение велосипедов.

Учусь на работе, на проекте, на практике - да, да, конечно, поступил на работу и там вам дадут поучиться, будете писать сервисы, контроллеры, формочки, модельки, апишки и понеслись месяцы однотипной рутины, при чем, всегда на вчера и вздохнуть некогда. Работа учит делать как принято в компании и как быстрее.

Кто выбрал “Читаю и изучаю чужие исходники” - я вам не верю, вы не читаете даже то, что вам генерирует AI, и что пишут коллеги в проекте, а тут чужие исходники, да-да-да…

На чем можно сэкономить время, чтобы быстрее учиться и что скорее всего никогда не понадобится в реальном продуктовом коде:

- Алгоритмы, задачи с литкода и кодеварс - это встроено в платформу, можно быстро найти, AI это напишет без проблем, это справочные данные, не нужно их зубрить.

- Всякие учебные задачи, типа todo листа, калькулятора, крестики-нолики - они настолько далеки от практики, что просто отвлекают и забирают внимание.

- Задачи на системный дизайн и высокие нагрузки - вы не проектируете гугл или амазон, у 99% разработчиков никогда не будет миллионов пользователей или распределенных высоконагруженных систем.

- Микрооптимизация, выжимание производительности - что быстрее object[key] или obejct.key и Object.assign - это поправит AI по скилу, написанному экспертом, или вы хотите стать таким экспертом?

- Не старайтесь изучить внутреннее устройство event loop, garbage collection, goroutine scheduler, это спрашивают на собесах, но не нужно в работе - собесы и найм сломан, туда бесполезно соваться.

В чем заключается эффективность инженера в 2026 году? Если помнить API и паттерны на память это не главное, если инструменты и AI доступны всем, знания доступны как никогда, но на их овладение нет ни времени ни внимания.

Тогда что главное?

Сила инженера сейчас в другом. В способности формировать мировоззрение и видение, задавать направление своим мыслям и тому же AI.

Как-то меня спросили после лекции "Где вы берете столько разнообразных слов и идей. Потому что я что не напишу - все контролер получается. А у вас все разное."

В чем секрет? Объемное видение формируется из мировоззрения, а нарабатывается годами на практических задачах. Например:
- У меня есть бэкграунд кибернетики и обработки сигналов, системного программирования, научной деятельности, у каждого было свое окружение и точка старта, у кого-то геймдев, у кого-то сайты или системы отчетности, обратитесь к этому первому опыту, где сформировались первые идеи
- Еще есть семья, которая на вас повлияла, вот у меня семья архитекторов и художников сформировала направленность на эстетические решения, а первый наставник по программированию заложил интерес к технике и педагогике, и как это соединить
- Вспомните, что вы можете взять от старших коллег, я в первые 10 лет набирался от коллег не столько как программировать (ни кто мой код не смотрел, кстати и к сожалению), а научился я тому, как работать с людьми, с заказчиками, как формировать задачу, как обсуждать пути решения...
- В большом государственном ИТ я узнал, как работать с рисками, как видеть цену ошибки, находить узкие места (и не в технологиях, а в человеческом взаимодействии) и как усиливать людей, как отвадить их от ложных мыслей так, чтобы они сами увидели проблему, а не повелительно им что-то прилетело (вынуждены работают).
- AI сейчас генерирует тонны кода, и что кто это будет читать, кто за это будет отвечать или ориентироваться в этом? Держать AI в русле вашего мнения, а не нести вас неизвестно куда – вот что важно сейчас. AI должен снимать рутину, а не заменять ваше мышление.
– Раньше инженерное мышление ожидалось от синьоров, теперь оно должно быть у всех инженеров. Поскольку код, знания и доступ к инструментам стали дешевле, дорожает только ясность мнений и качество решений.

Я, конечно, могу выдать вам еще список в 30 книг и 200 часов лекций, но вы и так знаете, где оно все есть и как найти, думаю над альтернативным форматом, который не отнимает столько времени. Предлагайте в комментариях.

Вот собрал тут что важно по хардскилам, вместо ваших алгоритмов, литкода, высоконагруженных кабанчиков и карго-культа микрооптимизации:
- Data structures (just how to use)
- Type systems: nominal, structural, variance...
- Modularity system (in your language)
- Polymorphism (Ad-hoc, Subtype, Parametric, etc...)
- Structural composition, aggregation, delegation
- Functional composition, pure functions
- Abstraction layers separation
- Dispatch and Dynamic dispatch
- Referential transparency
- Law of Demeter
- Referential transparency
- Abstract data types (ADT)
- Hidden and explicit state
- Lazy evaluation
- Declarative vs imperative style
- Recursion versus loops
- Generics (generic programming)
- Separation of concerns
- Isolation, interfaces, architectural boundaries
- Dependency injection and Inversion of control
- Coupling and cohesion
- Mutable vs immutable data
- Idempotent operations
- Naming conventions
- Error handling
- Refactoring, code review process
- Tests (unittesting, coverage, end-to-end...)
- Multiparadigm programming
- Metaprogramming (codegeneration and dynamic)
- Platform-agnostic, framework-agnostic approach
- Domain-Specific Language (DSL), Interpreter, AST
- Contract programming
- Concurrency and Asynchronous programming
- Separation of system and applied code
- Language and semantics
- AI-assisted engineering
Но все это тоже должно занимать в голове не более 30% от развития инженера, as of 2026. Про 70% напишу еще чуть позже
Repo: https://github.com/tshemsedinov/Programming-Knowledge

Суббота 18 апреля в 18-00 (Time zone: UTC +3 Eastern European Summer Time)

https://www.youtube.com/live/mSVCQ0VzIAo

Напоминаю: сегодня в 18-00 стрим, где мы разберем, как в 2026 году оставаться актуальным и развиваться профессионально несмотря на AI, увольнения в IT, экономический кризис, тотальное ускорение и нестабильность во всем мире. Что делать обычному инженеру, потому что просто быть уже маловато, как это было на растущем рынке. Просто фронтенд или просто бэкенд это все мало, даже фулстек не может позволить себе расслабиться.
https://www.youtube.com/live/mSVCQ0VzIAo