В Zed добавили Дебаггер
Только что заметил, что в Zed, кажется, наконец-то добавили дебаггер, это была основная причина, почему я не стал на него переезжать с VSCode, а потом в моей жизни появился Cursor
Ребята делают упор на скорость (пол года назад разница с VSCode действительно ощущалась, но для меня не была критичной) и ИИ. По последнему ничего сказать не могу, но не будь у меня платной подписки на курсор, я бы попробовал.
Только что заметил, что в Zed, кажется, наконец-то добавили дебаггер, это была основная причина, почему я не стал на него переезжать с VSCode, а потом в моей жизни появился Cursor
Ребята делают упор на скорость (пол года назад разница с VSCode действительно ощущалась, но для меня не была критичной) и ИИ. По последнему ничего сказать не могу, но не будь у меня платной подписки на курсор, я бы попробовал.
Zed
The Debugger
Native support for debugging across multiple programming languages, out now in Zed.
Новые (неочевидные) Заблуждения. Часть 1
Речь пойдёт про ИИ в программировании (кто бы мог подумать, да?), а именно про то, насчет чего профессиональные разработчики, даже продвинутые в вайб-кодинге, сегодня заблуждаются.
Для начала давайте вспомним, что мы и наше окружение думали про AI Coding agents 2 года назад. Понимаю, это не просто, но давайте попытаемся.
Моя версия: подавляющее большинство, во первых, ими не пользовались, а общий консенсус был в том, что это бесполезная шляпа.
Со временем картина стала меняться — разработчики признали за LLM возможность генерировать небольшие кусочки кода и, как следствие, допустили ИИ автокомплит. Но ИИ по прежнему было отказано в том, чтобы работать с большим контекстом.
Оно и понятно, нынче не то что давеча. В смысле, нейронки 2 года назад и сейчас это две большие разницы. Таким образом, консенсус остался на уровне "этому есть применение, но оно никогда не заменит настоящего программиста".
На вопрос "почему" можно (до сих пор) услышать что-то про "понимание" или, упаси господь, "сознание".
Хорошо. А что думают профессиональные разработчики сегодня, два года спустя?
Моя версия :) Подавляющее большинство, во первых, стали пользоваться — LLM-based инструментарий в том или ином виде проник всюду: в терминалы, кодовые редакторы и даже браузеры. Два года назад надо было быть "гиком" ИИ-программирования, сегодня это мейнстрим.
Сегодня у нас есть "вайб-кодинг" как методология (не побоюсь этого слова) разработки софта без, собственно, ручного кодинга. То есть то, чему "есть применение" в итоге вообще вытеснело все остальное. Ну, то есть, конечно еще нет. Но отдельные люди вайб-кодят отдельные штуки, это реальность.
А что стало с общим консенсусом? Я бы сформулировал его теперь так:
"ИИ-кодинг реален, и при должном умении можно даже реализовать довольно сложную задачу. Но! Во-первых, иногда это все равно проще сделать руками, а во-вторых, рано или поздно вайб-кодинг сломается (см. мой пост про бота) и тебе все равно придется лезть под капот руками. Тебе все равно придется разбираться, как это работает. Тебе придется наводить порядок в хаосе, который создал ИИ. Так что эта штука все равно не заменит настоящего программиста!"
Вторая часть тут.
Речь пойдёт про ИИ в программировании (кто бы мог подумать, да?), а именно про то, насчет чего профессиональные разработчики, даже продвинутые в вайб-кодинге, сегодня заблуждаются.
Для начала давайте вспомним, что мы и наше окружение думали про AI Coding agents 2 года назад. Понимаю, это не просто, но давайте попытаемся.
Моя версия: подавляющее большинство, во первых, ими не пользовались, а общий консенсус был в том, что это бесполезная шляпа.
Со временем картина стала меняться — разработчики признали за LLM возможность генерировать небольшие кусочки кода и, как следствие, допустили ИИ автокомплит. Но ИИ по прежнему было отказано в том, чтобы работать с большим контекстом.
Оно и понятно, нынче не то что давеча. В смысле, нейронки 2 года назад и сейчас это две большие разницы. Таким образом, консенсус остался на уровне "этому есть применение, но оно никогда не заменит настоящего программиста".
На вопрос "почему" можно (до сих пор) услышать что-то про "понимание" или, упаси господь, "сознание".
Хорошо. А что думают профессиональные разработчики сегодня, два года спустя?
Моя версия :) Подавляющее большинство, во первых, стали пользоваться — LLM-based инструментарий в том или ином виде проник всюду: в терминалы, кодовые редакторы и даже браузеры. Два года назад надо было быть "гиком" ИИ-программирования, сегодня это мейнстрим.
Сегодня у нас есть "вайб-кодинг" как методология (не побоюсь этого слова) разработки софта без, собственно, ручного кодинга. То есть то, чему "есть применение" в итоге вообще вытеснело все остальное. Ну, то есть, конечно еще нет. Но отдельные люди вайб-кодят отдельные штуки, это реальность.
А что стало с общим консенсусом? Я бы сформулировал его теперь так:
"ИИ-кодинг реален, и при должном умении можно даже реализовать довольно сложную задачу. Но! Во-первых, иногда это все равно проще сделать руками, а во-вторых, рано или поздно вайб-кодинг сломается (см. мой пост про бота) и тебе все равно придется лезть под капот руками. Тебе все равно придется разбираться, как это работает. Тебе придется наводить порядок в хаосе, который создал ИИ. Так что эта штука все равно не заменит настоящего программиста!"
Вторая часть тут.
Новые (неочевидные) Заблуждения. Часть 2
Начало тут.
Ничего не напоминает? Не правда ли это "конвенционально адекватное" мнение кажется чем-то рациональным?
На самом деле, если вы так думаете, вы ведете себя как то самое "подавляющее большинство" из 2023.
(Даже смешно делать такие отсылки к временам двухгодичной давности, но что поделать, вот с такой скоростью развивается прогресс в нашей области.)
Всем, кто лапочет про понимание и сознание я предлагаю сперва задаться вопросам, уверены ли они, что понимают, о чем говорят и откуда у них эта уверенность, если она, не приведи Господь, у них есть.
Всех остальных предлагаю задуматься вот над чем:
А что если пройдет еще два года и вайб-кодинг перестанет ломаться, потому что ИИ станет достаточно умен? Код больше не будет превращаться в хаос, потому что ИИ будет следить за его чистотой на уровне senior software engineer.
Можно сделать еще один мысленный прыжок и представить, что и другие недостатки сегодняшнего ИИ-кодинг инструментария будут устранены.
Например, ИИ будет не просто писать код, а также следить за его работоспособностью — открывать браузер и протыкивать там фичу, анализировать логи, прогонять тесты.
Более того, он будет собирать это в единую картину. Первые шаги в эту сторону уже делаются, Cursor видит ошибки линтинга/компиляции и учитывает их, не хватает только интеграции с остальными частями системы.
Человек — это клей, который интегрирует разрозненные части.
Это не единственная роль человека в разработке (например, есть еще коммуникация с остальной командой, проектирование, ревью), но я, если честно, не вижу здесь вообще ничего, что не могло бы быть автоматизировано в следующие пару лет.
И мне кажется, что нам очень повезет, если это займет больше времени.
Потому что бизнес спит и видит, как инструментарий такого уровня достигает enterprise качества. И доказательство этому — деньги. Просто посмотрите сколько денег инвестируется во все, что связано с ИИ кодингом.
Я бы добавил, что для достижения этого нам не нужны никакие прорывы в LLM инжиниринге. У нас все уже есть. Нам нужно время чтобы разработать и обкатать инженерные подходы — как правильно стыковать куски таких систем вместе, чтобы это работало хорошо.
Как правильно применять оптимизации, чтобы есть меньше токенов и прочее. Это перешло из технологической/научной в чисто инженерную проблему. И это вопрос времени.
Популярная и чертовски притягательная сегодня мысль что "кто-то же должен придти и навести порядок за всеми этими вайбкодерами, скоро они столкнуться с реальностью и придут к НАМ, настоящим программистам" не более чем заблуждение. И для меня это было неочевидное заблуждение, хотя я веду канал про ИИ-кодинг.
P.S. - Я не думаю, что мы лишимся работы в следующие два года.
Во-первых, я могу быть просто напросто не прав. Я могу не видеть каких-то больших проблем, как это часто бывает в инженерии.
Во-вторых, прогресс распространяется неравномерно, и в мире все еще достаточно бизнеса, который не внедрил LLM-based tooling.
Но я думаю, что большинство профессиональных (именно они, точнее мы, подвержены этому когнитивному искажению сильнее всего) разработчиков сегодня заблуждаются насчет того, в каком состоянии на самом деле находятся AI Coding технологии сегодня.
Начало тут.
Ничего не напоминает? Не правда ли это "конвенционально адекватное" мнение кажется чем-то рациональным?
На самом деле, если вы так думаете, вы ведете себя как то самое "подавляющее большинство" из 2023.
(Даже смешно делать такие отсылки к временам двухгодичной давности, но что поделать, вот с такой скоростью развивается прогресс в нашей области.)
Всем, кто лапочет про понимание и сознание я предлагаю сперва задаться вопросам, уверены ли они, что понимают, о чем говорят и откуда у них эта уверенность, если она, не приведи Господь, у них есть.
Всех остальных предлагаю задуматься вот над чем:
А что если пройдет еще два года и вайб-кодинг перестанет ломаться, потому что ИИ станет достаточно умен? Код больше не будет превращаться в хаос, потому что ИИ будет следить за его чистотой на уровне senior software engineer.
Можно сделать еще один мысленный прыжок и представить, что и другие недостатки сегодняшнего ИИ-кодинг инструментария будут устранены.
Например, ИИ будет не просто писать код, а также следить за его работоспособностью — открывать браузер и протыкивать там фичу, анализировать логи, прогонять тесты.
Более того, он будет собирать это в единую картину. Первые шаги в эту сторону уже делаются, Cursor видит ошибки линтинга/компиляции и учитывает их, не хватает только интеграции с остальными частями системы.
Человек — это клей, который интегрирует разрозненные части.
Это не единственная роль человека в разработке (например, есть еще коммуникация с остальной командой, проектирование, ревью), но я, если честно, не вижу здесь вообще ничего, что не могло бы быть автоматизировано в следующие пару лет.
И мне кажется, что нам очень повезет, если это займет больше времени.
Потому что бизнес спит и видит, как инструментарий такого уровня достигает enterprise качества. И доказательство этому — деньги. Просто посмотрите сколько денег инвестируется во все, что связано с ИИ кодингом.
Я бы добавил, что для достижения этого нам не нужны никакие прорывы в LLM инжиниринге. У нас все уже есть. Нам нужно время чтобы разработать и обкатать инженерные подходы — как правильно стыковать куски таких систем вместе, чтобы это работало хорошо.
Как правильно применять оптимизации, чтобы есть меньше токенов и прочее. Это перешло из технологической/научной в чисто инженерную проблему. И это вопрос времени.
Популярная и чертовски притягательная сегодня мысль что "кто-то же должен придти и навести порядок за всеми этими вайбкодерами, скоро они столкнуться с реальностью и придут к НАМ, настоящим программистам" не более чем заблуждение. И для меня это было неочевидное заблуждение, хотя я веду канал про ИИ-кодинг.
P.S. - Я не думаю, что мы лишимся работы в следующие два года.
Во-первых, я могу быть просто напросто не прав. Я могу не видеть каких-то больших проблем, как это часто бывает в инженерии.
Во-вторых, прогресс распространяется неравномерно, и в мире все еще достаточно бизнеса, который не внедрил LLM-based tooling.
Но я думаю, что большинство профессиональных (именно они, точнее мы, подвержены этому когнитивному искажению сильнее всего) разработчиков сегодня заблуждаются насчет того, в каком состоянии на самом деле находятся AI Coding технологии сегодня.
This media is not supported in your browser
VIEW IN TELEGRAM
7 раз Отмерь, 1 раз Отрежь
Дано: Claude 4 + Cursor + проект на Go.
Задача: реализовать фичу, которая затрагивает вообще всё — схему базы данных, SQL запросы, локализацию, конфигурацию, бизнес-логику и так далее. Сможем сделать через автономного агента? Учитывая, что это не локальный прототип, а запущенный в прод с живыми юзерами продукт?
Pure Manual <—> Vibe Coding
Лично я под "вайб-кодингом" подразумеваю подход, когда ты не понимаешь, как работает твой код.
Это не обязательно плохо — если ты осознаешь этот риск, то почему нет? Однако, с текущим уровнем технологий, на этом подходе далеко не уедешь.
Подобно тому, как динамические языки оправдывают себя лишь до определенных масштабов, вайб-кодинг обязательно сломается, когда проект достигнет некоторого размера, а тебе придется разбираться, как работает вся эта любезно нагенерированная лапша.
Только ситхи всё возводят в абсолют — пренебрегать genAI инструментами и делать все самостоятельно ровно в той же степени неправильно, как и заниматься pure вайб-кодингом. Если, конечно, речь не идет об обучении или разработке "прототипа на коленке" который мы сто процентов потом выкинем.
ИИ не должен принимать решений
Помните исходную задачу? Секрет в том, чтобы не полагаться на ИИ в принятии решений, чтобы он был исключительно исполнителем. Все решения вы должны принимать сами.
Это не значит, что вы не можете их обсудить с ИИ! Если вы не уверены в дизайне, обязательно сделайте это. Главное убедитесь, что построили богатый контекст, чтобы агент действительно понимал суть вашего вопроса относительно вашего проекта.
Я настоятельно советую это делать, потому что условный Claude 4 может подсветить не мало потенциальных проблем, особенно, если его об этом попросить.
Отмеряем 7 раз
Продолжаю раскрывать секрет. Если ИИ не должен принимать решений, их должны принимать вы. Следовательно, вы должны понимать, как все работает и как все должно работать.
Точнее у вас должно быть решение, которое вы предлагаете ИИ, чтобы он его "прожарил", и это решение вы должны осознавать полностью, вплоть до отдельных переменных.
Итак, вы описываете решение, начиная с мотивации, что и зачем вы делаете и какую проблему решаете, объясняете какие компоненты системы поменяются и как, и ссылаетесь на конкретные файлы - схемы базы данных, запросы, файлы с исходным кодом. Вы строите контекст, тут тонкая грань — собрать как можно больше всего, что понадобится и зацепить как можно меньше того, что к задаче не относится.
Далее, внимание (!), вы требуете чтобы ИИ не модифицировал код (я прям капсом это пишу, потому что Claude 4 любит настырничать), а просто ответил вам, что он думает, все ли ему ясно, не видит ли он проблем.
Вы повторяете это N раз пока не будет достигнуто полное понимание между вами и агентом. ИИ может находить потенциальные проблемы, подсвечивать какие-то правки, о которых вы забыли, или находить в задаче неоднозначности, предлагая вам решения на выбор.
Отрезаем один раз
Когда понимание, наконец, достигнуто, мы просим ИИ (внимание!), нет, не внести правки, а сгенерировать детальный промпт, который мы вставим в новое окно чата. Мы прямо так и говорим — контекстное окно приближается к лимиту, сделай мне промпт, но не упусти ничего важного.
Контекстное окно Claude 4 на самом деле далеко от предела, но если нам предстоит править десяток другой файлов, а между этими правками модельке еще предстоит размышлять и выполнять команды, а возможно еще и гуглить что-то, то окошко легко может треснуть.
Ну а потом открываем новый чат, вставляем промпт, можем пробежаться по нему последний раз и подправить, если очень надо.
Кстати, пока я писал этот пост, Claude 4 имплементит штуку со криншотов. На прикрепленной gif то как строился промпт, а в комментах скрин — кусочек получившегося промпта.
Дано: Claude 4 + Cursor + проект на Go.
Задача: реализовать фичу, которая затрагивает вообще всё — схему базы данных, SQL запросы, локализацию, конфигурацию, бизнес-логику и так далее. Сможем сделать через автономного агента? Учитывая, что это не локальный прототип, а запущенный в прод с живыми юзерами продукт?
Pure Manual <—> Vibe Coding
Лично я под "вайб-кодингом" подразумеваю подход, когда ты не понимаешь, как работает твой код.
Это не обязательно плохо — если ты осознаешь этот риск, то почему нет? Однако, с текущим уровнем технологий, на этом подходе далеко не уедешь.
Подобно тому, как динамические языки оправдывают себя лишь до определенных масштабов, вайб-кодинг обязательно сломается, когда проект достигнет некоторого размера, а тебе придется разбираться, как работает вся эта любезно нагенерированная лапша.
Только ситхи всё возводят в абсолют — пренебрегать genAI инструментами и делать все самостоятельно ровно в той же степени неправильно, как и заниматься pure вайб-кодингом. Если, конечно, речь не идет об обучении или разработке "прототипа на коленке" который мы сто процентов потом выкинем.
ИИ не должен принимать решений
Помните исходную задачу? Секрет в том, чтобы не полагаться на ИИ в принятии решений, чтобы он был исключительно исполнителем. Все решения вы должны принимать сами.
Это не значит, что вы не можете их обсудить с ИИ! Если вы не уверены в дизайне, обязательно сделайте это. Главное убедитесь, что построили богатый контекст, чтобы агент действительно понимал суть вашего вопроса относительно вашего проекта.
Я настоятельно советую это делать, потому что условный Claude 4 может подсветить не мало потенциальных проблем, особенно, если его об этом попросить.
Отмеряем 7 раз
Продолжаю раскрывать секрет. Если ИИ не должен принимать решений, их должны принимать вы. Следовательно, вы должны понимать, как все работает и как все должно работать.
Точнее у вас должно быть решение, которое вы предлагаете ИИ, чтобы он его "прожарил", и это решение вы должны осознавать полностью, вплоть до отдельных переменных.
Итак, вы описываете решение, начиная с мотивации, что и зачем вы делаете и какую проблему решаете, объясняете какие компоненты системы поменяются и как, и ссылаетесь на конкретные файлы - схемы базы данных, запросы, файлы с исходным кодом. Вы строите контекст, тут тонкая грань — собрать как можно больше всего, что понадобится и зацепить как можно меньше того, что к задаче не относится.
Далее, внимание (!), вы требуете чтобы ИИ не модифицировал код (я прям капсом это пишу, потому что Claude 4 любит настырничать), а просто ответил вам, что он думает, все ли ему ясно, не видит ли он проблем.
Вы повторяете это N раз пока не будет достигнуто полное понимание между вами и агентом. ИИ может находить потенциальные проблемы, подсвечивать какие-то правки, о которых вы забыли, или находить в задаче неоднозначности, предлагая вам решения на выбор.
Отрезаем один раз
Когда понимание, наконец, достигнуто, мы просим ИИ (внимание!), нет, не внести правки, а сгенерировать детальный промпт, который мы вставим в новое окно чата. Мы прямо так и говорим — контекстное окно приближается к лимиту, сделай мне промпт, но не упусти ничего важного.
Контекстное окно Claude 4 на самом деле далеко от предела, но если нам предстоит править десяток другой файлов, а между этими правками модельке еще предстоит размышлять и выполнять команды, а возможно еще и гуглить что-то, то окошко легко может треснуть.
Ну а потом открываем новый чат, вставляем промпт, можем пробежаться по нему последний раз и подправить, если очень надо.
Кстати, пока я писал этот пост, Claude 4 имплементит штуку со криншотов. На прикрепленной gif то как строился промпт, а в комментах скрин — кусочек получившегося промпта.
Bonus Tip
Недавно писал, как правильно кодить большие фичи с ИИ. Прочтите, если еще не, а потом вернитесь. Есть еще один совет, это как вишенка на торте к тому, что уже было описано
Перед тем как начать ревьюить изменения (что делать при таком подходе, разумеется, необходимо), откройте новый чат, и попросите Claude 4 проревьюить изменения за вас.
Скажите, мол, ИИ сделал изменения, вот его промпт, вот изменения что он сделал (mention git changes). После того как ИИ подтвердит, что все ок, начинайте ревьюить сами.
P.S. — Прикладываю размер ИИ правок. Я сперва протестировал изменения локально, всё работает идеально. Полез ревьюить, реализация на 5+, я бы не сделал лучше, всё как я хотел. Сейчас буду катить на прод.
Недавно писал, как правильно кодить большие фичи с ИИ. Прочтите, если еще не, а потом вернитесь. Есть еще один совет, это как вишенка на торте к тому, что уже было описано
Перед тем как начать ревьюить изменения (что делать при таком подходе, разумеется, необходимо), откройте новый чат, и попросите Claude 4 проревьюить изменения за вас.
Скажите, мол, ИИ сделал изменения, вот его промпт, вот изменения что он сделал (mention git changes). После того как ИИ подтвердит, что все ок, начинайте ревьюить сами.
P.S. — Прикладываю размер ИИ правок. Я сперва протестировал изменения локально, всё работает идеально. Полез ревьюить, реализация на 5+, я бы не сделал лучше, всё как я хотел. Сейчас буду катить на прод.
Галерея Промптов в ИИ браузере Dia
Помните, я писал, что пересел с Arc на его наследник, так как сам Arc прекращают поддерживать? Так вот, все это время я сидел на Dia, мое резюме будет в конце поста, а сейчас я расскажу про их последний апдейт, где они выкатили галлерею skills.
https://www.diabrowser.com/skills
Skills в Dia это возможность сохранить промпт под короткий алиас и вызвать его в чате. На вход в ИИ идет этот промпт + контекст страницы + ваше сообщение. Так, например, можно просить ЛЛМ сделать TLDR; страницы (или письма, если вы смотрите на письмо) на русском, или генерировать ответы. Кейсов множество. Я, кстати, скилами не пользуюсь вообще, и вроде я среди юзеров Dia такой не один, судя по постам на Reddit. Посмотрим, изменится ли это теперь.
Что касается самого Dia... Это не Arc, но и не голый Chrome. Я скучаю по вертикальным вкладкам со спейсами, как и все аркоебы, волею судеб пересевшие на Dia, но мне нравится ИИ чат. Он работает хорошо и я пользуюсь им достаточно часто. Было бы интересно попробовать Comet от Perplexity, но мотивации недостаточно. Миграция между браузерами слишком запарный процесс. Transaction Cost у операции высокий.
P.S. Для тех, кому интересна продуктовая аналитика — конкретно тот кейс, что я рассматривал в своем первом посте про Dia, q&a с продуктовой аналитикой, теперь работает из коробки в Posthog. То есть если вы используете Posthog для метрик, то там теперь есть встроенный чат под названием Max AI, и я советую юзать его, а не Dia, потому что у Dia доступ к содержимому вкладки, а у Max под капотом RAG в базу с вашими событиями. У него тупо больше контекста. F context is king, как известно.
Помните, я писал, что пересел с Arc на его наследник, так как сам Arc прекращают поддерживать? Так вот, все это время я сидел на Dia, мое резюме будет в конце поста, а сейчас я расскажу про их последний апдейт, где они выкатили галлерею skills.
https://www.diabrowser.com/skills
Skills в Dia это возможность сохранить промпт под короткий алиас и вызвать его в чате. На вход в ИИ идет этот промпт + контекст страницы + ваше сообщение. Так, например, можно просить ЛЛМ сделать TLDR; страницы (или письма, если вы смотрите на письмо) на русском, или генерировать ответы. Кейсов множество. Я, кстати, скилами не пользуюсь вообще, и вроде я среди юзеров Dia такой не один, судя по постам на Reddit. Посмотрим, изменится ли это теперь.
Что касается самого Dia... Это не Arc, но и не голый Chrome. Я скучаю по вертикальным вкладкам со спейсами, как и все аркоебы, волею судеб пересевшие на Dia, но мне нравится ИИ чат. Он работает хорошо и я пользуюсь им достаточно часто. Было бы интересно попробовать Comet от Perplexity, но мотивации недостаточно. Миграция между браузерами слишком запарный процесс. Transaction Cost у операции высокий.
P.S. Для тех, кому интересна продуктовая аналитика — конкретно тот кейс, что я рассматривал в своем первом посте про Dia, q&a с продуктовой аналитикой, теперь работает из коробки в Posthog. То есть если вы используете Posthog для метрик, то там теперь есть встроенный чат под названием Max AI, и я советую юзать его, а не Dia, потому что у Dia доступ к содержимому вкладки, а у Max под капотом RAG в базу с вашими событиями. У него тупо больше контекста. F context is king, как известно.
Telegram
AI Coder 🦾
Протестировал ИИ-браузер от создателей Arc 🌐
Прикрепляю скриншот, как я анализирую продуктовые метрики в одном из своих проектов с помощью этого браузера.
Речь идет о браузере Dia. Он сейчас в закрытой бете, но если вы были пользователем Арка, то вас пустят…
Прикрепляю скриншот, как я анализирую продуктовые метрики в одном из своих проектов с помощью этого браузера.
Речь идет о браузере Dia. Он сейчас в закрытой бете, но если вы были пользователем Арка, то вас пустят…
Allowlist в Cursor
То ли не видел, то ли недавно добавили.
Раньше в Cursor чате с Agent mode было 2 опции: либо каждую команду надо апрувить, либо разрешить все и пустить тем самым на самотек.
Лично мне не очень хотелось узреть условный
Allowlist это золотая середина — когда агент хочет выполнить команду, теперь можно ее не только апрувнуть или зареджектить, но также апрувнуть и добавить в белый список, чтобы он больше не спрашивал.
Осторожно: тут есть нюанс, команды в UNIX чейнятся через разными способами (&&, |, >, » и так далее), и кажется что курсор при проверке прав смотрит только на первую команду, а все остальное парсит как ее аргументы. То есть разрешив
UPD: кажется курсор таки понимает
То ли не видел, то ли недавно добавили.
Раньше в Cursor чате с Agent mode было 2 опции: либо каждую команду надо апрувить, либо разрешить все и пустить тем самым на самотек.
Лично мне не очень хотелось узреть условный
rm -rf / в результате гениального мыслительного хода Claude и я ревьюил каждую команду. Когда агент пилит большую многослойную фичу, получается, что надо микроменеджерить, иначе спустя 5-10 минут ты альт-табнешься обратно в чат и увидишь, что все это время машина ждала тебя, кожанный ты боттлнек.Allowlist это золотая середина — когда агент хочет выполнить команду, теперь можно ее не только апрувнуть или зареджектить, но также апрувнуть и добавить в белый список, чтобы он больше не спрашивал.
Осторожно: тут есть нюанс, команды в UNIX чейнятся через разными способами (&&, |, >, » и так далее), и кажется что курсор при проверке прав смотрит только на первую команду, а все остальное парсит как ее аргументы. То есть разрешив
cd в теории вы разрешаете также cd / && rm -rf ./ но это не точно. Ну я включил, посмотрим, не поминайте лихом.UPD: кажется курсор таки понимает
&& и запросил у меня разрешение на cd ... && templ ..., формулируя это как "добавить templ в белый список?"Написал статью про фронтенд на Хабр
Как я люблю, без кода, простыми словами про что есть что.
— RU: https://habr.com/ru/articles/934486/
— EN: https://medium.com/@emil.musician/htmx-alpinejs-ssr-v1-2-3-and-spa-easy-missing-guide-f60af888e1e0 (тут с картинками)
Как я люблю, без кода, простыми словами про что есть что.
— RU: https://habr.com/ru/articles/934486/
— EN: https://medium.com/@emil.musician/htmx-alpinejs-ssr-v1-2-3-and-spa-easy-missing-guide-f60af888e1e0 (тут с картинками)
Хабр
HTMX, AlpineJS, SSR v1/2/3 и SPA. Что к чему
HTMX и AlpineJS HTMX и AlpineJSэто две JS библиотеки, которые расширяют HTML специальными аттрибутами и позволяют писать фронтенд без SPA фреймворков. Это альтернативы React/Vue/Angular и иже...
Как я Фикшу Баг в Cursor
TLDR; На проде баг, из-за которого платный юзер продукта получает ошибку, вместо корректной обработки своего запроса.
Раньше, я полез бы в логи, а затем начал бы думать, в чем дело. Сейчас я делаю вот как:
— Открываю чат в курсоре
— Прикрепляю скрин с багом
— Описываю проблему вкратце
— Прикрепляю логи с прода
— Прикрепляю релевантную строчку из таблицы в БД, чтоб контекст был совсем полным
Наверно, вместо последнего шага можно было бы MCP заюзать, чтоб агент сам в базу сходил, если б посчитал нужным, но у меня пока с ними не сложилось.
То, что я сделал, называется "построить контекст". По сути, когда вы ставите задачу другому человеку, вы тоже строите контекст.
Кто-то, наверно, может сказать — теперь ИИ и думает за тебя, а не просто код пишет.
Я отвечу так — да, и это хорошо. Я не хочу об этом думать. Я не считаю, что это творческая задача. Я знаю, что могу потратить время и сделать все сам, но зачем? Мое время ограниченно, мне надо распределить мыслетопливо максимально эффективно. Если я могу делегировать ИИ агенту исправление бага, то я обязан это сделать. Любая другая стратегия не будет рациональной, если ваша цель — эффективность.
P.S. — Офигеть, курсор теперь mermaid диаграммы строит в процессе рассуждения О_о
P.S.S. — Claude 4 любит добавлять юнит-тесты, и они даже валидны, но если вам хочется перестраховаться еще сильнее, примените технику ИИ самопроверки
TLDR; На проде баг, из-за которого платный юзер продукта получает ошибку, вместо корректной обработки своего запроса.
Раньше, я полез бы в логи, а затем начал бы думать, в чем дело. Сейчас я делаю вот как:
— Открываю чат в курсоре
— Прикрепляю скрин с багом
— Описываю проблему вкратце
— Прикрепляю логи с прода
— Прикрепляю релевантную строчку из таблицы в БД, чтоб контекст был совсем полным
Наверно, вместо последнего шага можно было бы MCP заюзать, чтоб агент сам в базу сходил, если б посчитал нужным, но у меня пока с ними не сложилось.
То, что я сделал, называется "построить контекст". По сути, когда вы ставите задачу другому человеку, вы тоже строите контекст.
Кто-то, наверно, может сказать — теперь ИИ и думает за тебя, а не просто код пишет.
Я отвечу так — да, и это хорошо. Я не хочу об этом думать. Я не считаю, что это творческая задача. Я знаю, что могу потратить время и сделать все сам, но зачем? Мое время ограниченно, мне надо распределить мыслетопливо максимально эффективно. Если я могу делегировать ИИ агенту исправление бага, то я обязан это сделать. Любая другая стратегия не будет рациональной, если ваша цель — эффективность.
P.S. — Офигеть, курсор теперь mermaid диаграммы строит в процессе рассуждения О_о
P.S.S. — Claude 4 любит добавлять юнит-тесты, и они даже валидны, но если вам хочется перестраховаться еще сильнее, примените технику ИИ самопроверки
Как строить контекст для ИИ агента в Cursor, основанный на изменениях кода
Уже два человека просили раскрыть мысль про ИИ самопроверку в Cursor получше.
Думаю, я напишу об этом нормальную статью. Кажется, мой поток сознания на эту тему тяжело читается.
Пока статьи нет, расскажу про маленькую фичу в Cursor, которая играет важную роль в вышеприведенной технике. Кажется, не все про эту фичу знают.
1️⃣ Открываем чат с агентом (
2️⃣ Жмакаем
3️⃣ В открывшейся выпадашке выбираем
Это позволяет в 1 клик построить контекст для агента, основанный на изменениях кода, а не его состоянии. Что необходимо для техники самопроверки.
P.S. — статью напишу, потому что техника реально мощная и, кажется, не все про нее в курсе.
Уже два человека просили раскрыть мысль про ИИ самопроверку в Cursor получше.
Думаю, я напишу об этом нормальную статью. Кажется, мой поток сознания на эту тему тяжело читается.
Пока статьи нет, расскажу про маленькую фичу в Cursor, которая играет важную роль в вышеприведенной технике. Кажется, не все про эту фичу знают.
1️⃣ Открываем чат с агентом (
Cmd+I на маке)2️⃣ Жмакаем
@ собачку и выбираем Git3️⃣ В открывшейся выпадашке выбираем
Branch либо Commit в зависимости от того, что нас интересует (уже закомиченные изменения, или текущие).Это позволяет в 1 клик построить контекст для агента, основанный на изменениях кода, а не его состоянии. Что необходимо для техники самопроверки.
P.S. — статью напишу, потому что техника реально мощная и, кажется, не все про нее в курсе.
В полку ИИ браузеров прибыло
https://strawberrybrowser.com/
Продукт в закрытой бете. Обещают автономных агентов в вебе, через которых можно автоматизировать рутинные задачи. Забудьте, мол, про рутину, отправляйте роботов-рабов делать рисерчи, выгребать данные, заполнять формы и проч.
Я сижу на Dia и у меня недостаточно мотивации пробовать что-то еще, но я прям чувствую, что что-то упускаю. В 2025 браузеры реально могут и должны больше, чем просто chat with your tabs или, прости господи, skills.
https://strawberrybrowser.com/
Продукт в закрытой бете. Обещают автономных агентов в вебе, через которых можно автоматизировать рутинные задачи. Забудьте, мол, про рутину, отправляйте роботов-рабов делать рисерчи, выгребать данные, заполнять формы и проч.
Я сижу на Dia и у меня недостаточно мотивации пробовать что-то еще, но я прям чувствую, что что-то упускаю. В 2025 браузеры реально могут и должны больше, чем просто chat with your tabs или, прости господи, skills.
Strawberrybrowser
Strawberry — Intuitive AI in Your Tabs
The self-driving browser. Build your own team of AI agents that browse, research, and automate tasks across your tabs.
Все еще пишете commit messages руками? Тогда мы идем к вам!
Буквально до вчерашнего дня я всегда писал комиты сам. Я много лет работал в командах от мала до велика и содержательность комитов считалась чем-то важным. На одном из моих первых мест работы гит вообще возвели в культ, на ревью буквально требовали переименования комитов, сквошей, ревертов мержей на ребейзы и прочей ереси.
Мое мнение на эту тему такое — гит надо понимать, но лишь основные концепты - ветвление, ребейзинг, слияние. Не надо упарываться в идеальные commit messages, не надо дрочить на красивые графы. Вам даже не обязательно уметь работать с ним через терминал, вот что я думаю. Говорю как человек очень много времени работающий с гитом исключительно в консоли.
Так вот, commit messages. Бывают штуки вроде Conventional Commits и я очень долго им следовал, даже работая один. И вот только недавно до меня дошло — наименования коммитов это своего рода индекс, который позволяет быстрее понять, что в этом комите происходит, не заглядывая в него. Это то же самое, что нейминг сущностей в коде. Вот только код мы читаем постоянно, а как часто мы читаем историю git? Если это большой проект и вас туда комитит человек 5, окей, возможно, но если вас 2-3 или тем более вы один, ну камон. Я в своих пет проектах почти никогда не смотрю историю. Только если я что-то зафакапил, но я редко что-то факаплю, когда весь код принадлежит мне и я его хорошо понимаю и ощущаю.
Короче, советую не париться и генерировать коммиты через ИИ. Он это делает лучше чем многие разрабы которых я видел. Лично я в личных проектах больше никогда не буду писать подписи к коммитам сам.
Тратишь больше времени, чем можно — обоснуй что это необходимо. Я очень редко читаю свои комиты и мне очевидно, что я не должен больше их писать сам. Мне очевидно, что я сделал, но я должен потратить время и сформулировать это. Если машина с этим справляется достаточно хорошо, то отныне она должна делать, всегда.
Буквально до вчерашнего дня я всегда писал комиты сам. Я много лет работал в командах от мала до велика и содержательность комитов считалась чем-то важным. На одном из моих первых мест работы гит вообще возвели в культ, на ревью буквально требовали переименования комитов, сквошей, ревертов мержей на ребейзы и прочей ереси.
Мое мнение на эту тему такое — гит надо понимать, но лишь основные концепты - ветвление, ребейзинг, слияние. Не надо упарываться в идеальные commit messages, не надо дрочить на красивые графы. Вам даже не обязательно уметь работать с ним через терминал, вот что я думаю. Говорю как человек очень много времени работающий с гитом исключительно в консоли.
Так вот, commit messages. Бывают штуки вроде Conventional Commits и я очень долго им следовал, даже работая один. И вот только недавно до меня дошло — наименования коммитов это своего рода индекс, который позволяет быстрее понять, что в этом комите происходит, не заглядывая в него. Это то же самое, что нейминг сущностей в коде. Вот только код мы читаем постоянно, а как часто мы читаем историю git? Если это большой проект и вас туда комитит человек 5, окей, возможно, но если вас 2-3 или тем более вы один, ну камон. Я в своих пет проектах почти никогда не смотрю историю. Только если я что-то зафакапил, но я редко что-то факаплю, когда весь код принадлежит мне и я его хорошо понимаю и ощущаю.
Короче, советую не париться и генерировать коммиты через ИИ. Он это делает лучше чем многие разрабы которых я видел. Лично я в личных проектах больше никогда не буду писать подписи к коммитам сам.
Тратишь больше времени, чем можно — обоснуй что это необходимо. Я очень редко читаю свои комиты и мне очевидно, что я не должен больше их писать сам. Мне очевидно, что я сделал, но я должен потратить время и сформулировать это. Если машина с этим справляется достаточно хорошо, то отныне она должна делать, всегда.
Please open Telegram to view this post
VIEW IN TELEGRAM
Готовимся к собеседованию на позицию software engineer с ChatGPT
Создал кастомный GPT для подготовки к system design интервью. Под капотом промпт с идеальным список тем, которые надо понимать. Идеальный, значит не "все что есть на свете", а то что с максимальной вероятностью могут спросить на собеседовании.
Создал кастомный GPT для подготовки к system design интервью. Под капотом промпт с идеальным список тем, которые надо понимать. Идеальный, значит не "все что есть на свете", а то что с максимальной вероятностью могут спросить на собеседовании.
ChatGPT
ChatGPT - System Design Interview Preparator
ChatGPT helps you get answers, find inspiration, and be more productive.