Классическая пирамида объясняет, каких тестов должно быть больше, а каких меньше, но не показывает, на каком этапе и в каком окружении каждая проверка происходит. Я предлагаю посмотреть на неё через пайп-лайн, окружение, тип проверки.
Попробуем представить ситуацию: очередной человек за очередные два вечера написал с помощью очередного ИИ очередной магазин, пусть будет магазин кормов для кошек. Магазин работает, человек счастлив, новая эра разработки наступила. Теперь остается дело за малым - посмотреть, как оно вообще будет работать, что произойдет после того как автор решит в нем что-то поменять. И здорово было бы, чтобы к тому моменту, когда после добавления скидки пропадёт самовывоз - автор ещё не закончил рассказывать, сколько программистов больше не понадобится. При этом сам инструмент действительно годный. И желание попробовать его вообще везде вполне понятно: интересно же, что ещё получится. Опять же, нередко возникает момент, когда человек ещё не закончил пробовать, но уже начал делать делать далеко идущие прогнозы. Получается как с автополивом - вода из шланга течет, помидоры растут, при чем - сами. Только между "я настроил автополив" и "агрономы больше не нужны" всё-таки есть некоторая разница. И как будто бы, она не настолько неуловима.
Как шаг за шагом организовать процесс внедрения статического анализа по ГОСТ Р 71207—2024: рассказываем простыми словами с отсылками на соответствующие пункты стандарта. Статья будет полезна компаниям, планирующим внедрять разработку безопасного ПО (РБПО) или проходить сертификацию по методике ВУ и НДВ ФСТЭК России.
В прошлой статье я писал, что компилятор — первый ревьюер кода, который написал агент. У этой идеи есть слепое пятно, и я в него наступил: конкурентность. Компилятор проверяет типы, go vet проверяет десяток известных шаблонов, -race ловит гонки данных. А горутина, которая никогда не завершится, — это не ошибка типов и не гонка. Код, который не слышит отмену, — тоже.
Джунам постоянно что‑то советуют: учиться, задавать вопросы, разбираться в чужом коде (хотя бы в своем…), постоянно развиваться. В это время junior: когда уже просто получать зарплату, которую обещали на курсе?
Предлагаю альтернативный путь: никакого развития через дискомфорт, признания ошибок и прочих плюшек найма! Только уверенность в себе и шесть простых правил, которые помогут надолго сохранить статус начинающего специалиста.
Нейросети с нами надолго. Даже если вдруг исчезнут OpenAI, Anthopic, Z.ai и прочие, мой личный Qwen 3.8 27B никуда не денется. Вопрос - a что с этим делать? Как разрабатывать софт в новую эпоху?
Можно делать вид, что разработка не изменилась, но это - отрицание реальности. Можно продолжать работать без нейросетей, но новое поколение уже к ним пристрастилось, и ближайшее время с этой иглы не слезет.
Есть такой университетский предмет, который все давненько подзабыли (а люди с ИТ-курсов его и в глаза не видели): "методология разработки программного обеспечения". Разработка хорошего ПО - это всегда вопрос методологии. Это и общие принципы архитектуры, и дисциплина работы, и возможность передать работу соседу, разделить между несколькими людьми, признать нечто готовым или не готовым. Без методологии разработка стремительно теряет управляемость.
Как сейчас.
Давайте разбираться, куда мы можем двинуть методологию в мире, где нейросети стали неотъемлемой частью разработки. Как в современную эпоху агентов писать рабочий код.
Использование локальных агентов для сбора, саммаризации и валидации требований в закрытом контуре. Инструменты: агент-опросник, извлечение переписки, расшифровка встреч, RAG-поиск по Confluence, агент-контролёр.
ИИ очень сильно изменил то, как мы пишем код, и этот процесс всё ещё продолжается. Мы пробуем разные подходы и ищем более эффективные способы работы. Агенты позволяют писать код быстрее, но по мере роста их автономности понимание проекта людьми уменьшается.
Я хочу рассказать о том, как я использую потерю понимания как сигнал обратной связи. Так я решаю, когда можно делегировать ИИ больше, а когда нужно замедлиться и разобраться.
Как дать LLM разбирать сбои в пайплайнах, не открывая ей доступ к сырым логам и произвольным SQL-запросам
Нередко для описания хромых кодовых баз используют метафоры вроде «тонущий корабль». Я же считаю, что эта аналогия ошибочна. Бизнес начинает тонуть задолго до того, как код достигнет гипотетического дна. Технический долг нельзя свести к банкротству, чтобы начать с чистого листа. Именно поэтому подобные метафоры, подразумевающие достижение некоего конца, лишь создают ложное чувство спокойствия.
Программное обеспечение существует в умозрительной сфере. Его нельзя сравнивать со зданием или мостом, которые находятся в физическом мире, где вы можете их полноценно видеть и осязать. Если вы продолжите бесконечно добавлять в здание этажи и комнаты, оно в конечном итоге рухнет. Но у ПО нет такого жёсткого предела. Код всегда можно сделать ещё хуже. Всегда можно внести очередной слой абстракции или ещё больше ослабить производительность.
Я делаю систему, которая собирает черновики производственных инструкций. В ней есть детектор опасных формулировок — и он исправно срабатывал на фразе «убедиться, что в зоне движения нет людей». То есть на правиле техники безопасности, как на его нарушении.
Починил и задумался: а остальные шестьдесят проверок качества что-нибудь измеряют? Написал инструмент, который портит документы изнутри схемы и смотрит, какие проверки реагируют. Тридцать не реагируют ни на что.
Дальше оказалось, что этот инструмент сам имел слепую зону, его отчёт считал не проверки, а строки, которые они печатают, а пороги из конфига в код не попадали. Семь уровней, и на каждом одно: проверка выглядит рабочей и не работает.
Что происходит, когда команда оценивает задачу до знакомства с чужим кодом? В нашем случае это приводило к оптимистичным срокам, неожиданным A/B-реализациям, повторным итерациям ТЗ и багам, которые обнаруживались уже на тестировании.
Мы добавили Tech Discovery — раннее исследование кода до финализации требований, дизайна и оценки. В статье расскажу, для каких задач этот процесс окупается, сколько времени занимает, какие результаты должна получить команда и чем наш подход отличается от обычного технического spike.
На выборке из семи задач TTM средних и сложных проектов сместился с диапазона 1,5–3 месяца к 1–2 месяцам, а количество профильных багов на эпик — с 6–12 до 4–9.
Класс без единого поля занимает 24 байта, с двумя полями int — те же 24, а с тремя — уже 32.
В структуре достаточно поменять местами два поля, и её размер уменьшится с 24 байт до 16, а обход массива ускорится в 1,8 раза.
В первой части мы разобрали, как Dart отличает число от объекта, а во второй – как убирается молодое поколение. Там все держалось на одном приеме: живых переносим в соседнее полупространство, а всю старую половину выбрасываем целиком.
Почему в старом поколении переезд не подходит
В молодом поколении все было просто – отбрасываем мертвые объекты и забываем про них, в старом поколении все по-другому. Для старого поколения такая операция слишком дорогая. Количество живых объектов больше, чем неживых, а это значит, что нам бы пришлось копировать почти всю память с места на место. Также необходимо было бы держать вторую половину пространства запасам такого же размера как и занятую часть полупространства. Для решения этой проблемы существует mark-sweep (Пометка-очистка).
Скиллы превращают обычного ИИ-агента в узкопрофильного спеца: он ищет инфу в интернете, работает с файлами, пишет код, анализирует данные, запускает задачи в сторонних сервисах.
В этой подборке я собрал 50 самых популярных скиллов для ИИ-агентов - вместе они набрали 9 млн звезд на GitHub и 22 млн установок.
Используйте бесплатно.
Для каждого скилла указал, что он умеет, где пригодится и команду для быстрой установки.
Патч был на две строки: правка в проверке прав доступа. На ревью читается ровно то, что задумано, — апрув, мёрж. Через день выясняется, что проверка не срабатывает, хотя код перед глазами правильный.
На ревью смотрят глазами. Глаз видит символы так, как их нарисовал шрифт, а интерпретатор читает байты. Между этими двумя представлениями есть зазор, и в него помещается логика, которую при чтении кода не видно.
Этим зазором пользуются двумя способами, и оба закрываются одной проверкой.
Нейронке сказали — «разберись как оно работает». Пошевелив гигабайтами матриц, она полезла ковырять список классов в AppleNeuralEngine.framework— и нашла там то, что искала — «40+ private classes, including _ANEInMemoryModel». Код работал. Делал то что от него требовалось — запускал математику на ANE. Но было в этом что‑то… не то.
Строчка, которая встречается в скриптах повсеместно:
mysql -u admin -pSecretPass123 -e "select 1"
Пока команда выполняется, этот пароль видит каждый, у кого есть доступ к устройству — обычный, непривилегированный. Достаточно посмотреть список процессов.
В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.
Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?
После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.
Привет, Хабр! На связи Оля и Эрик из команды больших языковых моделей ecom.tech. Cегодня мы расскажем, как делали сервис для AI-ревью кода с встраиванием его в CI/CD пайплайн GitLab. Эта статья будет полезна тем, кто разрабатывает агентов для работы с кодом (и не только), а также кто хочет поближе познакомиться с ассортиментом граблей, на которые можно наступить при внедрении этого самого AI в производственные процессы.
