Hacker News Digest

Разработка 10G Ethernet-ядра с минимальной латентностью — вводная часть. Автор описывает, как написал ядро для FPGA, которое при полном цикле loopback показывает задержку менее 60 нс. Подчеркиваются нестандартные приёмы верификации на cocotb/pytest и оптимизации, которые позволили добиться такой скорости. Серия будет охватывать архитектуру, измерения и сравнение с коммерческими решениями, а также потенциальные улучшения.

• Обсуждение вращается вокруг FPGA-дизайнеров, которые создают ультранизколатентное оборудование для HFT-компаний, и вызывает вопросы о ценности такой работы и её влиянии на жизнь и карьеру разработчика.
• Участники обсуждают, насколько "интересной" или "захватывающей" может быть такая работа, и как она влияет на жизнь разработчика.
• Обсуждается, что такая работа может быть очень стрессовой из-за ответственности за миллионы долларов в минуту.
• Также обсуждается, что такая работа может быть не очень хорошо оплачена, и что она может нести за собой серьёзные этические вопросы.
• В обсуждении также поднимается вопрос о том, что такая работа может быть не очень интересной, если учитывать, что она не предлагает много возможностей для роста и развития.

Основы

• Определите цель: чётко сформулируйте задачу перед генерацией кода.
• Начинайте с 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 нужно понимать и контролировать результат.