#aiassisted_development — Public Fediverse posts

React Native в 2026 году: New Architecture, нативный код и AI в реальном проекте

React Native по-прежнему часто описывают формулой «один код для iOS и Android». В 2026 году она звучит слишком просто. Современное приложение на React Native — это общий продуктовый слой на TypeScript, нативный интерфейс, Hermes, Fabric, JSI, фоновые процессы, platform-specific код и довольно много решений о том, где именно должна выполняться каждая задача . Мы столкнулись с этим в Synchra.24 — мобильном приложении для линейных и распределённых команд. В проекте больше тысячи TS/TSX-файлов и свыше ста экранов, но рядом с ними живут Kotlin и Swift: геопозиция, push-уведомления, биометрия, системные виджеты и работа с медиа. Это не история о функциях нашего продукта и не попытка его рекламировать. Это разбор того, чем на практике стала разработка на React Native к 2026 году — и какую часть этой работы действительно можно поручить нейросетям.

https://habr.com/ru/articles/1072522/

#React_Native_2026 #New_Architecture #Fabric #JSI #TurboModules #Hermes #Reanimated #Worklets #mobile_development #AIassisted_development

AIRepo: как проверить, готов ли ваш репозиторий к работе с AI-агентами

Coding agent может написать технически правильный код и всё равно сделать неправильное изменение. Причина не обязательно в модели или промпте. Репозиторий может содержать несколько правдоподобных источников, неявный ownership, устаревшие артефакты или доказательство, которое относится не к той ревизии. Для человека часть этих противоречий компенсируется контекстом команды. У агента этого контекста может не быть. Разбираю, почему репозиторий становится частью среды исполнения, где заканчиваются возможности AGENTS.md и файлов инструкций и как из этой проблемы появился open-source framework AIRepo . Читать разбор

https://habr.com/ru/articles/1071158/

#ai #agentsmd #repository #coding_agent #ai_agent #AIRepo #source_of_truth #software_engineering #aiassisted_development #agentic_development

AI‑assisted development в малом бизнесе: как я собрала систему обработки отзывов для ресторанной сети

Я маркетолог и до этого проекта не писала код. Но с помощью GPT собрала рабочую систему сбора, обработки и аналитики отзывов для ресторанной сети: 16 500 отзывов в одном контуре, более 9 500 записей в собственном хранилище, четыре XML-фида, мониторинг, автоответы и 130+ страниц документации. Все это обходится в 8,5К в месяц. Это кейс не только про AI-assisted development, но и про вполне прикладную пользу для бизнеса: меньше ручной работы, меньше пропусков и ошибок, единая аналитика и понятная стоимость эксплуатации. А заодно – честный разбор того, где AI действительно снижает порог входа в разработку, а где без человеческого контроля быстро начинает моросить.

https://habr.com/ru/articles/1060962/

#AIassisted_development #ChatGPT #автоматизация_бизнеспроцессов #Cloudflare_Workers #Cloudflare_D1 #serverless #ETL #интеграция_API #data_engineering #автоматизация_отзывов

Spec-driven development в микросервисах, часть 3: archspec investigate — исследование фичи до кода

Третья, заключительная статья из цикла. Часть 1 — где LLM теряет межсервисный контекст и почему локальных спек недостаточно. Часть 2 — archspec как контракт вместо свободного Markdown. Часть 3 — archspec investigate: исследование фичи, обновление контрактов и реализация. В части 1 я показал, что spec-driven development с LLM начинает ошибаться, когда фича проходит через несколько микросервисов: по отдельности каждый сервис выглядит аккуратно, а вместе система работает не так, как нужно. Модель теряет межсервисный контекст — правила, которые живут на границах между сервисами, не записаны в одном месте, и LLM их пропускает. В части 2 я собрал archspec : на каждый сервис генерируется машиночитаемый контракт SERVICE_MAP.yaml , который делает эти правила явными. В этой части я беру ту же фичу — автоматическое переназначение задачи после отказа фрилансера — и прогоняю её заново через /archspec:investigate , но уже поверх контрактов. Тот же промпт, та же модель (Claude Sonnet 4.6). Вопрос один: поймает ли план те межсервисные ошибки, на которых в первый раз фича не сошлась, ещё до написания кода — и где спотыкается уже сам инструмент. Что нашёл investigate и где отъехал код

https://habr.com/ru/articles/1046824/

#specdriven_development #aiassisted_development #claude_code #llm #микросервисы #архитектура_микросервисов #service_contracts #outbox_pattern #идемпотентность #code_review_ai

Как научить AI писать коммиты по правилам вашего проекта, а не Conventional Commits по умолчанию

