domaintools.site начинался как PHP/Laravel-прототип: быстро собрать доменные утилиты в одном месте, проверить интерфейс и понять, будут ли этим пользоваться. Потом проект переехал на Python. Перенос шёл через Codex маленькими pull request’ами, а не «одной простынёй».
Сайт: domaintools.site. Репозиторий: github.com/A-Krivoshen/domaintools.
Что это за сервис сейчас
По факту domaintools.site – набор утилит «на каждый день», когда работаешь с доменами, DNS и IP. Не энтерпрайз-комбайн и не «проверка домена одной кнопкой», а прикладной инструментарий: ввёл значение, получил понятный ответ, не прыгая по десяти сервисам.
Что умеет
- Проверка доменного имени и быстрый поиск вариантов по зонам.
- WHOIS по домену.
- DNS-записи (A, AAAA, MX, NS, TXT и другие) с нормальным выводом.
- Поиск IP по домену и домена по IP.
- Сервисные проверки вроде site checker: доступность и ответы, без фанатизма.
Смысл простой: открыл страницу, ввёл домен, получил результат быстро и читаемо. Без «вот вам JSON, дальше сами».
Почему ушёл от PHP/Laravel
Старый вариант отработал как прототип: идея живая, инструменты нужны. Дальше хотелось развивать проект на Python – и ради практики, и по архитектуре: сетевые проверки, параллельность, аккуратная обработка ошибок, конфиги через окружение, простая сборка и деплой.
Честно: когда учишь новый стек, один раз переписать реальную вещь полезнее, чем десять «учебных блогов». На живом проекте сразу видно, где код падает, и почему «красиво» внезапно ломается в проде.
Где здесь Codex и почему это не «чатик подсказал»
Codex использовался так: не «нагенерь мне проект», а «сделай маленький кусок, оформи PR, я посмотрю дифф». История в репозитории – серия небольших pull request’ов, которые можно ревьюить и мержить без риска снести половину кода.
Через PR остаётся контроль: что поменялось, где, почему, и как откатиться. «Магическая» разработка без диффов – не мой формат.
История агентных правок: github.com/A-Krivoshen/domaintools/pulls.
Что улучшалось при переносе на Python
Не «архитектура на века», а сервис, которым удобно пользоваться и который не разваливается от реальных входных данных. Улучшения приземлённые.
Параллельность там, где всё упирается в сеть
Проверка зон и DNS – в основном ожидание. Последовательно сайт кажется «тормозным», хотя CPU может вообще не напрягаться. Логика уехала в параллельный режим с лимитами по числу зон и воркеров.
Параметры удобно держать в env, чтобы не лезть в код при каждом изменении лимитов:
export DOMAIN_CHECK_MAX_TLDS=20 export DOMAIN_CHECK_WORKERS=8
Читаемый вывод, а не простыня JSON
Многие доменные утилиты честно показывают ответ, но его невозможно читать. DNS/WHOIS и похожие вещи приведены к табличному виду: ключ и значение, аккуратная вёрстка, без ощущения дампа из консоли.
Язык и интерфейс
Шаблоны подчистились, появилась двуязычность ru/en, упростилась логика страниц. Дизайн не «SaaS-платформа», а прикладной инструмент: нормально выглядит и не раздражает.
Codex – не «сделай всё за меня». Скорее: сделай кусок, оформи PR, я посмотрю глазами. С таким подходом агент ускоряет. Без руля получается набор разрозненных правок, которые сложно поддерживать.
Главное правило: одна задача – один PR
Простая дисциплина. Один PR решает одну проблему. Не «рефакторинг всего проекта», а «ускорить доменную проверку и добавить лимиты», «нормально отрисовать JSON таблицей», «поправить ошибки в одном модуле».
Почему так лучше:
- дифф читается за 2-5 минут;
- если PR не зашёл, его легко откатить;
- понятно, что именно улучшилось;
- нет эффекта «всё поменялось, но где и почему».
Как формулировать задачу Codex
Не «сделай красиво» и не «улучши производительность». Задача в формате: контекст, цель, ограничения, критерии готовности. Как для нормального разработчика.
Шаблон
Контекст: - Проект: domaintools.site (Python/Flask) - Файл/модуль: app/site_checker.py (пример) - Сейчас: запросы идут последовательно, иногда таймауты Цель: - Параллельная проверка с лимитом на число задач Ограничения: - Не трогать внешний API и роуты - Не добавлять тяжёлые зависимости - Ошибки читаемые, без traceback в ответе Критерии готовности: - Есть PR с диффом - В логах понятные ошибки - Лимиты из env, есть safe default
С таким запросом агент реже расползается: сразу ясно, где копать и что нельзя трогать.
Какие задачи Codex закрывает лучше всего
- локальный рефакторинг одного модуля: разложить функции, убрать дубли;
- обработка ошибок: понятные сообщения, fallback, без «тихих» падений;
- рендер в шаблонах: единый стиль JSON/DNS/таблиц;
- настройки через env: параметры, дефолты, проверка значений;
- микро-оптимизации: list → set, кэш, лишние проходы.
На «перепиши всё приложение целиком» Codex не пускаю. Не потому что «не умеет», а потому что такой дифф почти невозможно нормально ревьюить.
Как ограничивать «креатив»
- Не менять публичные роуты и формат ответа, если это не оговорено.
- Не добавлять зависимости без причины. Если очень надо – объяснить зачем.
- Не делать архитектуру ради архитектуры. Решаем конкретную проблему.
- Не трогать стили на всех страницах, если задача про один блок.
Если задача про скорость, прошу 2-3 варианта и выбираю самый простой с нормальным эффектом. Простое проще поддерживать.
Чек-лист перед мержем PR от Codex
Секрет не в том, что агент «идеально пишет». Секрет в том, что вслепую не мержат.
- Дифф глазами. Особенно ошибки и network-часть.
- Проверка env: нет ли странных дефолтов.
- Минимум локально или на стенде: старт приложения, 1-2 запроса к ключевым страницам.
- Если есть параллелизм – смотреть лимиты и safe default.
- Если тронуты шаблоны – проверить в браузере и на мобиле.
Минимальный набор команд зависит от проекта, обычно хватает:
python -m compileall . python app.py # или твой entrypoint curl -I http://127.0.0.1:5000/ curl -s 'http://127.0.0.1:5000/dns?domain=example.com' | head
Не нужно покрывать тестами вселенную. Нужно убедиться, что PR не ломает базовые маршруты и не добавляет сюрпризов.
Промпты, которые реально используются
Готовые формулировки. Можно копировать и адаптировать.
1) Рефакторинг модуля «Возьми модуль X. Разбей на мелкие функции, убери дубли, добавь понятные ошибки. Не меняй роуты и формат ответа. Сделай PR.» 2) Скорость и параллелизм «Ускорь проверки в функции Y. Добавь параллельность с лимитами и safe default. Параметры вынеси в env. Сделай PR и короткое объяснение.» 3) UI вывод данных «Сделай единый вывод JSON таблицей key/value для страниц A, B, C. Без изменения логики получения данных. Только отображение. Сделай PR.» 4) Обработка ошибок «Сейчас при ошибке Z уходит traceback/500. Сделай аккуратный ответ пользователю и запись в лог. Не меняй happy-path. Сделай PR.»
Где Codex ошибается – и это нормально
Два частых сценария:
- агент слишком верит env и плохо защищается от кривых значений;
- агент перебарщивает с рефакторингом и трогает соседние части, хотя задача была локальной.
Это не трагедия. Это причина держать дисциплину: один PR – одна задача, и ревью глазами.
Как пользоваться domaintools.site
Всё прямолинейно: выбираешь инструмент, вводишь домен или IP, получаешь результат. Короткий маршрут:
- Нужно понять, жив ли домен и что по зонам – начинаешь с поиска/проверки домена.
- Нужен регистратор и сроки – WHOIS.
- Не сходится почта или веб – DNS и записи.
- Разбираешься с IP – прямой/обратный поиск.
Демо: domaintools.site.
Итог
Старый PHP/Laravel вариант был полезным стартом, но как продукт его уже нет смысла «продавать». Жизнь проекта – в Python-версии. Перенос стал тестом подхода: Codex как напарник, который готовит маленькие PR, а решения и качество остаются за ревью.
Codex здесь не «генератор кода», а ускоритель с контролем. Формат «агент делает PR, человек ревьюит и мержит» хорошо ложится на реальную разработку. Особенно когда учишь новый стек и не хочешь хаоса в репозитории.
Репозиторий: github.com/A-Krivoshen/domaintools