When I treat the AI as a focused tool, giving it specific commands like “refactor this function” or “explain this error,” the process is remarkably efficient. The work flows smoothly. But sometimes, in an attempt to truly maximize the AI’s potential, I push it further and slip into a different mode—a pattern that the developer community has aptly named “Vibe Coding.” I’m not just asking for help; I’m trying to offload the entire architectural thought process, throwing a vague, high-level prompt at it like, “build a complete service that does X, Y, and Z.”

That’s when the trouble starts.

The other day, I did exactly that. The AI generated a plausible chunk of code, but it failed on the first run. My immediate reaction wasn’t to read the code or think about the problem; it was to copy-paste the error log right back into the prompt. “Fix this,” I commanded. It gave me a new version, which then produced a different error. This loop continued for… well, for longer than I’d like to admit.

At some point, it hit me: if I had just taken 20 minutes to read the original code, maybe Google a thing or two, I would have solved the problem myself and been done hours ago. Instead, I found myself stuck in what I can only describe as my personal “Dopamine Pit”—the allure of a fully-automated, AI-generated solution had trapped me in a cycle of endless, unproductive tweaks.

I’m writing this down mostly to unpack that feeling. It’s the strange paradox of working with AI: my ambition to make the machine save me more time actually ended up creating a black hole for it. It turns out there’s a fine line between effective delegation and counterproductive abdication of your own thinking, and “Vibe Coding” with an AI is a perfect way to cross it.

Deeper Dive: The Psychology of the Dopamine Pit

The most fascinating and dangerous part of this entire cycle isn’t the faulty code; it’s what happens in my brain. The “Dopamine Pit” is so effective because it exploits the path of least resistance.

When an error pops up, I’m at a fork in the road.

Path A is the path of effort. It requires me to stop, engage my brain, read the error message, analyze the stack trace, load the surrounding code’s context into my working memory, and form a hypothesis. It’s real cognitive work.

Path B is the path of instant gratification. I just copy the error and paste it into the AI prompt with the command “fix this.” It requires almost zero mental effort, and in return, I get an immediate response—a new block of code.

That quick, effortless response is the dopamine hit. It feels like progress. My brain gets a tiny reward for taking an action, even though the action was mindless. The problem is that when the AI’s “fix” inevitably fails, my brain is already primed. The easiest thing to do—the path that offers another quick hit—is to repeat the cycle.

Each loop pulls me deeper into the pit. I’m so focused on the low-effort cycle of prompting and pasting that I fail to see the bigger picture: the cumulative time and frustration are soaring. Escaping the pit requires a moment of mindfulness—the conscious decision to choose the initial effort of Path A over the deceptive ease of Path B.

The Antidote: Working in Verifiable Chunks

So if “Vibe Coding” with an AI is the trap, what’s the way out?

After falling into that dopamine pit, I realized the solution wasn’t to stop using the AI for complex problems. The solution was to change the scope of my requests. I needed to break down the problem not just into smaller steps, but into steps whose output I could grasp and validate in seconds.

I started adhering to a simple practice: working in verifiable chunks. The principle is to never ask an AI to generate more code than you can comfortably understand and verify at a glance. The goal is to keep the cognitive overhead low.

Let’s look at the contrast:

A “Vibe Coding” Prompt (High Cognitive Load):

“Build a complete user authentication service in C# using ASP.NET Core Web API. Use JWT for tokens, Entity Framework Core to connect to a PostgreSQL database, and include endpoints for registration, login, and profile updates.”

The AI will generate a lot of code for this: multiple controllers, services, DTOs, and database context configurations. To truly verify it, you have to read every file, understand the dependency injection, check the security of the token handling, and trace the logic through multiple layers. The time you spend trying to comprehend this “instant” solution is often more than the time it would have taken to build it piece by piece yourself.

A “Verifiable Chunk” Prompt (Low Cognitive Load):

“Write a single, static C# method that validates password strength. It should take a string and return a boolean. The password must be at least 12 characters and contain an uppercase letter, a number, and a special character.”

The result of this prompt is a small, isolated method. I can read it in 30 seconds. I can see immediately if the logic is sound. I can write a quick unit test for it. I am in complete control. I can then ask for the next chunk: “Now, show me how to hash a password using BCrypt.Net.”

