Архитектор

Лютая дичь. Развитие технологий не зависят от взглядов и идеологий. Только вот мажоры и чиновники РФ почему то не отказываются от западных технологий, а стараются хвастануть ими друг перед другом. Если РФ не будет следовать НТП - то лет этак через 25, РФ будет сама запускать в космос с батута.

СЛАБЫЕ МЕСТА, ОШИБКИ И УСЛОЖНЕНИЯ
🔴 Критические проблемы
1. Tesseract.js — тяжёлая нагрузка на клиент.
Tesseract.js — это WASM-сборка (~10+ МБ). Запуск OCR на каждый ввод после 1200 мс дебаунса — это:

Высокое потребление CPU на мобильных устройствах.

Разряд батареи.

Задержки в UI, если OCR блокирует главный поток.

Решение: ленивая загрузка Tesseract, Web Worker для OCR, или замена на более лёгкий OCR (например, нативный API TextDetector в браузерах, где он есть).

2. Пасхалка «Avada Kedavra» — бесконечный while(true).
Автор называет это «самым честным эффектом», но это:

DoS-атака на собственный браузер пользователя.

На мобильных устройствах может привести к зависанию ОС, перегреву, потере несохранённых данных.

Браузер может пометить сайт как вредоносный.

Если пользователь не ожидал этого — это плохой UX, а не «фича».

Решение: заменить на имитацию краха (анимация, звук, сообщение), но без реального while(true). Или добавить явное предупреждение: «Этот эффект может замедлить браузер».

3. Отсутствие серверного rate limiting.
RateLimiterService на фронтенде — это UX-защита, а не безопасность. Любой может обойти его через DevTools или прямой запрос к Workers. Настоящий rate limiting должен быть на стороне Cloudflare Workers (через Durable Objects или KV).

Вероятностная машина... Правильно сформулированный вопрос... Не туда роете. Правильно составленная задача в промте и проверки ответа модели. Грамотно построенная архитектура. Вопрос абсолютно не должен ставить модель в тупик.

Как то всё свалено в кучу. Начнем с проекта. Нужно понимать, что лично ты хочешь, как проектировщик. Потом донести задачу до ассистента так, что бы он это понял. После этого создаём документацию проекта, где всё расписано. Идем в другой чат. Тащим документацию проекта, убеждаемся что ассистент понял. Даем задание... И это лишь малая часть одного из возможных вариантов реализации проекта. А если там несколько модулей, да кода строк на 10 000... Реально сделать всё. Главное - добиться от ассистента понимание задачи и ее выполнения.

Согласен. Данный спор не прийдет к одному знаменателю. Удачи.

Вы исказили суть - я вам старался донести - что информация первична и ее самоцель - проявить себя через устойчивую форму. Ваш агент всё переиначил. Далее - совершенно бессмысленно хранить "баги" в аду - для чего? Наказание без возможности исправления или как что??? Я мог бы позволить своему агенту использовать в диалоге собственную концепцию взгляда на все эти вещи - но опасаюсь - что диалог бы погряз в разборах формулировок, разборах самой концепции, объяснении всех ее нюансов.

Хорошо, зайдем с другой стороны. Кто вам мешает пользоваться бесплатными сильными моделями использовав обвязку из сильного промта? Опять же - слабая модель не справится с мощной обвязкой - она ее просто не осилит и вы получите на выходе бардак.

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

Писатель вообще не в теме ритуалки... Просто было на бумаге - но забыли про овраги...

Это упрощение - слабая модель, как и слабый Харнесс сыграют злую шутку. Всё зависит от решаемой задачи и конечной цели.