Программу проката дописывают агентами под выдачу, возврат и повреждения каждого экземпляра

Список клиентов и договоров ещё не отвечает на вопрос, какой именно перфоратор доступен. Если вы выбираете между готовым продуктом и своей CRM, проверяйте предметный учёт раньше оформления карточек: можно ли найти экземпляр, увидеть его состояние и выдать его без пересечения с другой арендой.

Rent in Hand, «Учёт Проката» и EasyPro уже продают программы учёта аренды. Мы прочитали их официальные страницы 7 октября 2026. В частности, «Учёт Проката» заявляет фото, серийные номера, запрет двойной выдачи и отправку повреждённого инструмента в ремонт. Нельзя обосновывать заказ разработки тем, что готовые программы всего этого не умеют.

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

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

Для выдачи нужен устойчивый идентификатор: серийный номер или внутренний номер, если заводской маркировки нет. К нему привязывают комплектность, точку хранения, аренду и фото перед передачей. П-017 здесь придуман для проверки, это не номер из клиентской базы.

Фото до выдачи и фото после возврата должны оставаться разными записями. Если новое фото заменяет старое, сравнивать уже нечего. Сотрудник фиксирует обнаруженное повреждение и результат осмотра; программа сохраняет автора и время действия. Кадр сам по себе не устанавливает, кто виноват и сколько должен заплатить.

У экземпляра есть физическое состояние и календарь аренды. Даже исправную вещь нельзя обещать на пересекающийся срок. Даже свободный календарь не разрешает выдать повреждённую вещь. Для П-017 возврат закрывает передачу клиенту, осмотр отмечает повреждение, ремонт сохраняет блокировку. Готовность подтверждают отдельным действием.

Проверка «свободен ли?» только на экране не защищает от одновременной брони. Два сотрудника могут увидеть один свободный П-017. Решение о бронировании и сохранение занятости должны выполняться как одна операция на сервере: одному подтверждение, второму отказ с понятной причиной. Тот же запрет должен работать при брони через сайт или интеграцию.

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

Задача «сделайте программу проката» оставляет агенту выбор всего сразу. Постановка задачи агенту начинается с конкретного поведения: «После возврата с повреждением П-017 нельзя забронировать ни с рабочего экрана, ни с сайта. После ремонта и проверки можно, если даты свободны». Таблица выше становится частью приёмки.

До правки инженер выясняет, где можно менять поведение. В собственном приложении это репозиторий клиента. В чужом сервисе нужны разрешённое расширение или нужные операции API. Без такого доступа агенты не смогут дописать закрытый продукт.

«Учёт Проката» заявляет публичный API, EasyPro допускает изменение конфигурации. Это ещё не подтверждение, что конкретный запрос можно выполнить: границы выясняют с поставщиком.

Наш опыт относится к машине vibecoding.ru. Инженер ведёт машину агентов; на живом /open при чтении 7 октября было 7 063 коммита за 98 дней, с 1 июля 2026. Это счёт изменений основной ветки, не замер скорости разработки проката. Полезнее перенести в вашу задачу правила, которые появились после наших ошибок.

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

Инженер проверяет правку, владелец или назначенный сотрудник принимает цикл на тестовых вещах. Код и написанный самим агентом тест не заменяют приёмку: тест тоже может закрепить неверное правило. Разделение ролей разобрано в статье «Руководитель разработки и агенты». В нашем курсе этот порядок собирается в уроке «Одиннадцать шагов одной задачи».

Для разработки возьмите вымышленных клиентов и фотографии инвентаря без документов и людей. Если на реальных кадрах есть персональные данные, порядок их использования нужно разобрать отдельно: см. «Персональные данные и ИИ-агенты». Чтобы проверить готовность вашей команды к такому циклу, пройдите тест для руководителя.

Первый поток можно ограничить выдачей по номеру, фотографиями состояния и запретом повторной брони занятого или повреждённого экземпляра. Не нужно добавлять распознавание дефектов по фото, приложение кладовщика и обмен со всей бухгалтерией в ту же задачу. Для каждого из этих пожеланий нужны собственные правила и отдельная приёмка.

На странице /services 7 октября 2026 подписка «Один проект» стоит 250 000 ₽ в месяц: один продукт, один поток, одна задача в работе, следующая в очереди.

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

Месяц оплаты не обещает завершения всего проката за месяц. Объём старого кода, доступ к интеграциям и правила приёмки влияют на сроки разработки. Покупателю нужен список результатов первого цикла: что можно показать и что остаётся в репозитории после паузы. «Агенты много написали» для этой приёмки недостаточно.

После запуска собирайте причины отказов и расхождения состояния. Повторяющаяся ошибка становится следующей задачей с воспроизводимым примером. Инженер закрепляет правило проверкой; владелец смотрит, исчезло ли расхождение. Так у проката появляется обратная связь между рабочей сменой и разработкой.

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

1. Проверьте готовую программу на повреждённом возврате и повторной брони. Настройка может закрыть задачу без разработки.
2. Выберите один экземпляр и запишите его выдачу, фото, возврат, ремонт и подтверждение готовности. У модели товара своей истории повреждений нет.
3. Принимайте правку на конфликтных операциях. Проверка только рабочего экрана не доказывает запрет двойной брони через сайт.
4. Заберите код, проверки и список следующей работы. После запуска превращайте повторяющиеся расхождения состояния в новые проверяемые правила.