The post has been translated automatically. Original language: Russian
We increasingly hear stories about people using AI tools to build apps, services, and websites in a matter of hours—work that once took days or weeks.
That is a good thing.
AI lowers the barrier to entry, helps people test ideas faster, and makes it possible to try things that once seemed too difficult. But it is important not to confuse two very different achievements: building a working prototype and creating a reliable product.
I am not opposed to AI, no-code, or low-code. Quite the opposite: I use AI extensively myself, including while building Adal, a service for receiving and delivering webhooks. It is a powerful tool when used appropriately—not because it looks modern, but because it fits the problem at hand.
A simple analogy is useful here. We use a spoon to stir sugar into a cup and a shovel to dig a hole. In theory, you could dig a hole with a spoon, but it would be slow and impractical. Technology works the same way.
An application might need a straightforward form with a few fields, clear validation, and predictable results. Or you could wrap the entire flow in AI and ask users to provide the same information in natural language. The second option may look more modern, but it immediately raises new questions: How often will the model get it wrong? What should happen when the user's answer is incomplete? How will errors be explained? How do you test such a flow? Sometimes a conventional form is simply the better tool.
The same applies to architecture. You can design a service for hundreds of thousands of requests per second even though the product currently receives only a few thousand visits a day. Sometimes that is prudent engineering. More often, it is unnecessary complexity.
The Gap Between a Prototype and a Product
AI can help test ideas, assemble an MVP, write code, generate interfaces, explain errors, and suggest architectural options. To someone without a programming background, this can look almost like magic.
But there is a wide gap between a prototype and a real product.
A prototype needs to demonstrate an idea. A product needs to operate reliably, securely, and predictably. Attractive screens and a working happy path are not enough. Access control, error handling, backups, logs, monitoring, operating costs, and edge cases all matter.
For Adal, this distinction is very concrete. A prototype webhook service might simply accept an HTTP request and forward it to another address. A real product must define what happens when the destination is temporarily unavailable, how retries behave, whether the original request is preserved without hidden changes, and whether users can make sense of its delivery history.
That is why I deliberately keep AI out of the critical webhook delivery path. AI helps me build Adal: I use it to write code, find bugs, and compare possible solutions. But receiving, storing, and delivering requests must follow explicit, testable rules. When a webhook may carry a payment confirmation, a new order, or a subscription change, predictable behavior matters more than behavior that merely appears “smart.”
AI can help with all of these concerns, but it will not automatically account for requirements it has not been given. Understanding the domain and applying engineering judgment are still essential both to frame the problem and to evaluate the result.
The Complexity You Do Not See
Consider a familiar example: Notepad in Windows. At first glance, it is one of the simplest text editors imaginable. You open a file, type some text, and save it. Yet even an application this “simple” hides a remarkable amount of complexity.
Take an ordinary period. It may look like just another character, but how should it behave when a line wraps? Can it be left at the beginning of a new line, or must it stay with the preceding word? What about quotation marks, parentheses, dashes, and ellipses?
A colon makes things more interesting. In French typography, some punctuation marks are preceded by a space, often a non-breaking one. If an editor or layout engine does not account for language-specific rules, the text may be displayed incorrectly.
Then there are languages written from right to left, such as Arabic and Hebrew. What happens when a single line contains right-to-left text alongside English words, numbers, links, and punctuation? Where should the cursor go? How should text selection, line wrapping, and search behave?
And all of this is part of a task as seemingly simple as “display text on a screen.”
The idea of displaying characters quickly turns into a collection of complex rules, exceptions, and implementation details. Someone without experience may not even know these problems exist. AI will not necessarily account for all of them unless it is given the right context. Even when it proposes a solution, only someone who understands the domain and its constraints can reliably assess it.
Responsibility Still Belongs to People
AI can write code, but it does not automatically know the full context of a product. It can suggest an architecture, but it is not accountable for your constraints. It can generate an interface, but it is not responsible for the user experience. It can assemble an MVP, but it does not bear responsibility for security, maintenance, or operations.
That is why AI should not be feared or ignored. It should be used for prototyping, exploring ideas, accelerating routine work, preparing first drafts, making targeted changes, and testing hypotheses.
AI is especially valuable when the person using it already has expertise. In that setting, it becomes a force multiplier: it helps people move faster, evaluate solutions sooner, and spend less time on mechanical work.
But when someone hands over product design, development, and technical decision-making entirely to AI, a dangerous illusion of control can emerge. Code is produced quickly, so the project appears to be moving forward. Meanwhile, its owner may gradually lose sight of how the system is structured, why it works, and what to do when something breaks.
The project then becomes a collection of generated decisions that its owner cannot confidently explain, maintain, or evolve.
AI is not a magic “make everything right” button. It is a powerful and useful tool. But it delivers its full value only in the hands of someone who understands the problem, recognizes the constraints, and is prepared to take responsibility for the decisions being made.
Всё чаще появляются истории о том, как с помощью AI-инструментов люди за несколько часов создают приложения, сервисы и сайты — то, на что раньше могли уйти дни или недели.
И это хорошо.
AI снижает порог входа, помогает быстрее проверять идеи и даёт людям возможность попробовать то, что раньше казалось слишком сложным. Но важно не перепутать две разные вещи: собрать работающий прототип и создать надёжный продукт.
Я не противник AI, no-code или low-code. Более того, я сам активно использую AI, в том числе при разработке Adal — сервиса для приёма и доставки вебхуков. Это сильный инструмент, если применять его уместно: не потому, что он выглядит современно, а потому, что подходит для конкретной задачи.
Здесь уместна простая аналогия. Чтобы размешать сахар в чашке, мы берём ложку, а чтобы выкопать яму — лопату. Теоретически яму можно выкопать и ложкой, но это будет долго и нецелесообразно. С технологиями происходит то же самое.
Можно сделать в приложении форму с несколькими полями, понятной валидацией и предсказуемым результатом. А можно обвесить всё AI и предложить пользователю вводить данные естественным языком. Второй вариант выглядит современнее, но сразу возникают вопросы: как часто модель будет ошибаться, что делать с неполными ответами, как объяснять ошибки и как тестировать такой сценарий. Иногда обычная форма — более подходящий инструмент.
Так же и с архитектурой: можно заранее проектировать сервис под сотни тысяч запросов в секунду, хотя у продукта пока несколько тысяч посещений в сутки. Иногда это предусмотрительность, но часто — переусложнение.
Между прототипом и продуктом
AI помогает проверять идеи, собирать MVP, писать код, генерировать интерфейсы, объяснять ошибки и предлагать варианты архитектуры. Для человека без опыта программирования это может выглядеть почти как магия.
Но между прототипом и настоящим продуктом есть большая дистанция.
Прототип должен показать идею. Продукт должен работать стабильно, безопасно и предсказуемо. В нём важны не только красивые экраны и рабочий happy path, но и права доступа, обработка ошибок, резервные копии, логи, мониторинг, стоимость эксплуатации и пограничные сценарии.
Для Adal это различие вполне конкретно. Прототип сервиса для вебхуков может просто принять HTTP-запрос и переслать его на другой адрес. В реальном продукте нужно решить, что произойдёт, если получатель временно недоступен, как будут выполняться повторные попытки, сохранится ли запрос без скрытых изменений и сможет ли пользователь разобраться в истории доставки.
Поэтому я сознательно не использую AI в критическом пути доставки вебхуков. AI помогает мне при разработке Adal: писать код, искать ошибки и сравнивать варианты решений. Но приём, хранение и доставка запросов должны подчиняться явным и проверяемым правилам. Когда вебхук может сообщать об оплате, заказе или изменении подписки, предсказуемость важнее внешне «умного» поведения.
AI может помочь со всем этим, но не учтёт автоматически требования, о которых ему не сообщили. Чтобы поставить задачу и оценить результат, всё равно нужны понимание предметной области и инженерное мышление.
Сложность, которой не видно
Возьмём знакомый пример — «Блокнот» в Windows. На первый взгляд это один из самых простых текстовых редакторов: открыл файл, написал текст, сохранил. Но даже в таком приложении скрыто множество нюансов.
Например, точка кажется обычным самостоятельным символом. Но можно ли оставлять её в начале новой строки или она должна переноситься вместе со словом перед ней? Как поступать с кавычками, скобками, тире и многоточием?
С двоеточием ещё интереснее. Во французской типографике перед некоторыми двойными знаками препинания ставят пробел, часто неразрывный. Если редактор или система вёрстки не учитывает языковые правила, текст может отображаться неправильно.
А есть языки с письмом справа налево, например арабский и иврит. Что делать со строкой, где одновременно есть такой текст, английские слова, числа, ссылки и знаки препинания? Как располагать курсор, выделять фрагменты, переносить строки и выполнять поиск?
И всё это относится лишь к задаче «показать текст на экране».
Простая идея быстро превращается в набор правил, исключений и технических деталей. Человек без опыта может не знать, что эти проблемы существуют. AI тоже не обязан предусмотреть их без соответствующего контекста. Даже если он предложит решение, надёжно оценить его сможет только тот, кто понимает задачу и её ограничения.
Ответственность остаётся на человеке
AI может написать код, но не знает автоматически весь контекст продукта. Может предложить архитектуру, но не несёт ответственности за ваши ограничения. Может сгенерировать интерфейс, но не отвечает за удобство пользователя. Может собрать MVP, но не отвечает за безопасность, поддержку и эксплуатацию.
Поэтому AI не нужно бояться или игнорировать. Его стоит использовать для прототипирования, поиска идей, ускорения рутинных задач, подготовки черновиков, точечных изменений и проверки гипотез.
Особенно полезен AI там, где у человека уже есть экспертиза. Тогда он становится усилителем: помогает быстрее двигаться, проверять решения и меньше времени тратить на механическую работу.
Но если полностью передать AI проектирование, разработку и технические решения, возникает иллюзия контроля. Код пишется быстро, и кажется, что проект развивается. При этом его владелец может перестать понимать, как всё устроено, почему работает и что делать, когда что-то сломается.
В результате проект превращается в набор решений, которые сложно уверенно объяснить, поддерживать и развивать.
AI — не волшебная кнопка «сделай всё правильно». Это мощный и полезный инструмент. Но он раскрывается в руках человека, который понимает задачу, видит ограничения и готов отвечать за принятые решения.
Share