This approach puts me back in the driver’s seat. The AI isn’t the architect; it’s a hyper-competent assistant handling the small, well-defined tasks I delegate. This is where the real time-saving happens, without the frustrating debugging loops.

Conclusion: Staying Mindful is the Real Work

My journey into the “Dopamine Pit” wasn’t really about the AI’s failures, but about a flaw in my own workflow. It revealed a subtle but powerful psychological trap that’s easy to fall into when the promise of an instant fix is just one prompt away.

The central lesson for me has been learning to recognize that critical moment when an error appears. The real challenge isn’t technical; it’s resisting the siren call of that low-effort dopamine hit from asking the AI to “just fix it.” When I fall for that, I’m no longer developing software; I’m just managing a frustrating, unpredictable machine.

The most effective defense I’ve found against this is a practical one: working in verifiable chunks. By consciously keeping my requests small enough to be immediately understood and validated, I never cede control. The AI remains a powerful assistant, not an architect I have to blindly trust and then painfully debug.

Ultimately, the responsibility to think remains with me. The next time an error pops up, I know I have a choice: the deceptive ease of another prompt, or the real, focused effort of understanding. Choosing the latter is how I escape the pit and get back to doing the actual work.

At first glance, everything went as expected. I created several issues in my company’s private repositories (yes, you can use your private Copilot in your company’s repos). Copilot began working, and within 10-15 minutes, it started reporting that everything was done and I could begin reviewing its Pull Requests.

That’s where the fun began. My first task was to migrate a CI build from Jenkins to GHA, meaning we needed to port a Jenkinsfile to GitHub’s workflow YAML. The first issue I noticed was that Copilot doesn’t detect failed builds. Second, it can’t read failed build logs. So, when I nudged it with a ‘hey, build failed’ comment, it started peering into the sources and the new build.yml, guessing why the build might have failed. It didn’t find the root cause, but it did generate a new commit with tons of debug logs in build.yml.

I then explicitly told it what the problem with the build was and asked it to revert the last commit.

There were a few more build problems, but when I posted the build logs in the PR review comments, the bot quickly fixed everything. In the end, we merged the PR, and my initial experience is this: you get what you pay for – a junior programmer who constantly needs your attention, but at least you don’t have to work on boilerplate or tech debt tasks.

