Искусственный интеллект сгенерировал рабочий вариант за 4 часа вместо недели работы. Звучит как успех, но когда передали код команде продуктовой разработки, выяснилось: около 60% пришлось переписывать. Нейросеть продублировала методы, которые уже существовали в других частях системы, проигнорировала архитектурные паттерны проекта и запихнула всю логику в один файл на 800 строк.
Вопрос: Почему так случилось, что можно сделать?
Ответ ИИ:
🤖 Почему ИИ подвёл команду (и как это исправить)
Ситуация классическая: ИИ отлично справляется с написанием кода в вакууме, но совершенно не чувствует контекст и архитектуру конкретного проекта. Для него ваша кодовая база — это «черный ящик», если вы не дали к нему доступ.
🚩 Почему это произошло?
Отсутствие контекста: Нейросеть видела только вашу задачу, но не знала о существовании готовых методов в других файлах. Она «изобрела велосипед», потому что не знала, что он уже стоит в гараже.
Проблема «длинного контекста»: ИИ проще выдать результат в одном файле, чем проектировать связи между десятью модулями. Разрезание логики на части требует понимания структуры папок и правил импорта, которые вы, скорее всего, не описывали в промпте.
Отсутствие Linter-ов и правил: ИИ не знаком с вашим стайл-гайдом или архитектурными паттернами (например, SOLID или Clean Architecture), если они не прописаны в системных инструкциях.
🛠 Что можно сделать?
Контекстная подача (RAG для кода): Используйте инструменты вроде Cursor или плагины (например, GitHub Copilot с индексацией репозитория). Они позволяют ИИ «читать» весь проект перед генерацией, что резко снижает дублирование функций.
Метод «Сначала архитектура»: Не просите ИИ сразу писать код. Сначала попросите его составить план реализации: какие файлы создать, какие методы использовать. Команда должна утвердить этот план, и только потом давать команду на генерацию по частям.
Модульные промпты: Разбивайте задачу. Вместо «напиши фичу» говорите: «Используй метод X из файла Y, создай новый класс в папке Z и вынеси бизнес-логику в отдельный сервис».
Спецификации (Rules): Создайте файл .cursorrules или аналогичный, где жестко прописаны правила:
«Не писать файлы длиннее 200 строк»
«Использовать только Dependency Injection»
«Всегда проверять папку /utils на наличие дублей»
Хотите подберем конкретные инструменты или настроим шаблон системного промпта, чтобы ИИ соблюдал ваши архитектурные правила?
Заменить классический текстовый стек (HTML/CSS) на компактный бинарный формат данных (назовем его BDOM — Binary Document Object Model). Сервер или Брокер конвертирует входящие данные в типизированные структуры, которые Skia отрисовывает напрямую, минуя тяжелые текстовые парсеры.
Требование: Использование сериализованных структур (например, FlatBuffers или кастомный двоичный протокол) для передачи дерева элементов от Брокера к Рендереру.
Критерий успеха: Скорость десериализации страницы в Рендерере должна быть в 10–50 раз выше, чем парсинг аналогичного HTML/CSS в LiteHTML.
BR-B2: Безопасность через типизацию (Binary Security)
Требование: Исключить возможность текстовых инъекций. Бинарный формат должен строго определять типы данных (размер шрифта — int, цвет — uint32, координаты — float).
Критерий успеха: Полная невозможность выполнения классических XSS-атак, так как данные в принципе не интерпретируются как исполняемый код или скрипт.
BR-B3: Экономия трафика (Bandwidth Optimization)
Требование: Бинарный документ должен занимать на 40–70% меньше объема, чем эквивалентный HTML-код, за счет отсутствия тегов, кавычек и дублирующихся строк.
Критерий успеха: Возможность комфортной работы браузера на каналах связи от 64 кбит/с.
BR-B4: Нативный мапинг на Skia (Rendering Alignment)
Требование: Структура бинарного документа должна максимально соответствовать командам рисования Skia (Draw Calls).
Критерий успеха: Рендерер должен начинать отрисовку первого кадра (First Meaningful Paint) сразу после получения первых байтов бинарного потока, не дожидаясь закрывающего тега.
3. Технологический стек реализации
Формат данных: FlatBuffers (позволяет обращаться к данным в памяти без распаковки) или Protobuf.
Конвертер (Proxy): Специальный сервис (или модуль в Брокере), который берет "грязный" HTML из сети и "выпрямляет" его в чистый бинарный BDOM.
Рендерер: Облегченная версия вашего приложения, где вместо LiteHTML стоит BDOM-Reader, вызывающий методы Skia.
4. Преимущества для бизнеса
Уникальность: Это не просто очередной браузер, а закрытая экосистема с высочайшим уровнем защиты.
Экономия: Снижение затрат на серверные мощности и трафик.
Контроль: Вы полностью контролируете, какие элементы могут быть отображены, а какие — нет.
Ваш браузер будет в 10–20 раз компактнее Chromium-решений (Electron/QtWebEngine), так как в нем отсутствуют тяжелые зависимости и избыточные компоненты.
1. Вес компонентов (Static Linkage)
При статической сборке всех модулей в один или несколько бинарников:
Minimal (Core + UI): Только Skia и LiteHTML. Вес ~20–25 МБ.
Standard (Core + JS): Добавляется модуль QuickJS. Вес ~26 МБ.
Gaming Edition (Full): Включает рантайм Godot для плагинов. Вес ~45 МБ.
3. Методы оптимизации размера
LTO (Link Time Optimization): Удаление неиспользуемых частей Skia (например, PDF-рендерера или редких кодеков) экономит до 30% веса.
Strip Symbols: Удаление отладочной информации (strip --strip-all) уменьшает бинарник в 2-3 раза.
System Libraries: Если линковать fontconfig, freetype и openssl динамически (использовать системные в Linux), размер упадет до 10–15 МБ.
UPX Compression: Сжатие финального исполняемого файла может довести размер до невероятных 8–12 МБ (с небольшой задержкой при распаковке в RAM при старте).
4. Сравнение с конкурентами
Google Chrome: ~350 МБ
Pale Moon: ~40 МБ
Dillo (старый легкий браузер): ~2 МБ (но без Skia и Godot)
Ваш проект:~35 МБ (современная графика + игры + безопасность).
План реализации опционального модуля JavaScript (QuickJS + IPC Isolation)
Чтобы сохранить безопасность, JS-движок выносится в отдельный процесс. Он не имеет прямого доступа к памяти рендерера или сети.
1. Архитектурная схема взаимодействия
[ UI/Render Process (LiteHTML) ] <--- IPC (Unix Socket) ---> [ JS Runtime Process (QuickJS) ]
^ ^
| |
[ Broker Process ] <-------------------------------------------------
2. Этапы реализации
Этап 1: Интеграция QuickJS (1-2 недели)
[ ] Сборка QuickJS как статической библиотеки внутри изолированного бинарника-воркера.
[ ] Создание основного цикла (Event Loop) в JS-процессе для обработки входящих сообщений.
[ ] Реализация базовых функций console.log и setTimeout через проброс сигналов в Broker.
Этап 2: Протокол DOM Bridge (2 недели)
[ ] Зеркалирование DOM: LiteHTML при парсинге создает упрощенную карту ID элементов и передает её в QuickJS.
[ ] Proxy Objects: Создание в QuickJS объектов-оберток (например, document.getElementById), которые при вызове методов генерируют IPC-сообщение (например, SET_STYLE, CHANGE_TEXT).
[ ] Событийная модель: Рендерер ловит клик -> отправляет ID элемента в JS-процесс -> QuickJS запускает привязанный onclick обработчик.
Этап 3: Интерфейс управления (1 неделя)
[ ] On-Demand Activation: Реализация кнопки в Skia UI для запуска/убийства процесса js_worker для конкретной вкладки.
[ ] Permissions: Настройка прав (разрешить ли JS доступ к буферу обмена или геопозиции через запрос к Broker).
Этап 4: Изоляция NsJail (1 неделя)
[ ] Sandboxing: Конфигурация NsJail для JS-процесса с null сетевым интерфейсом и пустой файловой системой.
[ ] Seccomp: Максимальное ограничение системных вызовов (только read/write в сокет, brk/mmap для памяти).
3. Технические детали (Технологии)
Движок: QuickJS (поддержка ES2023, малый вес ~1MB).
Транспорт: Unix Domain Sockets (тип SOCK_SEQPACKET для сохранения границ сообщений).
Сериализация: Simple Binary Protocol или FlatBuffers (для минимальных задержек при передаче изменений DOM).
4. Итоговая логика работы
Пользователь заходит на сайт (JS выключен, работает только LiteHTML).
Нажимает "Разрешить JS".
Broker запускает NsJail + QuickJS.
QuickJS запрашивает скрипты у Broker -> выполняет их -> шлет команды на обновление в Render Process.
Будут ли пользователи пользоваться таким браузером?
Ответ зависит от позиционирования. Без поддержки JavaScript 90% современного интернета (соцсети, банки, видеохостинги) не будут работать. Однако этот проект занимает уникальную нишу.
1. Целевая аудитория (Кто придет?)
Любители "Minimal Web": Те, кто читает Wikipedia, блоги, документацию и новостные ленты. Для них отсутствие JS — это плюс (нет рекламы, нет слежки, мгновенная загрузка).
Секьюрити-гики: Люди, работающие с конфиденциальной информацией, которым нужна "стерильная" среда для чтения текстов, где выполнение кода невозможно физически.
Геймеры и инди-разработчики: Если вы создадите каталог Godot-игр, пользователи будут использовать браузер как легкий игровой клиент (аналог Flash-плеера нового поколения).
Владельцы слабого железа: Пользователи старых ноутбуков и Raspberry Pi, на которых Chrome потребляет всю память.
2. Ключевые преимущества для пользователя
Мгновенный отклик: Благодаря Skia и отсутствию тяжелого JS-движка, интерфейс и страницы будут летать.
Безопасность: Архитектура с NsJail гарантирует, что даже если страница попытается атаковать систему, она останется заперта в "песочнице".
Идеальная типографика: Использование Skia позволяет сделать чтение длинных текстов максимально комфортным (субпиксельное сглаживание, кастомные шрифты).
3. Что нужно сделать, чтобы удержать пользователя?
Качественный UI: Сделать интерфейс на Skia более красивым и плавным, чем у современных браузеров.
Каталог контента: Встроить "магазин" или список Godot-плагинов прямо в стартовую страницу.
Reader Mode: Сделать упор на идеальный режим чтения, который переверстывает "кривые" сайты в удобный текстовый вид.
4. Главный риск
Современный CSS: LiteHTML поддерживает не все свойства Flexbox и Grid. Если верстка популярных текстовых сайтов (например, GitHub или StackOverflow) будет ломаться, пользователи уйдут.
Вердикт:
Это не замена основному браузеру, а "Второй браузер" для безопасного чтения и легких игр. Как инструмент для специфических задач или как платформа для инди-игр проект имеет высокий потенциал.
Ниже представлен подробный анализ статьи Сергея Кушниренко (dalerank) «О радости программирования и невесомости достижений», опубликованной на Хабре.
Основная идея и тезис
Автор размышляет о фундаментальном сдвиге в профессии программиста в эпоху ИИ. Главный тезис заключается в том, что автоматизация генерации кода (Copilot и аналоги) ускоряет работу, но обесценивает результат и разрушает глубокую когнитивную связь разработчика с его продуктом.
Ключевые темы анализа
1. Утрата «состояния потока» и тактильной радости
Автор выделяет два важных аспекта, которые уходят вместе с ручным написанием кода:
Когнитивное погружение: Раньше программирование сопровождалось состоянием глубокой концентрации (потока), когда мозг удерживал всю архитектуру целиком.
Физический аспект: Описывается удовольствие от ритма печати на клавиатуре, который помогал мыслить. Переход к текстовым промптам делает процесс абстрактным и «неживым».
2. Проблема «чужого кода» и интуиции
Один из самых практических выводов статьи касается отладки:
Ментальная карта: При ручном написании кода у разработчика формируется подробная модель системы в голове. Это позволяет чинить баги почти интуитивно.
Поверхностное владение: Код, сгенерированный ИИ, даже после ревью остается «чужим». При возникновении ошибок разработчик вынужден изучать его с нуля, так как он не «прожил» процесс его создания.
3. Эволюция роли программиста
Автор не отрицает прогресс, но прогнозирует изменение фокуса профессии:
От строк к архитектуре: Мастерство теперь смещается в сторону проектирования сложных систем на высоком уровне абстракции и умения задавать точные вопросы.
Риск превращения в оператора: Существует опасность потерять творческую искру и превратиться в простого «оператора чужих систем», если полностью делегировать созидание ИИ.
Эмоциональный тон
Текст пронизан ностальгией и легкой тревогой. Автор называет себя представителем «вымирающего поколения», для которого программирование было ремеслом. При этом он признает неизбежность изменений и пытается найти свое место в новой реальности.
Резюме
Статья является философским размышлением о том, что «полезное трение» (борьба с кодом) — это не лишняя трата времени, а необходимый механизм обучения и получения профессионального удовлетворения.
Пользователь:
да (в ответ на предложение составить список аргументов «за» и «против»)
Ассистент:
На основе статьи можно выделить следующие аргументы «за» и «против» использования ИИ в разработке:
Аргументы «ЗА» (Польза ИИ)
Скорость и производительность: ИИ избавляет от рутинного написания шаблонного кода (boilerplate), позволяя получать результат за секунды.
Снижение порога входа: ИИ помогает быстро разобраться в новых технологиях или языках, давая рабочие примеры «здесь и сейчас».
Фокус на архитектуре: Программист освобождается от «микро-менеджмента» строк кода и может сосредоточиться на проектировании системы в целом.
Ликвидация «страха чистого листа»: Нейросеть всегда дает базу, от которой можно оттолкнуться, ускоряя начало работы над задачей.
Аргументы «ПРОТИВ» (Риски и потери)
Отсутствие «ментальной карты»: Когда код пишет ИИ, разработчик не пропускает его через себя. В случае бага он тратит больше времени на понимание «чужого» решения, чем потратил бы на написание своего.
Утрата состояния потока: Исчезает глубокое погружение в задачу. Процесс превращается в прерывистое «чтение-правку-промпт», что мешает достижению высокой концентрации.
Обесценивание результата: Достижения, полученные слишком легко, не приносят профессионального удовлетворения и чувства мастерства («невесомость достижений»).
Атрофия навыков: Без регулярной практики решения сложных задач «вручную» мозг теряет способность находить нестандартные решения и выстраивать сложные логические связи.
Иллюзия понимания: Разработчик может одобрить сгенерированный код, который выглядит рабочим, но содержит скрытые архитектурные изъяны, которые проявились бы только в процессе вдумчивого написания.
Пользователь:
дать оценку выводов автора
Ассистент:
Выводы автора можно оценить как глубоко рефлексивные, психологически точные, но в некоторой степени консервативные. Вот детальный разбор:
1. Объективность и точность (Психология и когнитивистика)
Здесь автор абсолютно прав. Существует доказанная связь между «трудностью» процесса и качеством запоминания/понимания (эффект генерации). Когда мы создаем что-то сами, нейронные связи строятся иначе, чем при пассивном потреблении или редактировании. Вывод о потере «ментальной карты» — это самый сильный и практически важный аргумент статьи.
2. Профессиональная ценность (Ремесло vs Индустрия)
Автор смотрит на программирование как на ремесло (craftsmanship). С этой точки зрения его выводы о потере «радости» верны. Однако с точки зрения бизнеса, программирование — это производство продукта. Для индустрии переход от ручного труда к ИИ-конвейеру — это естественная эволюция (как переход от ткацких станков к фабрикам). Автор фиксирует боль «мастера», чей уникальный навык становится массовым и дешевым.
3. Риск элитизма
Вывод о том, что программисты станут «архитекторами», подразумевает, что порог входа в высшую лигу станет еще выше. Это может привести к разделению на узкую прослойку «тех, кто понимает, как всё работает» и огромную массу «операторов промптов», которые не смогут починить систему без подсказки ИИ. Это опасный, но реалистичный прогноз.
4. Эмоциональный аспект
Термин «невесомость достижений» — это блестящее описание проблемы современного дофаминового цикла. Если результат дается слишком легко, мозг не фиксирует его как победу. Это может привести к массовому выгоранию из-за отсутствия чувства самореализации, даже если KPI выполняются.
Итог оценки:
Автор зафиксировал экзистенциальный кризис профессии. Его выводы — это не «брюзжание старого программиста», а предупреждение о том, что вместе с ростом эффективности мы теряем устойчивость знаний и психологическую вовлеченность. Это цена, которую индустрия готова платить за скорость, но каждый разработчик лично должен решить, готов ли платить её он.
Пользователь:
что можно предпринять для устранения рисков и потерь?
Ассистент:
Для устранения рисков, описанных в статье, важно вернуть в работу «осознанность» и не позволять ИИ полностью подменять когнитивный процесс. Вот конкретные стратегии:
1. Стратегия «Сначала проект, потом код»
Что делать: Перед использованием ИИ спроектируйте решение на бумаге или в Miro. Пропишите логику взаимодействия компонентов.
Результат: Вы сохраняете роль архитектора, а ИИ становится лишь «руками».
2. Принудительное ревью (The "Why" Check)
Что делать: Никогда не копируйте код бездумно. Задавайте себе вопрос: «Почему ИИ выбрал именно этот алгоритм?». Попробуйте объяснить логику вслух.
Результат: Код переходит в категорию «проверенный и понятый».
3. Метод «Слепого набора» для обучения
Что делать: Если ИИ выдал новое для вас решение, не нажимайте Tab. Перепишите его вручную, глядя на экран.
Результат: Включается моторная память, что возвращает «полезное трение».
4. Создание «зон без ИИ»
Что делать: Выделяйте блоки времени (например, 1-2 часа в день) на задачи, которые вы решаете строго без Copilot.
Результат: Тренировка мозга в режиме высокой концентрации.
5. Использование ИИ как «Оппонента»
Что делать: Сначала напишите свое решение, а затем попросите ИИ найти в нем ошибки или предложить альтернативу.
Результат: Вы остаетесь ведущим в процессе.
Пользователь:
да (в ответ на предложение составить чек-лист для проверки сгенерированного кода)
Ассистент:
Чек-лист: Присвоение кода (от «Чужого» к «Своему»)
1. Уровень логики (The "How" Check)
[ ] Пошаговое чтение: Я могу объяснить каждую строку кода вслух?
[ ] Edge Cases (Крайние случаи): Что произойдет, если на вход придет null или пустой массив?
[ ] Лишний балласт: Нет ли здесь ненужных универсальных оберток?
2. Уровень интеграции (The "Where" Check)
[ ] Контекст проекта: Соответствует ли стиль именования и обработки ошибок моему проекту?
[ ] Зависимости: Не подтянул ли ИИ лишние или запрещенные библиотеки?
[ ] Дублирование: Не реализует ли этот код то, что уже есть в проекте?
3. Уровень безопасности и чистоты
[ ] Магические константы: Все ли вынесено в конфиги?
[ ] Безопасность: Нет ли потенциальных уязвимостей?
[ ] Производительность: Какая сложность у этого алгоритма (Big O)?
4. Финальный тест на владение
[ ] Готовность к багам: Если код упадет ночью, я смогу починить его за 5 минут без ИИ?
[ ] Ручная правка: Я внес хотя бы одно минорное изменение (переименование, комментарий), чтобы зафиксировать свое участие?
Пользователь:
этот чек лист может выполнять ИИ? что можно переложить на ИИ?
Ассистент:
Использование ИИ для проверки ИИ полезно, но имеет ограничения.
1. Что МОЖНО переложить на ИИ:
Поиск Edge Cases: Попросите найти 5 сценариев, при которых код сломается.
Анализ сложности: Расчет Big O сложности алгоритма.
Соответствие стайлгайду: Приведение кода к стандартам проекта.
Безопасность: Поиск явных уязвимостей.
Генерация тестов: Написание Unit-тестов для проверки логики.
2. Что КАТЕГОРИЧЕСКИ нельзя отдавать ИИ:
Пошаговое чтение: Только ваш мозг должен пропустить через себя логику для построения ментальной карты.
Контекст проекта: ИИ не знает архитектурных «договоренностей» вашей команды.
Готовность к багам: Ответственность за понимание лежит на вас.
Итоговая схема: ИИ генерирует и технически проверяет код, а вы выполняете финальную «приемку» и когнитивное присвоение.
Долгосрочная стратегия: Руководство компании, включая директора по персоналу Никл ЛаМоро (Nickle LaMoreaux), считает, что отказ от найма младших специалистов разрушает «конвейер талантов». Без набора новичков сегодня компания может столкнуться с нехваткой опытных руководителей через 5 лет.
Откуда у вашего Пети, зарабатывающего 300к, столько свободного времени, чтобы ежедневно столько денег тратить? И как употребление кальяна сочетается с зарабатыванием 300к, оно же мозги гарантированно убивает, как и алкоголь?
В книге "Пирс, Типы в языках программирования", в главе 1.5 можно найти: "Основания семантики типов в рамках математической теории категорий (category theory) можно найти во множестве источников, включая книги Якобса (Jacobs, 1999), Асперти и Лонго (Asperti and Longo, 1991) и Кроула (Crole, 1994); краткое введение имеется в «Основах теории категорий для специалистов по информатике» («Basic Category Theory for Computer Scientists», Pierce, 1991a)."
Вопрос:
Почему так случилось, что можно сделать?
Ответ ИИ:
🤖 Почему ИИ подвёл команду (и как это исправить)
Ситуация классическая: ИИ отлично справляется с написанием кода в вакууме, но совершенно не чувствует контекст и архитектуру конкретного проекта. Для него ваша кодовая база — это «черный ящик», если вы не дали к нему доступ.
🚩 Почему это произошло?
Отсутствие контекста: Нейросеть видела только вашу задачу, но не знала о существовании готовых методов в других файлах. Она «изобрела велосипед», потому что не знала, что он уже стоит в гараже.
Проблема «длинного контекста»: ИИ проще выдать результат в одном файле, чем проектировать связи между десятью модулями. Разрезание логики на части требует понимания структуры папок и правил импорта, которые вы, скорее всего, не описывали в промпте.
Отсутствие Linter-ов и правил: ИИ не знаком с вашим стайл-гайдом или архитектурными паттернами (например, SOLID или Clean Architecture), если они не прописаны в системных инструкциях.
🛠 Что можно сделать?
Контекстная подача (RAG для кода): Используйте инструменты вроде Cursor или плагины (например, GitHub Copilot с индексацией репозитория). Они позволяют ИИ «читать» весь проект перед генерацией, что резко снижает дублирование функций.
Метод «Сначала архитектура»: Не просите ИИ сразу писать код. Сначала попросите его составить план реализации: какие файлы создать, какие методы использовать. Команда должна утвердить этот план, и только потом давать команду на генерацию по частям.
Модульные промпты: Разбивайте задачу. Вместо «напиши фичу» говорите: «Используй метод X из файла Y, создай новый класс в папке Z и вынеси бизнес-логику в отдельный сервис».
Спецификации (Rules): Создайте файл
.cursorrulesили аналогичный, где жестко прописаны правила:«Не писать файлы длиннее 200 строк»
«Использовать только Dependency Injection»
«Всегда проверять папку /utils на наличие дублей»
Не кончились. Во-первых, спать пошёл. Во-вторых, хорошего помаленьку.
А что, выглядит захватывающе? Требуете продолжения?
У меня такого полно.
Бизнес-требование: Бинарный протокол отображения (Binary-First Browser)
1. Концепция (The Core Idea)
Заменить классический текстовый стек (HTML/CSS) на компактный бинарный формат данных (назовем его BDOM — Binary Document Object Model). Сервер или Брокер конвертирует входящие данные в типизированные структуры, которые Skia отрисовывает напрямую, минуя тяжелые текстовые парсеры.
2. Ключевые бизнес-требования (Business Requirements)
BR-B1: Нулевой синтаксический оверхед (Efficiency)
Требование: Использование сериализованных структур (например, FlatBuffers или кастомный двоичный протокол) для передачи дерева элементов от Брокера к Рендереру.
Критерий успеха: Скорость десериализации страницы в Рендерере должна быть в 10–50 раз выше, чем парсинг аналогичного HTML/CSS в LiteHTML.
BR-B2: Безопасность через типизацию (Binary Security)
Требование: Исключить возможность текстовых инъекций. Бинарный формат должен строго определять типы данных (размер шрифта — int, цвет — uint32, координаты — float).
Критерий успеха: Полная невозможность выполнения классических XSS-атак, так как данные в принципе не интерпретируются как исполняемый код или скрипт.
BR-B3: Экономия трафика (Bandwidth Optimization)
Требование: Бинарный документ должен занимать на 40–70% меньше объема, чем эквивалентный HTML-код, за счет отсутствия тегов, кавычек и дублирующихся строк.
Критерий успеха: Возможность комфортной работы браузера на каналах связи от 64 кбит/с.
BR-B4: Нативный мапинг на Skia (Rendering Alignment)
Требование: Структура бинарного документа должна максимально соответствовать командам рисования Skia (Draw Calls).
Критерий успеха: Рендерер должен начинать отрисовку первого кадра (First Meaningful Paint) сразу после получения первых байтов бинарного потока, не дожидаясь закрывающего тега.
3. Технологический стек реализации
Формат данных: FlatBuffers (позволяет обращаться к данным в памяти без распаковки) или Protobuf.
Конвертер (Proxy): Специальный сервис (или модуль в Брокере), который берет "грязный" HTML из сети и "выпрямляет" его в чистый бинарный BDOM.
Рендерер: Облегченная версия вашего приложения, где вместо LiteHTML стоит BDOM-Reader, вызывающий методы Skia.
4. Преимущества для бизнеса
Уникальность: Это не просто очередной браузер, а закрытая экосистема с высочайшим уровнем защиты.
Экономия: Снижение затрат на серверные мощности и трафик.
Контроль: Вы полностью контролируете, какие элементы могут быть отображены, а какие — нет.
как у вас все просто :)
«Plans are nothing; planning is everything.»
План разработки защищенного браузера (Slint + Skia + Godot + NsJail)
1. Архитектура "Slint-Native"
Host Process (Broker): Управляет окном и ресурсами.
UI Process (Slint + Skia): Основной интерфейс (вкладки, меню, настройки) на Slint.
HTML Plugin (LiteHTML): Опциональный модуль для отрисовки Web-контента внутри Slint-виджета.
Game Plugin (Godot): Изолированный игровой модуль.
2. Этапы разработки
Этап 1: Фундамент на Slint + Skia (4 недели)
[ ] Настройка CMake для интеграции Slint с использованием Skia Renderer.
[ ] Дизайн основного интерфейса браузера на языке
.slint(адресная строка, боковая панель).[ ] Реализация Broker Process для запуска UI в первом контейнере NsJail.
[ ] Настройка IPC (Unix Sockets) для передачи URL и команд между Slint и Брокером.
Этап 2: Опциональный HTML-модуль (3 недели)
[ ] Создание кастомного виджета в Slint (
NativeWindowHandleилиImage), куда будет транслироваться буфер от LiteHTML.[ ] Компиляция LiteHTML как динамического плагина, который подгружается только при необходимости.
[ ] Реализация "песочницы в песочнице": HTML-рендерер изолирован от основного интерфейса Slint.
Этап 3: Интеграция Godot (4 недели)
[ ] Использование DMA-BUF для проброса текстур из Godot напрямую в Skia-контекст Slint.
[ ] Настройка фокуса ввода: Slint передает управление клавиатурой/мышью в процесс Godot при клике на игровую область.
Этап 4: JS-модуль (QuickJS) (3 недели)
[ ] Подключение QuickJS как опционального скриптового движка для Slint-интерфейса или HTML-модуля.
[ ] Разграничение прав: JS в интерфейсе (Slint) и JS на страницах (HTML) работают в разных NsJail.
Этап 5: Безопасность и Hardening (2 недели)
[ ] Seccomp-профили для Slint (запрет доступа к сети, только IPC).
[ ] Cgroups для ограничения потребления RAM игровыми плагинами.
3. Технологический стек
UI Framework: Slint (основной).
Graphics: Skia (через Slint Renderer).
HTML Support: LiteHTML (опциональный C++ плагин).
Games: Godot 4.x (через NsJail + DMA-BUF).
Security: NsJail, Seccomp, Linux Namespaces.
4. Сроки и команда
MVP (Slint UI + NsJail): 2.5 месяца.
Полная версия (HTML + Godot + JS): 5-6 месяцев.
Оценка размера дистрибутива (Binary Size)
Ваш браузер будет в 10–20 раз компактнее Chromium-решений (Electron/QtWebEngine), так как в нем отсутствуют тяжелые зависимости и избыточные компоненты.
1. Вес компонентов (Static Linkage)
При статической сборке всех модулей в один или несколько бинарников:
2. Варианты дистрибуции
Minimal (Core + UI): Только Skia и LiteHTML. Вес ~20–25 МБ.
Standard (Core + JS): Добавляется модуль QuickJS. Вес ~26 МБ.
Gaming Edition (Full): Включает рантайм Godot для плагинов. Вес ~45 МБ.
3. Методы оптимизации размера
LTO (Link Time Optimization): Удаление неиспользуемых частей Skia (например, PDF-рендерера или редких кодеков) экономит до 30% веса.
Strip Symbols: Удаление отладочной информации (
strip --strip-all) уменьшает бинарник в 2-3 раза.System Libraries: Если линковать
fontconfig,freetypeиopensslдинамически (использовать системные в Linux), размер упадет до 10–15 МБ.UPX Compression: Сжатие финального исполняемого файла может довести размер до невероятных 8–12 МБ (с небольшой задержкой при распаковке в RAM при старте).
4. Сравнение с конкурентами
Google Chrome: ~350 МБ
Pale Moon: ~40 МБ
Dillo (старый легкий браузер): ~2 МБ (но без Skia и Godot)
Ваш проект: ~35 МБ (современная графика + игры + безопасность).
План реализации опционального модуля JavaScript (QuickJS + IPC Isolation)
Чтобы сохранить безопасность, JS-движок выносится в отдельный процесс. Он не имеет прямого доступа к памяти рендерера или сети.
1. Архитектурная схема взаимодействия
2. Этапы реализации
Этап 1: Интеграция QuickJS (1-2 недели)
[ ] Сборка QuickJS как статической библиотеки внутри изолированного бинарника-воркера.
[ ] Создание основного цикла (Event Loop) в JS-процессе для обработки входящих сообщений.
[ ] Реализация базовых функций
console.logиsetTimeoutчерез проброс сигналов в Broker.Этап 2: Протокол DOM Bridge (2 недели)
[ ] Зеркалирование DOM: LiteHTML при парсинге создает упрощенную карту ID элементов и передает её в QuickJS.
[ ] Proxy Objects: Создание в QuickJS объектов-оберток (например,
document.getElementById), которые при вызове методов генерируют IPC-сообщение (например,SET_STYLE,CHANGE_TEXT).[ ] Событийная модель: Рендерер ловит клик -> отправляет ID элемента в JS-процесс -> QuickJS запускает привязанный
onclickобработчик.Этап 3: Интерфейс управления (1 неделя)
[ ] On-Demand Activation: Реализация кнопки в Skia UI для запуска/убийства процесса
js_workerдля конкретной вкладки.[ ] Permissions: Настройка прав (разрешить ли JS доступ к буферу обмена или геопозиции через запрос к Broker).
Этап 4: Изоляция NsJail (1 неделя)
[ ] Sandboxing: Конфигурация NsJail для JS-процесса с
nullсетевым интерфейсом и пустой файловой системой.[ ] Seccomp: Максимальное ограничение системных вызовов (только
read/writeв сокет,brk/mmapдля памяти).3. Технические детали (Технологии)
Движок: QuickJS (поддержка ES2023, малый вес ~1MB).
Транспорт: Unix Domain Sockets (тип
SOCK_SEQPACKETдля сохранения границ сообщений).Сериализация: Simple Binary Protocol или FlatBuffers (для минимальных задержек при передаче изменений DOM).
4. Итоговая логика работы
Пользователь заходит на сайт (JS выключен, работает только LiteHTML).
Нажимает "Разрешить JS".
Broker запускает NsJail + QuickJS.
QuickJS запрашивает скрипты у Broker -> выполняет их -> шлет команды на обновление в Render Process.
Как думаете, получится реализовать?
План разработки защищенного браузера (Skia + LiteHTML + Godot + NsJail)
1. Архитектура системы (Multi-process Isolation)
Broker Process (Host): Управляющий процесс. Владеет окном (GLFW/Wayland), управляет IPC, координирует обмен DMA-BUF.
UI/Render Process (NsJail 1): Skia + LiteHTML. Рендеринг интерфейса и страниц. Без доступа к сети и FS.
Plugin Process (NsJail 2): Godot Engine. Запуск игр/приложений. Доступ к GPU (/dev/dri), изоляция логики.
2. Этапы разработки и сроки
Этап 1: Core Broker & IPC Foundation (4–5 недель)
[ ] Создание Broker-процесса на C++ (Main Loop).
[ ] Настройка IPC: Unix Domain Sockets для команд +
memfd_create/dmabufдля графики.[ ] Реализация механизма передачи File Descriptors (FD) между процессами.
[ ] Базовая конфигурация NsJail (Namespaces: mount, user, pid, net, uts).
Этап 2: Skia & LiteHTML Renderer (6 недель)
[ ] Интеграция Skia в изолированный процесс (NsJail 1).
[ ] Реализация
litehtml::containerдля отрисовки через Skia API.[ ] Настройка Font Manager (проброс шрифтов через Read-only bind-mount).
[ ] Система "тайлинга": рендеринг страницы в shared buffer, который забирает Broker.
Этап 3: Godot Plugin Bridge (4–5 недель)
[ ] Подготовка Godot (GDExtension) для работы в режиме "External Texture".
[ ] Настройка NsJail 2 с пробросом GPU драйверов (
/dev/dri) и.pckфайлов.[ ] Реализация синхронизации кадров: Godot рендерит в DMA-BUF -> Broker передает дескриптор в Skia UI.
[ ] Проброс Input-событий (мышь/клава) из Broker в Godot через сокет.
Этап 4: Безопасность и Seccomp (2 недели)
[ ] Написание жестких Seccomp-профилей для каждого процесса (запрет лишних syscalls).
[ ] Настройка Cgroups (ограничение RAM/CPU для игровых плагинов).
[ ] Аудит IPC: валидация всех входящих данных в Broker.
Этап 5: UI & Финализация (3 недели)
[ ] Разработка браузерной обвязки на Skia (вкладки, адресная строка).
[ ] Реализация логики загрузки ресурсов (Broker качает данные -> передает в Render Process).
[ ] Оптимизация Zero-copy переключения контекстов.
3. Общий эстимейт
MVP (Минимально рабочий прототип): ~4 месяца.
Stable Version (Полная изоляция + Плагины): ~6 месяцев.
4. Стек технологий
Язык: C++20 / GDScript (для игр).
Графика: Skia (UI), Godot (Plugins), Vulkan/OpenGL.
Layout: LiteHTML (CSS2.1 + частичный CSS3).
Изоляция: NsJail (Linux kernel features).
Связь: Unix Sockets (SCM_RIGHTS), Shared Memory.
Будут ли пользователи пользоваться таким браузером?
Ответ зависит от позиционирования. Без поддержки JavaScript 90% современного интернета (соцсети, банки, видеохостинги) не будут работать. Однако этот проект занимает уникальную нишу.
1. Целевая аудитория (Кто придет?)
Любители "Minimal Web": Те, кто читает Wikipedia, блоги, документацию и новостные ленты. Для них отсутствие JS — это плюс (нет рекламы, нет слежки, мгновенная загрузка).
Секьюрити-гики: Люди, работающие с конфиденциальной информацией, которым нужна "стерильная" среда для чтения текстов, где выполнение кода невозможно физически.
Геймеры и инди-разработчики: Если вы создадите каталог Godot-игр, пользователи будут использовать браузер как легкий игровой клиент (аналог Flash-плеера нового поколения).
Владельцы слабого железа: Пользователи старых ноутбуков и Raspberry Pi, на которых Chrome потребляет всю память.
2. Ключевые преимущества для пользователя
Мгновенный отклик: Благодаря Skia и отсутствию тяжелого JS-движка, интерфейс и страницы будут летать.
Безопасность: Архитектура с NsJail гарантирует, что даже если страница попытается атаковать систему, она останется заперта в "песочнице".
Идеальная типографика: Использование Skia позволяет сделать чтение длинных текстов максимально комфортным (субпиксельное сглаживание, кастомные шрифты).
3. Что нужно сделать, чтобы удержать пользователя?
Качественный UI: Сделать интерфейс на Skia более красивым и плавным, чем у современных браузеров.
Каталог контента: Встроить "магазин" или список Godot-плагинов прямо в стартовую страницу.
Reader Mode: Сделать упор на идеальный режим чтения, который переверстывает "кривые" сайты в удобный текстовый вид.
4. Главный риск
Современный CSS: LiteHTML поддерживает не все свойства Flexbox и Grid. Если верстка популярных текстовых сайтов (например, GitHub или StackOverflow) будет ломаться, пользователи уйдут.
Вердикт:
Это не замена основному браузеру, а "Второй браузер" для безопасного чтения и легких игр. Как инструмент для специфических задач или как платформа для инди-игр проект имеет высокий потенциал.
Диалог об анализе статьи «О радости программирования и невесомости достижений»
Пользователь:
https://habr.com
выполнить анализ текста
Ассистент:
Ниже представлен подробный анализ статьи Сергея Кушниренко (dalerank) «О радости программирования и невесомости достижений», опубликованной на Хабре.
Основная идея и тезис
Автор размышляет о фундаментальном сдвиге в профессии программиста в эпоху ИИ. Главный тезис заключается в том, что автоматизация генерации кода (Copilot и аналоги) ускоряет работу, но обесценивает результат и разрушает глубокую когнитивную связь разработчика с его продуктом.
Ключевые темы анализа
1. Утрата «состояния потока» и тактильной радости
Автор выделяет два важных аспекта, которые уходят вместе с ручным написанием кода:
Когнитивное погружение: Раньше программирование сопровождалось состоянием глубокой концентрации (потока), когда мозг удерживал всю архитектуру целиком.
Физический аспект: Описывается удовольствие от ритма печати на клавиатуре, который помогал мыслить. Переход к текстовым промптам делает процесс абстрактным и «неживым».
2. Проблема «чужого кода» и интуиции
Один из самых практических выводов статьи касается отладки:
Ментальная карта: При ручном написании кода у разработчика формируется подробная модель системы в голове. Это позволяет чинить баги почти интуитивно.
Поверхностное владение: Код, сгенерированный ИИ, даже после ревью остается «чужим». При возникновении ошибок разработчик вынужден изучать его с нуля, так как он не «прожил» процесс его создания.
3. Эволюция роли программиста
Автор не отрицает прогресс, но прогнозирует изменение фокуса профессии:
От строк к архитектуре: Мастерство теперь смещается в сторону проектирования сложных систем на высоком уровне абстракции и умения задавать точные вопросы.
Риск превращения в оператора: Существует опасность потерять творческую искру и превратиться в простого «оператора чужих систем», если полностью делегировать созидание ИИ.
Эмоциональный тон
Текст пронизан ностальгией и легкой тревогой. Автор называет себя представителем «вымирающего поколения», для которого программирование было ремеслом. При этом он признает неизбежность изменений и пытается найти свое место в новой реальности.
Резюме
Статья является философским размышлением о том, что «полезное трение» (борьба с кодом) — это не лишняя трата времени, а необходимый механизм обучения и получения профессионального удовлетворения.
Пользователь:
да (в ответ на предложение составить список аргументов «за» и «против»)
Ассистент:
На основе статьи можно выделить следующие аргументы «за» и «против» использования ИИ в разработке:
Аргументы «ЗА» (Польза ИИ)
Скорость и производительность: ИИ избавляет от рутинного написания шаблонного кода (boilerplate), позволяя получать результат за секунды.
Снижение порога входа: ИИ помогает быстро разобраться в новых технологиях или языках, давая рабочие примеры «здесь и сейчас».
Фокус на архитектуре: Программист освобождается от «микро-менеджмента» строк кода и может сосредоточиться на проектировании системы в целом.
Ликвидация «страха чистого листа»: Нейросеть всегда дает базу, от которой можно оттолкнуться, ускоряя начало работы над задачей.
Аргументы «ПРОТИВ» (Риски и потери)
Отсутствие «ментальной карты»: Когда код пишет ИИ, разработчик не пропускает его через себя. В случае бага он тратит больше времени на понимание «чужого» решения, чем потратил бы на написание своего.
Утрата состояния потока: Исчезает глубокое погружение в задачу. Процесс превращается в прерывистое «чтение-правку-промпт», что мешает достижению высокой концентрации.
Обесценивание результата: Достижения, полученные слишком легко, не приносят профессионального удовлетворения и чувства мастерства («невесомость достижений»).
Атрофия навыков: Без регулярной практики решения сложных задач «вручную» мозг теряет способность находить нестандартные решения и выстраивать сложные логические связи.
Иллюзия понимания: Разработчик может одобрить сгенерированный код, который выглядит рабочим, но содержит скрытые архитектурные изъяны, которые проявились бы только в процессе вдумчивого написания.
Пользователь:
дать оценку выводов автора
Ассистент:
Выводы автора можно оценить как глубоко рефлексивные, психологически точные, но в некоторой степени консервативные. Вот детальный разбор:
1. Объективность и точность (Психология и когнитивистика)
Здесь автор абсолютно прав. Существует доказанная связь между «трудностью» процесса и качеством запоминания/понимания (эффект генерации). Когда мы создаем что-то сами, нейронные связи строятся иначе, чем при пассивном потреблении или редактировании. Вывод о потере «ментальной карты» — это самый сильный и практически важный аргумент статьи.
2. Профессиональная ценность (Ремесло vs Индустрия)
Автор смотрит на программирование как на ремесло (craftsmanship). С этой точки зрения его выводы о потере «радости» верны. Однако с точки зрения бизнеса, программирование — это производство продукта. Для индустрии переход от ручного труда к ИИ-конвейеру — это естественная эволюция (как переход от ткацких станков к фабрикам). Автор фиксирует боль «мастера», чей уникальный навык становится массовым и дешевым.
3. Риск элитизма
Вывод о том, что программисты станут «архитекторами», подразумевает, что порог входа в высшую лигу станет еще выше. Это может привести к разделению на узкую прослойку «тех, кто понимает, как всё работает» и огромную массу «операторов промптов», которые не смогут починить систему без подсказки ИИ. Это опасный, но реалистичный прогноз.
4. Эмоциональный аспект
Термин «невесомость достижений» — это блестящее описание проблемы современного дофаминового цикла. Если результат дается слишком легко, мозг не фиксирует его как победу. Это может привести к массовому выгоранию из-за отсутствия чувства самореализации, даже если KPI выполняются.
Итог оценки:
Автор зафиксировал экзистенциальный кризис профессии. Его выводы — это не «брюзжание старого программиста», а предупреждение о том, что вместе с ростом эффективности мы теряем устойчивость знаний и психологическую вовлеченность. Это цена, которую индустрия готова платить за скорость, но каждый разработчик лично должен решить, готов ли платить её он.
Пользователь:
что можно предпринять для устранения рисков и потерь?
Ассистент:
Для устранения рисков, описанных в статье, важно вернуть в работу «осознанность» и не позволять ИИ полностью подменять когнитивный процесс. Вот конкретные стратегии:
1. Стратегия «Сначала проект, потом код»
Что делать: Перед использованием ИИ спроектируйте решение на бумаге или в Miro. Пропишите логику взаимодействия компонентов.
Результат: Вы сохраняете роль архитектора, а ИИ становится лишь «руками».
2. Принудительное ревью (The "Why" Check)
Что делать: Никогда не копируйте код бездумно. Задавайте себе вопрос: «Почему ИИ выбрал именно этот алгоритм?». Попробуйте объяснить логику вслух.
Результат: Код переходит в категорию «проверенный и понятый».
3. Метод «Слепого набора» для обучения
Что делать: Если ИИ выдал новое для вас решение, не нажимайте Tab. Перепишите его вручную, глядя на экран.
Результат: Включается моторная память, что возвращает «полезное трение».
4. Создание «зон без ИИ»
Что делать: Выделяйте блоки времени (например, 1-2 часа в день) на задачи, которые вы решаете строго без Copilot.
Результат: Тренировка мозга в режиме высокой концентрации.
5. Использование ИИ как «Оппонента»
Что делать: Сначала напишите свое решение, а затем попросите ИИ найти в нем ошибки или предложить альтернативу.
Результат: Вы остаетесь ведущим в процессе.
Пользователь:
да (в ответ на предложение составить чек-лист для проверки сгенерированного кода)
Ассистент:
Чек-лист: Присвоение кода (от «Чужого» к «Своему»)
1. Уровень логики (The "How" Check)
[ ] Пошаговое чтение: Я могу объяснить каждую строку кода вслух?
[ ] Edge Cases (Крайние случаи): Что произойдет, если на вход придет null или пустой массив?
[ ] Лишний балласт: Нет ли здесь ненужных универсальных оберток?
2. Уровень интеграции (The "Where" Check)
[ ] Контекст проекта: Соответствует ли стиль именования и обработки ошибок моему проекту?
[ ] Зависимости: Не подтянул ли ИИ лишние или запрещенные библиотеки?
[ ] Дублирование: Не реализует ли этот код то, что уже есть в проекте?
3. Уровень безопасности и чистоты
[ ] Магические константы: Все ли вынесено в конфиги?
[ ] Безопасность: Нет ли потенциальных уязвимостей?
[ ] Производительность: Какая сложность у этого алгоритма (Big O)?
4. Финальный тест на владение
[ ] Готовность к багам: Если код упадет ночью, я смогу починить его за 5 минут без ИИ?
[ ] Ручная правка: Я внес хотя бы одно минорное изменение (переименование, комментарий), чтобы зафиксировать свое участие?
Пользователь:
этот чек лист может выполнять ИИ? что можно переложить на ИИ?
Ассистент:
Использование ИИ для проверки ИИ полезно, но имеет ограничения.
1. Что МОЖНО переложить на ИИ:
Поиск Edge Cases: Попросите найти 5 сценариев, при которых код сломается.
Анализ сложности: Расчет Big O сложности алгоритма.
Соответствие стайлгайду: Приведение кода к стандартам проекта.
Безопасность: Поиск явных уязвимостей.
Генерация тестов: Написание Unit-тестов для проверки логики.
2. Что КАТЕГОРИЧЕСКИ нельзя отдавать ИИ:
Пошаговое чтение: Только ваш мозг должен пропустить через себя логику для построения ментальной карты.
Контекст проекта: ИИ не знает архитектурных «договоренностей» вашей команды.
Готовность к багам: Ответственность за понимание лежит на вас.
Итоговая схема: ИИ генерирует и технически проверяет код, а вы выполняете финальную «приемку» и когнитивное присвоение.
Вот вам еще нейрослопов: https://share.google/aimode/6FVm13aMzW4yhPa8V
12 байт: https://share.google/aimode/A61IM6zHTSexxFArS
Интересная: https://share.google/aimode/6V2F1a7xjX3c09Lij
https://share.google/aimode/XXAgcHtKaI8zj39AL
Их еще подогнуть, и будет самое то.
Как использовать AI для обучения джунов?
https://share.google/aimode/WLqb8fOaaitlJRWXO
Как видится, сейчас джун может прокачаться намного быстрее с помощью AI:https://share.google/aimode/gshemddMUnjF0Lrve
Джуны сейчас находятся в лучшем положении, чем раньше?
https://share.google/aimode/uHYFqYzYUZYZDul0p
nedoGPT, 37 строк: https://share.google/aimode/DcfbHR04awBu7pI41
Модэ — Википедия
Откуда у вашего Пети, зарабатывающего 300к, столько свободного времени, чтобы ежедневно столько денег тратить?
И как употребление кальяна сочетается с зарабатыванием 300к, оно же мозги гарантированно убивает, как и алкоголь?
Сюда нужно зайти: Learn Python, Data Viz, Pandas & More | Tutorials | Kaggle
В книге "Пирс, Типы в языках программирования", в главе 1.5 можно найти:
"Основания семантики типов в рамках математической теории категорий (category theory) можно найти во множестве источников, включая книги Якобса (Jacobs, 1999), Асперти и Лонго (Asperti and Longo, 1991) и Кроула (Crole, 1994); краткое введение имеется в «Основах теории категорий для специалистов по информатике» («Basic Category Theory for Computer Scientists», Pierce, 1991a)."