Любой AI-инструмент умеет генерировать commit message. Проблема в том, что он генерирует что-то разумное — но не то, что принято в вашем проекте: не знает ваш формат с тикетами, не вытаскивает номер задачи из ветки, не учитывает какие типы у вас разрешены. В этой статье я покажу как один раз описать правила своего проекта так, чтобы AI следовал им предсказуемо — каждый раз. Основной пример на Claude Code, но паттерн и готовый скрипт переносятся на любой инструмент: Cursor, Copilot Chat, git hook с API-вызовом. Как заставить AI писать коммиты по правила

https://habr.com/ru/articles/1044636/

#git #commit_message #claude_code #llm #prompt_engineering #автоматизация #инструменты_разработчика #git_hooks #aiassisted_development #developer_
__experience

Spec-driven development в микросервисах, часть 2: как archspec делает контекст сервисов явным

В первой части я разбирал, почему spec-driven development начинает ошибаться, когда фича проходит через несколько микросервисов. Проблема не в том, что LLM плохо читает код или не умеет писать спеку. На уровне отдельных сервисов всё может выглядеть аккуратно: есть описание, план, реализация и тесты. Но правила, которые связывают сервисы между собой, часто не записаны в одном месте. Часть таких правил спрятана в реализации, часть известна только команде, а часть всплывает уже на ревью. Обычный Markdown не решает эту проблему: его легко написать неполным, сложно проверить автоматически и почти невозможно ревьюить как структурный контракт. Отсюда родилась идея: нужен машиночитаемый контракт на каждый сервис, который фиксирует межсервисные правила, проверяется на коммите и даёт LLM структурный контекст вместо набора Markdown-файлов. Для этого я собрал open source плагин для Claude Code — archspec . В этой части я покажу, как работает /archspec:init на одном сервисе из демо-проекта freelance-marketplace , разберу сгенерированные артефакты и объясню, как archspec поддерживает их в актуальном состоянии. Напомню, это Go-проект с 12 микросервисами для поиска фрилансеров. Вот схема сервисов, которую я использую на протяжении всего цикла: Как работает archspec

https://habr.com/ru/articles/1037988/

#specdriven_development #aiassisted_development #claude_code #llm #aiагенты #микросервисы #архитектура_микросервисов #docs_as_code #service_contracts #outbox_pattern

MemForge2: загрузочная флешка, которая за минуту говорит — какую планку памяти менять

Сегодня собирал HP EliteDesk 8300, четыре планки DDR3 по 2 ГБ. При первой загрузке — синий экран Windows. Стандартный сценарий: сейчас полчаса вытаскивать планки по одной, перезагружаться, выяснять какая сбойная. «Танцы с бубнами», которые каждый сервисник делал тысячу раз. Потом вспомнил, что у меня есть собственный инструмент ровно для этого. Воткнул флешку, прогон, минута — на экране большими буквами: REPLACE DIMM1, confidence HIGH . Чтобы убедиться что программа не «запоминает» слот а реально находит планку, переставил её в DIMM4. Прогон повторно — нашла её и в DIMM4, тот же серийник из SPD. Замена планки — BSOD больше нет. Я работаю на сборке ПК — и новых, и б/у. На б/у это типичная ситуация: всё собрано, провода уложены, включаешь — синий экран на загрузке. Метод исключения работает, но это перезагрузка за перезагрузкой, глубокий вдох перед каждой, час твоего времени уходит на то, что должна была бы решить минута. Мне нужен был инструмент, который сразу показывает где проблема — без часовых прогонов и без танцев со свапами планок. Готового с такой комбинацией возможностей я не нашёл, поэтому собрал свой. Сразу честно про авторство. Я не программист. Я сборщик. Код MemForge2 писал не я — его писал Claude (LLM от Anthropic) под мою постановку задачи. Я приходил с пониманием предметной области («нужно SPD через SMBus, серийник для гарантии, MCA‑снимок до/после, контекст в момент ошибки»), описывал что должна делать программа на конкретных кейсах со своей сборки, гонял каждую версию на реальном железе, ловил баги, возвращался с дампами и описаниями поведения. Claude писал C, разбирался с UEFI‑API, MSR‑ами, SMBus‑протоколом, SPD JEDEC‑стандартом.

https://habr.com/ru/articles/1039280/

#UEFI #memtest #диагностика_памяти #ремонт_ПК #SPD #DDR3 #DDR4 #DDR5 #Row_Hammer #AIassisted_development

SDD на масштабе FullStack-приложения: 17 спринтов, две конституции, три чата

В первой статье я писал про SDD на примере одного вечера. После чего прошёл 17 спринтов SDD на FullStack-приложении: B2C-трекер привычек и целей, два репозитория, 251 тест на бэке и 77 на фронте, релиз в продакшен. Здесь — что не дало мне потерять контроль на этом масштабе.

https://habr.com/ru/articles/1027886/

#specdriven_development #spec_kit #claude_code #aiassisted_development #fullstack #java #spring_boot #react #методология #architecture