1. Сначала ставим из коробки Node-RED (настоятельно рекомендую делать все операции из-под юзера, например pi, без sudo)

   bash <(curl -sL https://raw.githubusercontent.com/node-red/raspbian-deb-package/master/resources/update-nodejs-and-nodered
   sudo systemctl enable nodered.service

2. Собираем руками open-zwave

   sudo apt install libudev-dev # ставим зависимости
   git clone https://github.com/OpenZWave/open-zwave
   make -j 4
   sudo make install # чтобы npm смог найти потом либу
   # если это не сделать, то потом при запуске node-red в логе
   # будут жалобы на линк: Error: libopenzwave.so.1.4: cannot open shared object file: No such file or directory
   export LD_LIBRARY_PATH=/usr/local/lib
   sudo ldconfig

3. Для корректной работоспособности Razberry на RPI3 нужно отключить bluetooth, потому что они оба используют один и тот же UART

   в /boot/config.txt добавить строчку
   dtoverlay=pi3-disable-bt

4. Устанавливаем в node-red нужные ноды

   cd ~/.node-red
   npm install openzwave-shared
   npm install node-red-contrib-openzwave

5. Для того, чтобы node-red смогла открыть порт /dev/ttyAMA0 (через который работает razberry) меняем настройку

   systemctl mask serial-getty@ttyAMA0.service
   в файле /boot/cmdline.txt убираем console=serial0,115200 чтобы ядро перестало писать в serial

6. reboot

{
  'target_defaults': {
    'configurations': {
      'Release': {
        'target_conditions': [
          ['OS=="win"', {
            'msvs_settings': {
               'VCCLCompilerTool': {
                  'RuntimeLibrary': '2',
                }, 
             },
          }],
        ],
      },
      'Debug': {
        'target_conditions': [
          ['OS=="win"', {
            'msvs_settings': {
               'VCCLCompilerTool': {
                   'RuntimeLibrary': '3',
                }, 
            },
          }],
        ],
      },
    },
  },
}

И пусть это сэкономит те полдня, которые пришлось потратить, чтобы выяснить этот факт.

1. Запускаем телефон в режиме BP Tools (из fastboot bootloader меню)
2. Идём в Device Manager, выбираем устройство diag_mdm и ручками ставим драйвер Motorola QC Diag Port
3. Запускаем DFS CDMA Tool (нужна старая версия, можно было скачать тут)
4. Вводим SPC 000000 и переходим во вкладку Programming
5. Находим вкладку Data и снимаем галку “Authentification require password encryption”.
6. Ребутаемся, работает 3G (EVDO Rev.A)

В результате на базе ESP8266, датчика движения BISS0001, сенсора AM2302 (DHT-22) и релешки OMRON G3MB-202P (вообще можно обойтись мосфетом, но было интересно SSD реле потыкать) был сделан контроллер ленты, который попутно сливал информацию о погоде на кухне. Всё это было аккуратно собрано в одну 6см распределительную коробочку шнайдер из “новой линии”. Напишу отдельно о процессе создания такой штуки.

Теоретически схема работала отлично, на практике тоже, датчик включал свет, через 40 секунд после последнего срабатывания выключался, температура с влажностью сливались, кроме одного нюанса: иногда свет включался сам. Системность выяснить не удавалось, поэтому пришлось демонтировать плату управления, прогреть её, почистить от флюса (я ещё тот паяльщик), но это не помогло. Пришлось гуглить и оказалось, что датчик движения чувствителен к Wi-Fi радио ESP, иными словами, когда контроллер передаёт информацию, то он может вызвать ложно-позитивное срабатывание сенсора, что приводит к включению света, несмотря на отсутствие кого-либо на кухне. Ну что же, красивую упаковку пришлось чуть разобрать и датчик вынести наружу, чтобы отдалить от радио-антенны и уменьшить наводки.

Свет стал включаться реже, но всё равно включается сам по себе. Пришлось заварить кофею и начать думать, как же поступить ещё… В голову пришла мысль заэкранировать датчик, под рукой оказалась продуктовая фольга – взял небольшой кусок, обмотал датчик движения, заизолировал изолентой внутри и снаружи и запустил систему заново.
Свет перестал включаться произвольно совсем! Теперь когда кто-то подходит к столешнице – ему услужливо включается подсветка и работает, пока этот кто-то там находится и что-то делает, после того, как человек уходит – свет отключается, а обычная кухонная фольга отлично экранирует наводки от радиосигнала Wi-Fi.

В нашем случае действие происходит на базе Ubuntu 14, PostgreSQL 9.5 установлен локально.
Первым шагом нам необходимо установить сам pghoard и supervisor, т.к. systemd нет, а запускать демона с системой нужно.

Текущая версия pghoard 1.4 в pypi нам не подходит (в ней нету поддержки новых модулей azure-storage), поэтому инсталлировать её нужно из репозитория, а поскольку pghoard работает только с третьим питоном, то делаем это с помощью pip3
UPDATE:
предварительно нужно установить модули:

azure
azure-storage==0.33

и проапгрейдить requests до версии 2.10+
END UPDATE

pip3 install git+https://github.com/ohmu/pghoard
apt-get install supervisor

Для автозапуска демона создаём конфигурационный файл pghoard.conf с минимально необходимым контентом и кладём его в /etc/supervisor/conf.d/

[program:pghoard]
user = postgres  # Запускать нужно от имени postgres, иначе не удастся подключиться к СУБД
group = postgres
directory = /var/lib/pghoard
command = /usr/local/bin/pghoard /var/lib/pghoard/pghoard.json
autostart=true
autorestart=true
environment=HOME="/var/lib/postgresql"  # Должен быть HOME пользователя postgres (туда записывается пароль и потом оттуда считывается)

Создаём пользователя в postgresql для выполнения репликации:
psql -c "CREATE USER pghoard PASSWORD 'hoardpassword' REPLICATION"

И вносим в /etc/postgresql/9.5/main/pg_hba.conf запись, разрешающую выполнять репликацию:
host replication pghoard 127.0.0.1/32 md5

В конфигурационный файл postgresql.conf нужно внести изменения, разрешающие выполнять репликацию:

max_wal_senders = 2
wal_level = archive  # 'hot_standby' or 'logical' are also ok

Перезапускаем postgresql и настраиваем pghoard на работу с Azure:

{
        "backup_location": "/var/lib/pghoard",
        "backup_sites": {
                "mysite": {
                        "nodes": [
                        {
                                "host": "127.0.0.1",
                                "password": "hoardpassword",
                                "port": 5432,
                                "user": "pghoard"
                        }
                        ],
                        "object_storage": {
                                "storage_type": "azure",
                                "account_name": "<storage-account>",
                                "account_key": "<storage-account-key>",
                                "bucket_name": "<bucket-name>"
                        }
                }
        }
}

После этого выполняем service supervisor restart и наблюдаем, как бекапы заливаются в azure blob storage.

В настоящее время для создания умного дома есть огромное количество различных решений. Если вы любитель DIY, или хотите сэкономить, а может и то, и другое – рекомендую обратить внимание на микросхемы ESP8266, или Arduino + nRF24. На базе ESP можно построить систему используя существующую домашнюю сеть Wi-Fi, на базе nRF можно построить систему по своей беспроводной сети, тоже работающией 2.4 ГГц, но не Wi-Fi, зато с преимуществом в виде возможности ретрансляции сигнала, т.е. каждая единица сети (нода) может общаться не только с контроллером, но и с другими нодами. Фактически mesh-сеть.

С экономической точки зрения ESP-12F стоит на алиэкспрессе 1.80USD за штуку, ардуино стоит 1.60USD, но к ней ещё надо дополнительно покупать трансмиттер NRF24L01+, который стоит порядка 0.9USD.

При этом у ардуины 16-32КБ памяти и слабенький 16MHz Atmel процессор, в то время, как у ESP до 4 мегабайт флеша, аппаратный Wi-Fi с шифрованием и довольно мощный 32 битный RISC процессор, работающий на 80MHz. Выливается это всё в то, что по факту в ESP можно, не сильно напрягаясь, прикрутить OTA обновления и накрутить много всякой автономной логики, например целый веб-сервер, с помощью которого управлять нодой (т.е. обходиться вообще без контроллера). Тут можно посмотреть в сторону проекта NodeMCU, ребята запилили в прошивку интерпретатор LUA с помощью которого можно накручивать весьма сложную логику прямо на устройстве, не задействуя центральный сервер – т.е. создавать автономные системы.

Z-Wave

В случае же, если есть много денег, или неохота заморачиваться с паяльником, прошивками и разного рода экспериментами – можно посмотреть на Z-Wave:
это уже вполне mature, production решение. В наличии обилие устройств самого разного назначения – и выключатели, и реле, и термостаты с датчиками – бери и образумливай дом хоть сейчас. Стоимость, при этом, немаленькая. Самое простое реле будет стоить порядка 25-30 евро, а контроллер вообще под две сотни тянет.

После нескольких лет использования Z-Wave оказалось, что я вообще сторонник гибридных решений. В части дома используется Z-Wave, в другой части появляются новые модули на базе ESP.

Чтобы всё это разнообразие взлетело, я использую в качестве контроллера Raspberry PI, к которой добавлена плата расширения RaZberry, позволяющая связываться с Z-Wave устройствами. Рядом с ней добавлена плата для связи с nRF24 устройствами, а связь с ESP осуществляется через локальную сеть.

До тех пор, пока я использовал только Z-Wave – в качестве контроллера мне хватало софта от RaZBerry, под названием Z-Way, но после того, как началась экспансия на DIY устройства – пришлось искать систему, которая сможет общаться со всем этим “зоопарком”. Мой выбор пал на Domoticz. Он умеет работать и с z-wave посредством OpenZWave, и с Arduino + nRF при помощи MySensors сборки для RPi, и с ESP через MQTT, который оказался настолько мощным и удобным протоколом, что появились даже мысли попробовать, когда-то адаптировать MySensors (или как-то написать свою прошивку) на работу через него.