Hacker News Digest

Диалог высмеивает современную тенденцию усложнять разработку на Rails, добавляя множество инструментов вроде Vite, React, TypeScript, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky, Docker и Redis. Всё это оправдывается стремлением к «современности» и скорости, но приводит к громоздкой настройке.

В противовес этому демонстрируется простота «ванильного» Rails: один командой запускается мгновенно работающее приложение с быстрой загрузкой и формами. Ключевая идея — Rails уже содержит всё необходимое, а избыточные инструменты лишь создают сложность без реальной выгоды. Фраза «Просто используй Rails, блин!» резюмирует мысль: не усложняй там, где это не нужно.

• Участники обсуждают растущую сложность современных веб-фреймворков, отмечая, что Rails предлагает более простой и "батарейками включенный" подход по сравнению с перегруженными инструментами JS-экосистемы.
• Многие выражают ностальгию по классическому Rails, критикуя такие новые решения, как Hotwire и Stimulus, за сложность освоения и недостаток документации, в то время как другие защищают их как "путь Rails".
• Поднимается тема чрезмерного усложнения проектов (over-engineering), особенно для небольших команд, где монолитные фреймворки (Rails, Django) часто продуктивнее разделения на фронтенд и бэкенд.
• JS-экосистема подвергается критике за постоянное "изобретение велосипедов", сложность инструментов и модульность, которая приводит к усталости от инструментария, хотя некоторые защищают её гибкость.
• Отмечается, что выбор инструментов должен определяться конкретными задачами проекта, а не модными тенденциями, и что проверенные временем технологии часто эффективнее для небольших и средних приложений.

Основы

• Определите цель: чётко сформулируйте задачу перед генерацией кода.
• Начинайте с README: описание проекта помогает ИИ и команде.
• Используйте шаблоны: готовые структуры (FastAPI, React) экономят время.

Промпты

• Контекст: указывайте язык, фреймворк, стиль (PEP8, camelCase).
• Мелкие задачи: дробите фичи на куски по 50–100 строк.
• Примеры: прикладывайте JSON-ответы или SQL-запросы.
• Итерации: улучшайте код по одному аспекту за раз.

Рабочий процесс

• Сессии: 30-минутные циклы «запрос-ревью-запуск».
• Git-коммиты после каждого шага для отката.
• Линтеры/тесты сразу: pytest, eslint, mypy.
• Code Review: проверяйте всё, даже «очевидное».

Инструменты

• Copilot Chat в IDE для быстрых правок.
• Cursor / Windsurf для многофайлового рефакторинга.
• Playwright для e2e-спек, сгенерированных из текста.
• Docker для воспроизводимого окружения.

Качество

• Типы: добавляйте аннотации (TypedDict, Pydantic).
• Док-строки: пишите для всех публичных функций.
• Тесты: покрывайте критические пути ≥80 %.
• Логи: структурированные (structlog) для отладки.

Безопасность

• Секреты: проверяйте .env и git history.
• OWASP Top 10: сканируйте зависимости (pip-audit, npm audit).
• RBAC: реализуйте роли и разрешения сразу.

Производительность

• Профилирование: cProfile, py-spy для горячих точек.
• Кеш: Redis для частых запросов.
• CDN для статики фронтенда.

Деплой

• CI/CD: GitHub Actions → Docker → ECS/Fargate.
• Feature flags для постепенного релиза.
• Мониторинг: CloudWatch + Grafana.

Советы

• Не доверяйте 100 %: всегда читайте сгенерированный код.
• Учитесь у ИИ: спрашивайте «почему так» для роста навыков.

• Подавляющее большинство участников считает «vibe-coding» либо вредным, либо вообще не тем, что описано в документе.
• Настоящий vibe-coding — это «не смотреть код, а принимать результат, если визуально работает»; любые советы «тщательно читайте код» противоречат самому термину.
• Многие предпочитают писать чёткие спецификации и использовать LLM как «парного программиста», но подчёркивают, что это уже не «vibe», а обычная работа с AI.
• Частый риск — накопление непонятного, неотрефакторенного кода и «отравление» контекста при изменении требований.
• Итоговый совет большинства: «Don’t go full vibe» — даже при активном использовании LLM нужно понимать и контролировать результат.