Telegram-бот за вечер через Spec Kit: что AI-ассистированная разработка сделала с моим инженерным процессом

Я Java-разработчик: пишу на Java 5 лет. Последний месяц собираю портфолио через Spec-Driven Development — связку Spec Kit и Claude Code. Первый проект — Telegram-бот для задач. С шести вечера до двух ночи одного вторника я прошёл полный SDD-цикл от конституции до MVP с шестью командами. Восемь часов. Один вечер. Рабочий продукт. Но главное — что-то сдвинулось в моём инженерном процессе.

https://habr.com/ru/articles/1027250/

#specdriven_development #spec_kit #claude_code #ai_coding #aiassisted_development #telegram_bot #spring_boot #java #разработка #методология

[Перевод] Как кодинг-агенты используют инструменты, память и контекст репозитория, чтобы писать код лучше

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

https://habr.com/ru/articles/1021168/

#harness #харнесс #кодингхарнесс #кодинг #кодинг_ассистенты #aiassisted_development #harness_engineering #claude_code #codex #coding_cli

Я заменил целую команду разработки на ИИ. 0 рублей, 2 недели, 2 приложения

Меня зовут [неважно], я бизнес-аналитик. Моя работа — писать ТЗ, рисовать процессы в BPMN, ругаться с разработчиками из-за неправильно понятых требований и пить кофе на стендапах. За 5 лет в профессии я не написал ни одной строчки кода. Ни одной. Даже Hello World . В начале 2026-го я поймал себя на мысли, которая наверняка посещала каждого бизнес-аналитика: «Я точно знаю, что нужно сделать. Я подробно описываю как это должно работать. Единственное, чего я не могу — написать код». А потом я прочитал очередной пост про то, как кто-то с помощью ИИ создал приложение за выходные, и подумал: а что если моя профессия — это и есть идеальная подготовка к работе с ИИ-ассистентами? Спойлер: через 2 недели у меня было 2 приложения в RuStore, 0 рублей затрат и 14 скачиваний. Да, четырнадцать. Но обо всём по порядку.

https://habr.com/ru/articles/1017748/

#ИИразработка #Claude #Flutter #vibe_coding #промптинжиниринг #MVP #Supabase #AIassisted_development #rustore #GPT

Цена контекста в агентной разработке: почему bottleneck — не код, а внимание человека

Пока diff небольшой, в нас просыпается хранитель инженерной чистоты: мы спорим о нейминге, замечаем лишний пробел, обсуждаем, стоило ли выносить логику в helper , но когда правка разрастается до тысяч строк, строгость уступает другому подходу: CI зелёный, тесты прошли, код выглядит вроде неплохо - можно жать Approve . С coding-агентами проблема становится более системной. Пока задача небольшая и хорошо ограничена, результат ещё можно напрямую соотнести с исходным запросом, но при асинхронной и мультиагентной работе у каждого из агентов появляются собственные подзадачи, гипотезы и хвосты незавершённых решений. Поэтому, возвращаясь в процесс, человек проверяет уже не изолированные изменения, а заново восстанавливает состояние задачи - что именно было задумано, что уже проверено, какие инварианты теперь считаются действующими и где остался риск. И именно здесь ломается наивный human-in-the-loop , а большой diff - является лишь симптомом. Настоящее узкое место - стоимость повторного входа в контекст: формально человек остаётся в процессе, но фактически его роль всё чаще сводится к механическому одобрению, в свою очередь дефицитом становится не машинная производительность, а человеческое внимание. В прошлой статье о контекстной инженерии для coding-агентов я писал о памяти агента. Здесь - о том, какая память и какие механизмы контроля нужны уже человеку.

https://habr.com/ru/articles/1008344/

#мультиагентная_разработка #ИИагенты #agentic_AI #code_review #context_switching #humanintheloop #quality_gates #контекстная_инженерия #AIassisted_development

На одном собесе меня похвалили за то, что я не писал код. На другом — не зачли тестовое за то же самое

Сегодня утром я прошёл лайв-кодинг в одну англо-продуктовую компанию. Написал ноль строчек кода руками. Задеплоил результат на свою VPS прямо во время звонка. Интервьюер сказал: "It's so wonderful just how much everything has changed." А неделю назад другая компания не зачла мне тестовое, потому что я забыл про запрет AI. 20+ собесов за последние месяцы. Фронтенд, бэкенд, фулстек, AI-инженер. Python, TypeScript. Разные рынки, разные компании, совершенно разное отношение к одному и тому же инструменту. Я не теоретик, который рассуждает о будущем. Я прямо сейчас хожу на эти собесы и вижу, как рынок разламывается пополам.

https://habr.com/ru/articles/1004280/

#claude_code #вайбкодинг #собеседование #лайвкодинг #aiassisted_development #карьера_в_IT #искусственный_интеллект #aiагенты