Все бывает. Но короткие промты - это конкурентное преимущество. Именно короткие промты ускоряют работу. Понятно что промты не в вакууме, а в рамках проекта, который весь доступен агентам. Это глубоко ошибочная логика, что промты главное, главное для агента - проект.
Да какой вы плано можете составить, если не знаете до конца как работает периферия. Ну не смешите. Ваша портянка об этом красноречиво говорит. Claude тем и хорош что раскрывает такие детали о кторых и знать не могли. И вытягивает их из этих многомегабайтных кривых хидеров. Ну я еще PDF даю ему сканировать. Нет, планы - это не область человека. Человеку - только метод тыка хорошо подходит. Другое дело что чтобы вспомнить контекст надо создать доку с промежуточным результатом для Claude, но это не план.
Ничего не путаете опыть? Я про жесткое, а вы про теплое. Речь идет о премиум запросах, где рельно надо думать. Это наверно похоже на ваши Code Reviews, которых у вас там 100 штук. Походу вы наверно только дополнением кода пользуетесь.
Ну так в том-то и разница. Clаude понял почти как человек. Т.е. надо сделать быстро, полно, качественно и понятно заказчику. А GPT понял как тупой автомат. Упомянута в запросе одна функция - только ее и переделал, причем реально способом которым в Arduino дети делают.
Чем мощнее агент тем меньше ему что либо надо объяснять в промптах. В этом и есть прогресс.
Только что провел эксперимент. Сказал GPT 5.2 и Claude Opus 4.5 сделать одно и тоже - переписать драйвер SPI из SDK производителя в функции прямой работы с регистрами (такое нужно для сверх малого потребления функций). Ну так GPT 5.2 мне тупо переписал одну функцию отсылки в стиле Bit-banging ! И все! Ну не придраться. Да, это будет компилироваться. Но это будет не пойми с какими задержками и таймингами. Работать нормально скорее всего не будет. А Claude Opus 4.5 мне создал нормальное API с инициализацией, записью, отработкой ошибок, учетом тактовых частот шины и таймингов (он сам нашел в проекте) и дружественным отчетом от том что он сделал и почему.
Странно, в статьях про умные колонки так много расписано про растановку микрофонов, подбор их характеристик, по цифровой обработке, по акустике, материалам. А тут тяп-ляп из пластмассы и готово.
Не, что-то вы путаете. За лимит плана выходишь уже в середине месяца. Исчерпывается лимит на 1500 запросов. Плана явно не хватает. После 1500 включается взрослый счетчик. Не знаю что вы там в CLI делаете и каким образом укладываетесь в план. У меня вся работа через визуальные среды, визуальные отладчики и VS Code. VS Code сам умеет решать какому движку отдать вопрос. Так вот он GPT брезгует.
Ну я бы посмотрел как тут "порядок" понять. GPT всегда отставал и отстает, чуть чуть, но неприятно. Дольше думает и это уже жирный минус, во-вторых ну не для программирования он. Его фэйлы прям фатальные если он их делает. После него Opus знатно подчищает. А самое главное цена! Она говорит за себя.
Нюанс в том, что Claude Opus 4.5 сейчас самая дорогая модель. Одна сессия ленивого программирования пары функций в ней легко выходит в 10 $ Приходится уже думать об экономии. И да, Claude Opus 4.5 это что-то особенное. Находит ошибки в самых сложных хардварных драйверах ориентируясь только по стандартным хидерам. GPT 5.2 и рядом не валялось. Если удается создать рабочий процесс когда она может править , компилировать, запускать и видеть результат - это просто бомба, результат 100% годный. Проблема что такой процесс трудно создать. Ну и на деньги сразу влетаешь неконтролируемо. Поэтому да, сегрегация нового типа неизбежна.
Я бы даже сказал не землю делать, а кучу пар земля-сигнал для такой конфигурации щупа
Иначе можно ловить все что угодно, но только не то что нужно.
И даже не JTAG, а SWD. Тут опять проблемы разделения на электронщиков и программистов. Если программисты вообще не хотят что-то слышать об интерфейсах, то электронщики ничего не хотят знать об отладочной периферии. У ST в чипах один из лучших отладочных модулей - ARM CoreSight Segger чипы STM32 использует как эталон для своих трассировщиков. А тут UART какой-то, светодиоды ... И еще этот ужасный, бестолковый и неуклюжий PogoPins , это наверно чтоб SWD только в крайнем случае подключали. Между тем даже на самых дешевых отладках сейчас ставят инструментальные чипы для работы через SWD.
Ну вот и стоило было им заниматься. Конечно протокол проприетарный. И там адресация и маршрутизация, и механизмы масштабирования, и механизмы изоляции сбойных узлов и т.д. и т.п. Эт не BLE ломать. Свою платку сделать и уже хакать по полной гирлянду, не волнуясь какие там софтовые заплатки сделает производитель.
Одно дело защитить от хаков какого-то производителя , он и так деньги хорошие делает. И другое дело дать народу проверенную технологию двухпроводного полевого протокола.
Вместо того чтобы ковырять этот несчастный ESP лучше бы расковыряли протокол обмена с лампочками , вот это было бы интересно. Там же их тысячи, а работают удивительно синхронно.
EVT (Engineering Validation Test) — ранний этап разработки аппаратного изделия Т.е. схема по сути невалидная. Никаккого смысла ее разбирать нет. Это еще не упоминая, что такие схемы без трассировки мало что значат.
Вот почему не стоит брать "программиста микроконтроллеров" Нужно брать разработчика встраиваемых систем. А программисты они всегда такие - изолируются от железа, типа они не при чем. Что пины терминаторов можно коротнуть любой проволочкой не знают, что USB кабель можно отрезать неподходящий разъем и припаять напрямую не знают, что периферия самого CAN модуля в микроконтроллере дает достаточно флагов для определения причин проблемы не знают. Что любой микроконтроллер можно превратить через RTT в анализатор шины CAN не знают. И вообще CAN анализатор это такой примитив что его можно сделать на любой продвинутой отладочной плате. На дворе уже давно Claude Opus 4.5 Редкий осциллограф теперь не имеет декодера сигналов CAN. Словом позорище.
Но статья забавная, скромный аутистичный юмор. Ставлю плюс. Может следующая уже будет по делу.
Возраст здесь ни при чём. Я видел пенсионеров, которые ради фана подсаживаются на архаичные практики — и это нормально. Но не надо выдавать это за ноу-хау, чтобы получить признание.
Я вам так скажу. Если вы работаете с 8–16-ногими микроконтроллерами, используйте чипы с no-code-фреймворком вроде MSP Zero Code Studio и оставьте свои скрипты в прошлом. Если чипы более мощные, то RTT, SWD, USB — обязательно. И чтобы ОЗУ хватало для развёртывания веб-сервера. Тогда вы получите и скорость, и мощность отладки.
Чем быстрее отладочный вывод получает Claude, тем больше итераций в час он успевает сделать.
CMake на ура теперь конвертируются в IAR XML с помощью Claude. Вообще никакой проблемы. И линкерные файлы с тем же успехом конвертирует. Сейчас про скрипты писать - высасывать тему из пальца. Я за час превел весь хостовый стек с CMake Espresiff на IAR. И еще кучу хлама от туда выкинул. Дебажу теперь его c C-Spy в хвост и в гриву. Юзаю всю мощ таймлайнов, ITM ивентов, live view , RTT monitor, tracing. Потому что Espresiff со своим GNU создал неимоверный шлак. CLI - просто жалкий лепет зеленого джуниора, которого только что от ардуины оторвали.
Да знаете ли, паровоз не ждёт пассажиров. Не успели сделать IoT в своих девайсиках — сделают без вас. И облака теперь тоже горячая тема.
Особенно убедительно, когда приплетают холодильники и всякое такое в духе представлений прошлого века. Надеюсь, облака для пылесосов и счётчиков уже не шокируют?
Ось в современном embedded абсолютно необходима. Ее осутствие говорит о том что система недоработана в плане масштабируемости, унифицированности и универсальности. Поэтому некая "каноническая форма" никак не может быть без RTOS. Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать. Все они так или иначе будут уворовывать ресурсы времени, которые без RTOS у них отобрать и поделить не получится. Остальные пункты - вкусовщина. Claude Opus за минуты может сделать инфраструктуру для компиляции хоть GNU хоть LLVM И сорсы переделает под них. Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil. Поэтому многие SDK от производителей чипов имеют варианты для IAR. И даже Zephyr уже имеет порт для IAR. Сейчас писк моды - делать отладку через WEB интерфейс. Поэтому "каноническая форма" должна обязательно иметь WEB сервер и хранилище WEB страниц. Потому что Claude Opus идеально генерит WEB интерфейс. С графиками, таблицами, формами, редакторами - всем чем хочешь.
Нет у Arduino никакой спецификации железа. Есть спецификация на SDK, которое совмстимо с IDE или CLI. А дальше хоть на улитках делайте. Хотя да забыл , есть некая спецификация посадочного места модулей Arduino. Но это не то.
Все бывает.
Но короткие промты - это конкурентное преимущество.
Именно короткие промты ускоряют работу. Понятно что промты не в вакууме, а в рамках проекта, который весь доступен агентам.
Это глубоко ошибочная логика, что промты главное, главное для агента - проект.
Да какой вы плано можете составить, если не знаете до конца как работает периферия. Ну не смешите. Ваша портянка об этом красноречиво говорит.
Claude тем и хорош что раскрывает такие детали о кторых и знать не могли. И вытягивает их из этих многомегабайтных кривых хидеров.
Ну я еще PDF даю ему сканировать.
Нет, планы - это не область человека.
Человеку - только метод тыка хорошо подходит.
Другое дело что чтобы вспомнить контекст надо создать доку с промежуточным результатом для Claude, но это не план.
Ничего не путаете опыть?
Я про жесткое, а вы про теплое. Речь идет о премиум запросах, где рельно надо думать. Это наверно похоже на ваши Code Reviews, которых у вас там 100 штук.
Походу вы наверно только дополнением кода пользуетесь.
Ну так в том-то и разница. Clаude понял почти как человек. Т.е. надо сделать быстро, полно, качественно и понятно заказчику.
А GPT понял как тупой автомат. Упомянута в запросе одна функция - только ее и переделал, причем реально способом которым в Arduino дети делают.
Чем мощнее агент тем меньше ему что либо надо объяснять в промптах.
В этом и есть прогресс.
Только что провел эксперимент.
Сказал GPT 5.2 и Claude Opus 4.5 сделать одно и тоже - переписать драйвер SPI из SDK производителя в функции прямой работы с регистрами (такое нужно для сверх малого потребления функций).
Ну так GPT 5.2 мне тупо переписал одну функцию отсылки в стиле Bit-banging !
И все! Ну не придраться. Да, это будет компилироваться. Но это будет не пойми с какими задержками и таймингами. Работать нормально скорее всего не будет.
А Claude Opus 4.5 мне создал нормальное API с инициализацией, записью, отработкой ошибок, учетом тактовых частот шины и таймингов (он сам нашел в проекте) и дружественным отчетом от том что он сделал и почему.
Странно, в статьях про умные колонки так много расписано про растановку микрофонов, подбор их характеристик, по цифровой обработке, по акустике, материалам.
А тут тяп-ляп из пластмассы и готово.
Не, что-то вы путаете.
За лимит плана выходишь уже в середине месяца.
Исчерпывается лимит на 1500 запросов.
Плана явно не хватает. После 1500 включается взрослый счетчик.
Не знаю что вы там в CLI делаете и каким образом укладываетесь в план.
У меня вся работа через визуальные среды, визуальные отладчики и VS Code.
VS Code сам умеет решать какому движку отдать вопрос. Так вот он GPT брезгует.
Ну я бы посмотрел как тут "порядок" понять.
GPT всегда отставал и отстает, чуть чуть, но неприятно. Дольше думает и это уже жирный минус, во-вторых ну не для программирования он.
Его фэйлы прям фатальные если он их делает. После него Opus знатно подчищает.
А самое главное цена! Она говорит за себя.
Нюанс в том, что Claude Opus 4.5 сейчас самая дорогая модель.
Одна сессия ленивого программирования пары функций в ней легко выходит в 10 $
Приходится уже думать об экономии.
И да, Claude Opus 4.5 это что-то особенное.
Находит ошибки в самых сложных хардварных драйверах ориентируясь только по стандартным хидерам. GPT 5.2 и рядом не валялось.
Если удается создать рабочий процесс когда она может править , компилировать, запускать и видеть результат - это просто бомба, результат 100% годный. Проблема что такой процесс трудно создать.
Ну и на деньги сразу влетаешь неконтролируемо.
Поэтому да, сегрегация нового типа неизбежна.
Я бы даже сказал не землю делать, а кучу пар земля-сигнал для такой конфигурации щупа
Иначе можно ловить все что угодно, но только не то что нужно.
И даже не JTAG, а SWD.
Тут опять проблемы разделения на электронщиков и программистов.
Если программисты вообще не хотят что-то слышать об интерфейсах, то электронщики ничего не хотят знать об отладочной периферии.
У ST в чипах один из лучших отладочных модулей - ARM CoreSight
Segger чипы STM32 использует как эталон для своих трассировщиков.
А тут UART какой-то, светодиоды ...
И еще этот ужасный, бестолковый и неуклюжий PogoPins , это наверно чтоб SWD только в крайнем случае подключали.
Между тем даже на самых дешевых отладках сейчас ставят инструментальные чипы для работы через SWD.
Ну вот и стоило было им заниматься.
Конечно протокол проприетарный.
И там адресация и маршрутизация, и механизмы масштабирования, и механизмы изоляции сбойных узлов и т.д. и т.п.
Эт не BLE ломать.
Свою платку сделать и уже хакать по полной гирлянду, не волнуясь какие там софтовые заплатки сделает производитель.
Одно дело защитить от хаков какого-то производителя , он и так деньги хорошие делает.
И другое дело дать народу проверенную технологию двухпроводного полевого протокола.
Ну, ну. Расскажите мне про 1-wire.
Если бы там была 1-Wire, они бы секундами из одного состояния в другое переходили.
Вместо того чтобы ковырять этот несчастный ESP лучше бы расковыряли протокол обмена с лампочками , вот это было бы интересно. Там же их тысячи, а работают удивительно синхронно.
EVT (Engineering Validation Test) — ранний этап разработки аппаратного изделия
Т.е. схема по сути невалидная. Никаккого смысла ее разбирать нет. Это еще не упоминая, что такие схемы без трассировки мало что значат.
Вот почему не стоит брать "программиста микроконтроллеров"
Нужно брать разработчика встраиваемых систем.
А программисты они всегда такие - изолируются от железа, типа они не при чем.
Что пины терминаторов можно коротнуть любой проволочкой не знают, что USB кабель можно отрезать неподходящий разъем и припаять напрямую не знают, что периферия самого CAN модуля в микроконтроллере дает достаточно флагов для определения причин проблемы не знают. Что любой микроконтроллер можно превратить через RTT в анализатор шины CAN не знают. И вообще CAN анализатор это такой примитив что его можно сделать на любой продвинутой отладочной плате. На дворе уже давно Claude Opus 4.5
Редкий осциллограф теперь не имеет декодера сигналов CAN.
Словом позорище.
Но статья забавная, скромный аутистичный юмор. Ставлю плюс.
Может следующая уже будет по делу.
Возраст здесь ни при чём.
Я видел пенсионеров, которые ради фана подсаживаются на архаичные практики — и это нормально.
Но не надо выдавать это за ноу-хау, чтобы получить признание.
Я вам так скажу.
Если вы работаете с 8–16-ногими микроконтроллерами, используйте чипы с no-code-фреймворком вроде MSP Zero Code Studio и оставьте свои скрипты в прошлом.
Если чипы более мощные, то RTT, SWD, USB — обязательно. И чтобы ОЗУ хватало для развёртывания веб-сервера. Тогда вы получите и скорость, и мощность отладки.
Чем быстрее отладочный вывод получает Claude, тем больше итераций в час он успевает сделать.
CMake на ура теперь конвертируются в IAR XML с помощью Claude.
Вообще никакой проблемы. И линкерные файлы с тем же успехом конвертирует.
Сейчас про скрипты писать - высасывать тему из пальца.
Я за час превел весь хостовый стек с CMake Espresiff на IAR.
И еще кучу хлама от туда выкинул.
Дебажу теперь его c C-Spy в хвост и в гриву. Юзаю всю мощ таймлайнов, ITM ивентов, live view , RTT monitor, tracing. Потому что Espresiff со своим GNU создал неимоверный шлак.
CLI - просто жалкий лепет зеленого джуниора, которого только что от ардуины оторвали.
Да знаете ли, паровоз не ждёт пассажиров.
Не успели сделать IoT в своих девайсиках — сделают без вас.
И облака теперь тоже горячая тема.
Особенно убедительно, когда приплетают холодильники и всякое такое в духе представлений прошлого века. Надеюсь, облака для пылесосов и счётчиков уже не шокируют?
А так вообще-то речь шла об отладке.
Ось в современном embedded абсолютно необходима.
Ее осутствие говорит о том что система недоработана в плане масштабируемости, унифицированности и универсальности.
Поэтому некая "каноническая форма" никак не может быть без RTOS.
Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать.
Все они так или иначе будут уворовывать ресурсы времени, которые без RTOS у них отобрать и поделить не получится.
Остальные пункты - вкусовщина.
Claude Opus за минуты может сделать инфраструктуру для компиляции хоть GNU хоть LLVM
И сорсы переделает под них.
Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil. Поэтому многие SDK от производителей чипов имеют варианты для IAR. И даже Zephyr уже имеет порт для IAR.
Сейчас писк моды - делать отладку через WEB интерфейс.
Поэтому "каноническая форма" должна обязательно иметь WEB сервер и хранилище WEB страниц. Потому что Claude Opus идеально генерит WEB интерфейс. С графиками, таблицами, формами, редакторами - всем чем хочешь.
Нет у Arduino никакой спецификации железа. Есть спецификация на SDK, которое совмстимо с IDE или CLI. А дальше хоть на улитках делайте.
Хотя да забыл , есть некая спецификация посадочного места модулей Arduino. Но это не то.