ШІ змінив поняття та підхід до MVP

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, я зараз у відпустці: вдень гуляю вулицями Анталії, а ввечері в мене з’явилося більше часу та сил позайматися власним проєктом Poklych. Тож я з Claude Code вже реалізував значну частину функціоналу, який задумав, але ще багато попереду.

І, звісно, CC займається й менеджментом моїх ідей у контексті проєкту, пропонує свої, а в кінці перед моїм сном генерує мені документ-вижимку: що вже зробили загалом, що треба зробити для запуску, а що дешевше переінженерити зараз, щоб було простіше розширювати в майбутньому.

І от читаю я цей документ-вижимку й розумію, що CC сформував дуже скупий функціонал для запуску MVP — такий, який був би актуальним у роки до ШІ. Такий функціонал був би вагомим для запуску MVP у 2016 році, проте у 2026 році треба вже робити MVP із функціоналом, який у 2016 вважався розкішшю. Планка зросла разом із тим, як подешевшала розробка.

Відповідно, щоб зробити пристойний MVP у 2016 році, потрібно було витратити від двох тижнів до двох місяців. Зараз, у 2026 році, той самий MVP можна зробити від кількох годин до тижня, проте щоб зробити його пристойним за сучасними мірками, треба витратити ті самі два+ тижні, що й у 2016.

Висновки з цього:

• Перший, який знайшов через Perplexity, коли досліджував зміну поняття MVP: ваш проєкт має містити бар’єр від простого копіювання. Або це вже клієнти, з якими у вас налагоджений зв’язок, або якась інша унікальна умова, яку складно скопіювати. Наприклад, наявність ексклюзивних сертифікованих фахівців, які можуть надавати послуги через ваш сервіс-портал MVP.
• Другий: треба вибирати мови, які будуть рятувати ШІ від помилок: Rust або Gleam, бо вибирати Ruby/Node.js/PHP/Python і навіть Java/Kotlin/C#/Go для майбутніх проєктів із сервером вважаю помилкою.

Чому Rust та Gleam? Бо обидві мови мають чудові системи типів, щоб перевіряти більшість помилок на етапі компіляції, уже мають фреймворки, що компілюються в JavaScript, і, відповідно, буде й спільний код між сервером та клієнтом, і легковаговий клієнт без важкого причепа з WASM. У Rust це Topcoat від Tokio, а у Gleam це Lustre.

Також минулого тижня творець Ruby on Rails, DHH (Девід Хайнемаєр Ханссон), розповів, що вибрав Rust для нової версії свого проєкту Hey замість RoR.

Тож писати свої нові проєкти на Node.js з Claude Code — це вже програшна стратегія.

Дякую тим, хто читав не по діагоналі, й дайте знати, чи відгукуються вам ці висновки.