Красота, эстетика и интуиция решают задачи там, где формального компутер-саенса пока недостаточно.

Я не противопоставляю эстетику науке и уж точно не свожу все к мистике. За настоящей эстетикой почти всегда стоит какой-то принцип, обобщение, закономерность, просто оно еще не формализовано.

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

А потом уже приходит наука и аккуратно рационализирует то, что сначала было найдено чувством формы.

По состоянию на 7 марта 2026 лучшее применение:
Sonnet 4.6 - модель по умолчанию для написания кода
Opus 4.6 - для написания ТЗ, стратегии и ревью кода

Opus 4.6 лучше отдавать архитектуру, спецификации, декомпозицию задач, критерии приемки и финальный QA для рискованных задач. Sonnet 4.6 лучше отдавать реализацию, итерации, рефакторинг, тесты и выполнение хорошо определенных задач в масштабе.

Лучшая схема на сегодня: Opus 4.6 проектирует, Sonnet 4.6 реализует, потом Opus 4.6 ревьюит

Моя политика: так называемая Jira и все творения террористической организации Атласиан - запрещены везде, где я присутствую.

- Я вынедрил Jira в десятках организаций
- Может, внедрил?
- Нет, именно вынедрил

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

Конфлюенс, например, полностью заменяется .md-файликами. Все это Atlassian-искусство построено вокруг одной идеи: они капитализируют бюрократию. Берут простое действие: написать текст, поставить задачу, обсудить изменение, слить ветку - и обмазывают его таким слоем интерфейсного цемента, что через год команда уже не создает продукт, а обслуживает инструмент.

Ревью кода и постановка ТЗ занимает много времени в программировании с AI и люди, естественно, пытаются переложить эту задачу тоже на AI. Пусть агенты друг-другу ТЗ пишут, друг-друга дрессируют и ревью делают. Так можно дойти и до кнопки "Сделай все хорошо", которая запускает бесконечный цикл. У вас не выйдет не тратить внимания на проект.

AI про ваши потребности не занет и мысли не читает. Идеи, приоритеты, контекст, критерии качества и продуктовые компромиссы он сам не определит. AI хорошо пишет только то, что уже много раз кем-то писалось. Если убрать из процесса человеческое внимание, вы не ускорите проект - вы просто зациклите галюцинирование.

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

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

Агенты постепенно мимикрируют под программистов. Текущие костыли - временные. Скоро процесс внешне перестанет отличаться от работы с людьми: у каждого инструмента появятся агентные аналоги и взаимозаменяемость. А человек пока скачет вокруг с бубном, пытаясь найти свое органичное место в этой системе.

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