День 74 :: 🔥 Кипиш в «ЧоПочом»: готовим MVP!
Пол третьего ночи, а я все ещё пишу код. Сейчас такой режим - норма. Любой стартапер это подтвердит.
Наш MVP — это не просто список задач, это наша первая ступенька к запуску огромного AI-маркетплейса.
Чтобы начать тестирование, нам уже нужно запустить 6 основных продуктов из 11:
1️⃣ Витрину для товаров
2️⃣ Портал партнера
3️⃣ Админку для управления сервисом
4️⃣ Личный кабинет продавца
5️⃣ Личный кабинет курьера
6️⃣ Личный кабинет покупателя
Что уже есть на данный момент?
✅ Настроены шаблоны и авторизация — все кабинеты уже начинают оживать.
✅ Модуль импорта и управления товарами на финальной стадии.
✅ Модуль управления пользователями — готов!
✅ Логирование событий тоже настроено.
⚙️ Модуль корзины сейчас активно пилится.
И это все делают всего два разработчика. Два человека — и кипиш в коде просто максимальный: все работает на скорости света, дедлайны горят, задачи растут, а кофе уходит литрами.
Но главное — через 2 дня мы планируем протестировать ПЕРВЫЙ ЗАКАЗ! 🚀
Каждая новая строчка кода — это шаг к тому, чтобы наш стартап стал ближе к реальным пользователям.
Скоро расскажем, как прошел тестовый заказ, а пока идем писать код, много кода. ЧоПочом, погнали!
@achopochom — закулисье создания стартапа🦄
#разработка #стартап #чопочом
Пол третьего ночи, а я все ещё пишу код. Сейчас такой режим - норма. Любой стартапер это подтвердит.
Наш MVP — это не просто список задач, это наша первая ступенька к запуску огромного AI-маркетплейса.
Чтобы начать тестирование, нам уже нужно запустить 6 основных продуктов из 11:
1️⃣ Витрину для товаров
2️⃣ Портал партнера
3️⃣ Админку для управления сервисом
4️⃣ Личный кабинет продавца
5️⃣ Личный кабинет курьера
6️⃣ Личный кабинет покупателя
Что уже есть на данный момент?
✅ Настроены шаблоны и авторизация — все кабинеты уже начинают оживать.
✅ Модуль импорта и управления товарами на финальной стадии.
✅ Модуль управления пользователями — готов!
✅ Логирование событий тоже настроено.
⚙️ Модуль корзины сейчас активно пилится.
И это все делают всего два разработчика. Два человека — и кипиш в коде просто максимальный: все работает на скорости света, дедлайны горят, задачи растут, а кофе уходит литрами.
Но главное — через 2 дня мы планируем протестировать ПЕРВЫЙ ЗАКАЗ! 🚀
Каждая новая строчка кода — это шаг к тому, чтобы наш стартап стал ближе к реальным пользователям.
Скоро расскажем, как прошел тестовый заказ, а пока идем писать код, много кода. ЧоПочом, погнали!
@achopochom — закулисье создания стартапа🦄
#разработка #стартап #чопочом
👍4❤1🔥1
День 102 :: Почему даже маленькой команде нужно вести себя как большая?
В мире стартапов часто звучит мысль: "Мы маленькая команда, давайте сосредоточимся на продукте и не будем тратить время на сложные процессы".
Но это ловушка, в которую легко попасть.
Несмотря на то, что в нашей команде всего два разработчика, мы стремимся вести себя как полноценная команда разработки.
Вот почему:
1. Масштабируемость — думать наперед
Сегодня нас двое, а завтра нас десять. Если изначально не заложить правильные процессы, каждый новый член команды будет сталкиваться с хаосом.
Докер, CI/CD, контроль версий — это не просто модные слова, а базовые инструменты, которые позволяют масштабироваться без боли.
2. Автоматизация — меньше ручной работы
Ручная настройка окружений? Нет, спасибо. Докер помогает нам разворачивать окружения за минуты.
CI/CD исключает человеческий фактор при деплое. Эти процессы экономят время и уменьшают количество ошибок, даже если команда маленькая.
3. Управление кодом — всё под контролем
Git — это не просто про хранение кода. Это контроль изменений, возможность отката, работа с ветками и командная синхронизация. Даже если у вас всего два разработчика, без гита легко потеряться в файлах и версиях.
4. Привычка к дисциплине
Когда в команде всего два человека, может показаться, что можно "договориться на словах".
Но это ошибка. Привычка работать по чётко установленным процессам дисциплинирует и делает команду устойчивой. Когда придут новые сотрудники, они смогут быстро включиться в работу.
5. Подготовка к партнерствам и инвестициям
Потенциальные инвесторы и партнёры любят команды, которые организованы. Если вы можете показать, что ваши разработки построены на современных практиках, это вызовет доверие и уважение. Никто не хочет инвестировать в хаос.
6. Повышение уровня ответственности
Работа через CI/CD, Docker и другие инструменты требует планирования. Это приучает к тому, чтобы думать на несколько шагов вперёд, что особенно важно в стартапах, где каждая ошибка может стоить дорого.
Работая как большая команда, мы закладываем прочный фундамент для нашего стартапа.
Это не просто про технологии, это про подход к делу: стратегический, профессиональный и ориентированный на рост. И да, это занимает время и требует усилий, но эти вложения окупятся с лихвой, когда мы будем готовы к масштабированию и новым вызовам.
Нас мало, но мы настроены на великое. Поэтому мы настраиваем Docker, CI/CD, Git и всё остальное, что делают "большие парни". Потому что мы сами — большие парни.
@achopochom — закулисье создания стартапа🦄
#бизнес #разработка #процессы
В мире стартапов часто звучит мысль: "Мы маленькая команда, давайте сосредоточимся на продукте и не будем тратить время на сложные процессы".
Но это ловушка, в которую легко попасть.
Несмотря на то, что в нашей команде всего два разработчика, мы стремимся вести себя как полноценная команда разработки.
Вот почему:
1. Масштабируемость — думать наперед
Сегодня нас двое, а завтра нас десять. Если изначально не заложить правильные процессы, каждый новый член команды будет сталкиваться с хаосом.
Докер, CI/CD, контроль версий — это не просто модные слова, а базовые инструменты, которые позволяют масштабироваться без боли.
2. Автоматизация — меньше ручной работы
Ручная настройка окружений? Нет, спасибо. Докер помогает нам разворачивать окружения за минуты.
CI/CD исключает человеческий фактор при деплое. Эти процессы экономят время и уменьшают количество ошибок, даже если команда маленькая.
3. Управление кодом — всё под контролем
Git — это не просто про хранение кода. Это контроль изменений, возможность отката, работа с ветками и командная синхронизация. Даже если у вас всего два разработчика, без гита легко потеряться в файлах и версиях.
4. Привычка к дисциплине
Когда в команде всего два человека, может показаться, что можно "договориться на словах".
Но это ошибка. Привычка работать по чётко установленным процессам дисциплинирует и делает команду устойчивой. Когда придут новые сотрудники, они смогут быстро включиться в работу.
5. Подготовка к партнерствам и инвестициям
Потенциальные инвесторы и партнёры любят команды, которые организованы. Если вы можете показать, что ваши разработки построены на современных практиках, это вызовет доверие и уважение. Никто не хочет инвестировать в хаос.
6. Повышение уровня ответственности
Работа через CI/CD, Docker и другие инструменты требует планирования. Это приучает к тому, чтобы думать на несколько шагов вперёд, что особенно важно в стартапах, где каждая ошибка может стоить дорого.
Работая как большая команда, мы закладываем прочный фундамент для нашего стартапа.
Это не просто про технологии, это про подход к делу: стратегический, профессиональный и ориентированный на рост. И да, это занимает время и требует усилий, но эти вложения окупятся с лихвой, когда мы будем готовы к масштабированию и новым вызовам.
Нас мало, но мы настроены на великое. Поэтому мы настраиваем Docker, CI/CD, Git и всё остальное, что делают "большие парни". Потому что мы сами — большие парни.
@achopochom — закулисье создания стартапа🦄
#бизнес #разработка #процессы
❤3👍2🔥1
День 111 :: Ошибка номер один: как мы слишком поверили в AI и что из этого вышло 🤖💥
Ошибки — это не провал. Это уроки, которые делают нас сильнее. И сегодня я хочу рассказать о нашей главной ошибке, которая задержала запуск MVP, но зато научила нас двигаться быстрее и умнее.
В чём была ошибка?
Мы слишком сильно поверили в искусственный интеллект как в программиста. Да, AI — это мощный инструмент, который помогает писать код, генерировать идеи и даже находить баги. Но, как оказалось, он не идеален. 🛠️
Мы хотели, чтобы AI писал код сразу по всем правилам: с тестами, логированием, кэшированием и всем, что только есть в лучших практиках. Но такой подход съел кучу времени. Почему? Потому что AI пока не может писать безупречный код. И отладка, как известно, занимает до 90% времени разработки.
Что мы поняли?
1. MVP — это минимальный продукт.
Не нужно пытаться сделать всё идеально с первого раза. Тесты, логирование и прочие "плюшки" можно добавить позже. Главное — запустить и получить обратную связь от рынка.
2. Мелкие итерации — это спасение.
Мы перестроили процесс: теперь AI работает над небольшими задачами, а код сохраняется мелкими коммитами. Это позволяет в любой момент вернуться к стабильной версии, если что-то пошло не так.
3. Готовые модули — это круто.
Мы активно используем готовые "кубики" кода, которые встраиваем в наш сервис. Это экономит время и силы.
Что в итоге?
За три с небольшим месяца AI написал нам огромное количество кода (вот бы кто-то посчитал точное количество строк! 😄). Но главное — мы поняли, что только двигаясь мелкими итерациями и фокусируясь на MVP, можно достичь скорости, недоступной даже огромным командам разработчиков.
Что дальше?
Мы продолжаем работать, учиться на ошибках и двигаться вперёд. AI всё ещё наш главный помощник, но теперь мы знаем, как использовать его с умом.
А вы сталкивались с подобными ошибками? Делитесь в комментариях — обсудим!
@achopochom — закулисье создания стартапа🦄
#стартап #ошибки #AI #разработка #MVP
Ошибки — это не провал. Это уроки, которые делают нас сильнее. И сегодня я хочу рассказать о нашей главной ошибке, которая задержала запуск MVP, но зато научила нас двигаться быстрее и умнее.
В чём была ошибка?
Мы слишком сильно поверили в искусственный интеллект как в программиста. Да, AI — это мощный инструмент, который помогает писать код, генерировать идеи и даже находить баги. Но, как оказалось, он не идеален. 🛠️
Мы хотели, чтобы AI писал код сразу по всем правилам: с тестами, логированием, кэшированием и всем, что только есть в лучших практиках. Но такой подход съел кучу времени. Почему? Потому что AI пока не может писать безупречный код. И отладка, как известно, занимает до 90% времени разработки.
Что мы поняли?
1. MVP — это минимальный продукт.
Не нужно пытаться сделать всё идеально с первого раза. Тесты, логирование и прочие "плюшки" можно добавить позже. Главное — запустить и получить обратную связь от рынка.
2. Мелкие итерации — это спасение.
Мы перестроили процесс: теперь AI работает над небольшими задачами, а код сохраняется мелкими коммитами. Это позволяет в любой момент вернуться к стабильной версии, если что-то пошло не так.
3. Готовые модули — это круто.
Мы активно используем готовые "кубики" кода, которые встраиваем в наш сервис. Это экономит время и силы.
Что в итоге?
За три с небольшим месяца AI написал нам огромное количество кода (вот бы кто-то посчитал точное количество строк! 😄). Но главное — мы поняли, что только двигаясь мелкими итерациями и фокусируясь на MVP, можно достичь скорости, недоступной даже огромным командам разработчиков.
«Я промахнулся более 9000 раз за свою карьеру. Я проиграл почти 300 игр. 26 раз мне доверяли сделать победный бросок, и я промахнулся. Именно поэтому я добился успеха».
Майкл ДжорданЧто дальше?
Мы продолжаем работать, учиться на ошибках и двигаться вперёд. AI всё ещё наш главный помощник, но теперь мы знаем, как использовать его с умом.
А вы сталкивались с подобными ошибками? Делитесь в комментариях — обсудим!
@achopochom — закулисье создания стартапа🦄
#стартап #ошибки #AI #разработка #MVP
👍2🔥2❤1
День 142 :: Метод «Прогрессивного JPEGа»: Почему «Hello World» важнее, чем вы думаете 🖥️💥
Представьте, что вы печете торт, но вместо того чтобы дать гостям попробовать коржи уже на первом этапе, вы полгода молчите, а потом внезапно ставите на стол шедевр с 10 ярусами. Гости в шоке, а вы в стрессе.
Так мы и делаем — и это ошибка.
Готовность на 1% сегодня лучше, чем 100% никогда.
Каждый день нужно показывать результат. Пусть даже микроскопический.
Для этого мы внедряем метод прогрессивного JPEGа.
Суть метода:
«Продукт должен быть готов на 100% в любой момент времени»
- День 1: Выводим «Hello World!» и показываем всем.
- День 2: Добавляем кнопку «Купить» (она не работает, но выглядит круто).
- День 3: Кнопка отправляет запрос в консоль (уже прогресс!).
Зачем?
Если вы не показываете прогресс ежедневно, вы:
1. Теряете фокус команды («А мы вообще движемся?»).
2. Копите технический долг, как хомяк — орехи.
3. Пропускаете баги, которые потом взорвутся, как непотушенный костер.
---
Наша ошибка:
Мы хотели сразу идеальный MVP:
- Красивое API,
- Сложные алгоритмы,
- Бесшовная интеграция с 10 сервисами.
Итог: 3 месяца кода, который запускается на ноутбуке, но не запускается на тестовом.
Поэтому «тестовый заказ» так и остался в планах.
---
Что меняем:
1. Принцип «Hello World»
Даже если сегодня готов только экран с логотипом — показываем его команде. Пусть видят: прогресс есть!
2. Ежедневные демо
Каждый день в 18:00 — отчёт в общий телеграмм: «Смотрите, кнопка теперь меняет цвет!».
Нет прогресса? Значит, день прошел зря.
3. Касается всех членов команды
Не только разработки. Но и продаж. И производства.
---
Как Alibaba запускала День холостяка:
- 2009: Первая версия — падающие серверы и ручное управление заказами.
- 2017: 325 000 транзакций в секунду.
Они не ждали «идеальной» системы. Они начинали с «Hello World» и масштабировались по мере роста.
---
Что меняется? Мы больше не прячем код «до релиза». Каждый день — маленький шаг к MVP. И если завтра наш сервис упадет от 10 заказов — это лучше, чем не упасть никогда.
@achopочом — закулисье создания стартапа🦄
#MVP #разработка #Agile #ошибки #прогресс
Представьте, что вы печете торт, но вместо того чтобы дать гостям попробовать коржи уже на первом этапе, вы полгода молчите, а потом внезапно ставите на стол шедевр с 10 ярусами. Гости в шоке, а вы в стрессе.
Так мы и делаем — и это ошибка.
Готовность на 1% сегодня лучше, чем 100% никогда.
Каждый день нужно показывать результат. Пусть даже микроскопический.
Для этого мы внедряем метод прогрессивного JPEGа.
Суть метода:
«Продукт должен быть готов на 100% в любой момент времени»
- День 1: Выводим «Hello World!» и показываем всем.
- День 2: Добавляем кнопку «Купить» (она не работает, но выглядит круто).
- День 3: Кнопка отправляет запрос в консоль (уже прогресс!).
Зачем?
Если вы не показываете прогресс ежедневно, вы:
1. Теряете фокус команды («А мы вообще движемся?»).
2. Копите технический долг, как хомяк — орехи.
3. Пропускаете баги, которые потом взорвутся, как непотушенный костер.
---
Наша ошибка:
Мы хотели сразу идеальный MVP:
- Красивое API,
- Сложные алгоритмы,
- Бесшовная интеграция с 10 сервисами.
Итог: 3 месяца кода, который запускается на ноутбуке, но не запускается на тестовом.
Поэтому «тестовый заказ» так и остался в планах.
---
Что меняем:
1. Принцип «Hello World»
Даже если сегодня готов только экран с логотипом — показываем его команде. Пусть видят: прогресс есть!
2. Ежедневные демо
Каждый день в 18:00 — отчёт в общий телеграмм: «Смотрите, кнопка теперь меняет цвет!».
Нет прогресса? Значит, день прошел зря.
3. Касается всех членов команды
Не только разработки. Но и продаж. И производства.
---
Как Alibaba запускала День холостяка:
- 2009: Первая версия — падающие серверы и ручное управление заказами.
- 2017: 325 000 транзакций в секунду.
Они не ждали «идеальной» системы. Они начинали с «Hello World» и масштабировались по мере роста.
---
Что меняется? Мы больше не прячем код «до релиза». Каждый день — маленький шаг к MVP. И если завтра наш сервис упадет от 10 заказов — это лучше, чем не упасть никогда.
@achopочом — закулисье создания стартапа🦄
#MVP #разработка #Agile #ошибки #прогресс
👍4🔥1🤔1
День 158 :: Docker: друг, враг или повелитель хаоса?
История о том, как мы 45 дней приручали 25 свирепых сервисов
Признавайтесь: вы тоже когда-то верили, что Docker — это волшебная палочка для разработчика. "Закинул Dockerfile, накатил compose — и вуаля, приложение летает!" — шептали нам мантры из туториалов. А потом началась реальность.
Наша — это 1.5 месяца экзистенциального кризиса, 327 чашек кофе и 25 сервисов, которые вели себя как кошки в ванной.
Хотите хоррор-комедию с моралью? Поехали!
Акт 1: "Да это же 5 минут работы!"
Сцена: тимлид, щелкая пальцами, запускает первый сервис. Окружение ликует.
— Смотрите, ребята! Контейнер стартанул!
— А почему он изнутри кричит "ERROR: lib WTF_NOT_FOUND"?
— Эээ… Это фича. Демо-режим.
Мораль №1: Docker не делает ваш код волшебно рабочим — он лишь аккуратно упаковывает ваш хаос в симпатичные контейнеры с лейблом "ОСТОРОЖНО! Хрупкое!".
---
Акт 2: Танец зависимостей
Сервис А требует Python 3.8. Сервис Б клянётся, что умрёт без 3.9. Сервис В вообще шепчет "собери меня из исходников, сладкий". А потом вы обнаруживаете, что ваше приложение — это матрёшка: внутри Java-сервиса живёт скрипт на Perl 1998 года выпуска, который вызывает бинарник, написанный для Windows XP.
Мораль №2: Docker-compose.yml — это не конфиг, а брачный контракт между враждующими технологиями. "И в горе, и в… segmentation fault".
---
Акт 3: Сеть — это паутина
Когда два контейнера внезапно начинают общаться через порт 3000, который вы не открывали.
Когда Redis решает, что он web-сервер.
Когда вы 3 часа ищете баг, а оказывается, что это не ваш код — это DNS. Это всегда DNS.
Мораль №3: Docker network — цифровой эквивалент комнаты с кривыми зеркалами. "Кто где? Кто я? Почему этот nginx отвечает стихами Есенина?".
---
Акт 4: Объёмы данных, или "Оставь надежду, всяк сюда входящий"
— Куда делись данные после перезапуска?
— Ты же не маунтил volume…
— А что такое volume?
*Звуки тихого плача из-под стола.*
Мораль №4: Docker — лучший учитель паранойи. Теперь вы делаете бэкапы даже перед тем, как заварить чай.
---
Финал: Когда тучи рассеялись
После 45 дней битв мы внезапно обнаружили:
✅ Сервисы запускаются одной командой
✅ Поднять окружение можно за 15 минут (а не за 2 дня)
✅ В чате разработчиков исчезли вопли "А у меня это работает!"
Мы поняли главное: Docker — не silver bullet, а зеркало. Он беспощадно показывает все грехи вашей архитектуры, зато щедро вознаграждает за чистоту помыслов (и Dockerfile'ов).
---
5 выстраданных лайфхаков:
1.
2. Пишите .dockerignore строже, чем условия брачного контракта
3. Один сервис — один процесс (даже если очень хочется запихнуть туда ещё и кофеварку)
4. Лейте логи как в последний раз — и заставьте себя их ЧИТАТЬ
5. Когда сроки горят — помните: без Docker было бы в 3 раза дольше. Но это не точно.
@achopochom — закулисье создания стартапа🦄
#docker #разработка
История о том, как мы 45 дней приручали 25 свирепых сервисов
Признавайтесь: вы тоже когда-то верили, что Docker — это волшебная палочка для разработчика. "Закинул Dockerfile, накатил compose — и вуаля, приложение летает!" — шептали нам мантры из туториалов. А потом началась реальность.
Наша — это 1.5 месяца экзистенциального кризиса, 327 чашек кофе и 25 сервисов, которые вели себя как кошки в ванной.
Хотите хоррор-комедию с моралью? Поехали!
Акт 1: "Да это же 5 минут работы!"
Сцена: тимлид, щелкая пальцами, запускает первый сервис. Окружение ликует.
— Смотрите, ребята! Контейнер стартанул!
— А почему он изнутри кричит "ERROR: lib WTF_NOT_FOUND"?
— Эээ… Это фича. Демо-режим.
Мораль №1: Docker не делает ваш код волшебно рабочим — он лишь аккуратно упаковывает ваш хаос в симпатичные контейнеры с лейблом "ОСТОРОЖНО! Хрупкое!".
---
Акт 2: Танец зависимостей
Сервис А требует Python 3.8. Сервис Б клянётся, что умрёт без 3.9. Сервис В вообще шепчет "собери меня из исходников, сладкий". А потом вы обнаруживаете, что ваше приложение — это матрёшка: внутри Java-сервиса живёт скрипт на Perl 1998 года выпуска, который вызывает бинарник, написанный для Windows XP.
Мораль №2: Docker-compose.yml — это не конфиг, а брачный контракт между враждующими технологиями. "И в горе, и в… segmentation fault".
---
Акт 3: Сеть — это паутина
Когда два контейнера внезапно начинают общаться через порт 3000, который вы не открывали.
Когда Redis решает, что он web-сервер.
Когда вы 3 часа ищете баг, а оказывается, что это не ваш код — это DNS. Это всегда DNS.
Мораль №3: Docker network — цифровой эквивалент комнаты с кривыми зеркалами. "Кто где? Кто я? Почему этот nginx отвечает стихами Есенина?".
---
Акт 4: Объёмы данных, или "Оставь надежду, всяк сюда входящий"
— Куда делись данные после перезапуска?
— Ты же не маунтил volume…
— А что такое volume?
*Звуки тихого плача из-под стола.*
Мораль №4: Docker — лучший учитель паранойи. Теперь вы делаете бэкапы даже перед тем, как заварить чай.
---
Финал: Когда тучи рассеялись
После 45 дней битв мы внезапно обнаружили:
✅ Сервисы запускаются одной командой
✅ Поднять окружение можно за 15 минут (а не за 2 дня)
✅ В чате разработчиков исчезли вопли "А у меня это работает!"
Мы поняли главное: Docker — не silver bullet, а зеркало. Он беспощадно показывает все грехи вашей архитектуры, зато щедро вознаграждает за чистоту помыслов (и Dockerfile'ов).
---
5 выстраданных лайфхаков:
1.
docker system prune —all —force —volumes — ваша мантра на первые недели разработки2. Пишите .dockerignore строже, чем условия брачного контракта
3. Один сервис — один процесс (даже если очень хочется запихнуть туда ещё и кофеварку)
4. Лейте логи как в последний раз — и заставьте себя их ЧИТАТЬ
5. Когда сроки горят — помните: без Docker было бы в 3 раза дольше. Но это не точно.
@achopochom — закулисье создания стартапа🦄
#docker #разработка
1🔥4❤3👍3
День 177 :: Тише едешь — дальше будешь.
— Можно ли доверять ИИ писать код за нас?
— Да.
— А целиком сложный и большой проект?
— Тоже да. Если вы хотите, чтобы этот проект напоминал икебану из спагетти, сваренную слепым шеф-поваром.
---
ИИ как студент-первокурсник. Он умён, быстр, но...
видит код через «замочную скважину»: помнит только ограниченное количество строк. Остальное для него — тёмный лес.
Он пишет функции, как стихи: Красиво, но без связи друг с другом. Результат: «Hello, World!» превращается в «Goodbye, Server!».
Контекст? Не, не слышал. Спросите его про микросервисы — он начнёт рассказывать про микроволновки.
Пример из жизни:
Как же быть? Что же делать?
Документация — НАШЕ ВСЕ. И еще умение быстро откатывать плохие изменения.
Мы превратили проект в «библию для ИИ»:
— User Stories прописаны так детально, будто это сценарий для Marvel.
— Метрики и тесты — как GPS для потерявшегося курьера.
— Архитектура описана так, что даже кофеварка в офисе её поняла.
В итоге ИИ-ассистент — не враг, а коллега, который:
1. Читает документацию вместо чатов в Telegram.
2. Пишет код, который хотя бы компилируется.
3. Напоминает: «Вы тут про бэкапы забыли. Или хотите повторить историю с Titanic?»
Мы учим ИИ видеть проект целиком. И учится сами разговаривать на его языке.
И если ИИ вдруг спросит: «А что такое микросервисы?», мы не паникуем, а просто даем ему ссылку на нашу документацию. И кофе. ☕️
@achopочом — закулисье создания стартапа🦄
#AI #документация #разработка
— Можно ли доверять ИИ писать код за нас?
— Да.
— А целиком сложный и большой проект?
— Тоже да. Если вы хотите, чтобы этот проект напоминал икебану из спагетти, сваренную слепым шеф-поваром.
---
ИИ как студент-первокурсник. Он умён, быстр, но...
видит код через «замочную скважину»: помнит только ограниченное количество строк. Остальное для него — тёмный лес.
Он пишет функции, как стихи: Красиво, но без связи друг с другом. Результат: «Hello, World!» превращается в «Goodbye, Server!».
Контекст? Не, не слышал. Спросите его про микросервисы — он начнёт рассказывать про микроволновки.
Пример из жизни:
«Напиши код для обработки платежей» → ИИ генерирует скрипт.
«А где интеграция с банком?» → «Интеграция?.. Вы не упоминали... Может, добавим котика в интерфейс?» 😺
Как же быть? Что же делать?
Документация — НАШЕ ВСЕ. И еще умение быстро откатывать плохие изменения.
Мы превратили проект в «библию для ИИ»:
— User Stories прописаны так детально, будто это сценарий для Marvel.
— Метрики и тесты — как GPS для потерявшегося курьера.
— Архитектура описана так, что даже кофеварка в офисе её поняла.
В итоге ИИ-ассистент — не враг, а коллега, который:
1. Читает документацию вместо чатов в Telegram.
2. Пишет код, который хотя бы компилируется.
3. Напоминает: «Вы тут про бэкапы забыли. Или хотите повторить историю с Titanic?»
Мы учим ИИ видеть проект целиком. И учится сами разговаривать на его языке.
И если ИИ вдруг спросит: «А что такое микросервисы?», мы не паникуем, а просто даем ему ссылку на нашу документацию. И кофе. ☕️
@achopочом — закулисье создания стартапа🦄
#AI #документация #разработка
1👍4🔥1🤔1