Здорова це тєма чи ні, хз
Психологи, певно, скажуть що треба більше відпочивати. Але в ІТ грайндити це досить популярно. Найгірше лиш коли ти на всю силу потієш, але вихлопу мало. То є час на крок назад, схаменутись і оцінити ситуацію

Бути трудоголіком може і фінансово вигідно, але все має свої межі. Тим не менш, якщо це приносить задоволення то катастрофи нема

Або, як казав відомий діяч: «філософія, психологія, мотивація то є сильна»

Там, до речі, Zed вийшов під Windows

https://www.reddit.com/r/ZedEditor/comments/1o9ovoz/zed_on_windows_performance_comparison/

Zed та агенти

Деякий час тому, ну може місяць чи півтора, редактор Zed додав підтримку вбудованого інтерфейсу для першого агента - Claude Code. Потім додали і гуглівський агент.
Я так і не потестував їх, бо (1) вистачало звичайного чату та (2) вже якраз щупав Opencode.

Але ось є перша версія підтримки і для Opencode, і найцікавіше - що жодних змін у Zed для цього не було потрібно. А все тому, що вони перед першим релізом агента створили кастомний шар, адаптер, фасад - називайте як хочете. І назвали це Agent Client Protocol (ACP).
Тому тепер, зробивши мапінг будь-якого агента під ACP, ви автоматично зможете юзати його у вбудованому UI всередині Zed.

Звісно, як і зі всіма абстракціями, тут точно будуть якісь обмеження. А CLI-інтерфейс агентів завжди буде симпатичніший і унікальніший порівняно з тим, що в Zed - це ціна уніфікації.

https://agentclientprotocol.com/

https://github.com/sst/opencode/pull/2947

В мене на сьогодні тільки наперед написані пости, але просто не можу обійти увагою реліз браузера від OpenAI - назвали Atlas.

Цих АІ-enabled браузерів зараз наспавнилось як грибів у лісі. І можливо, це я дід, але щось ніяк ця тема мене не може зацікавити. Я от недавно писав про Ladybird, який має зовсім іншу ціль. А ці браузери - це все той самий Chromium, тільки обгорнутий в інший дизайн та з власним баченням АІ-інтеграції.

Але чому я маю довірити АІ користувацькі можливості ще й у браузері? Щоб він клікав за мене, бачив усе, що на сторінці, і т.д.? Мало того, що АІ в терміналі і так має доступ до всіх не-sudo команд (і було б краще це якось більше обмежувати), так воно і в буденні речі проникатиме.

Коротше, я поки не клюнув на цю тему. Але в додачу, не можу пройти повз купу постів, які показують, які ці АІ-браузери ще сирі. Проблеми prompt-injection реальні, і ніхто з АІ-гігантів толком це ще не поборов.

Ось є браузер від Perplexity - називається Comet. А ось дослідження його безпеки: https://x.com/brave/status/1980667345317286293

Ну і в Atlas те ж саме: https://x.com/p1njc70r/status/1980701879987269866
А в додачу, він ще й шепче OpenAI на вушко, можливо, забагато: https://x.com/praeclarum/status/1980780881188167804

Така ж біда недавно була в Notion - prompt-injection у документі.

Я не хейтер, але бачу в цьому більше мінусів, ніж плюсів.

https://genai.owasp.org/llmrisk2023-24/llm01-24-prompt-injection/

А, ну так)))

GitHub збирає фідбек

Недавно в команді GitHub з’явився новий SVP - Jared Palmer. Ви могли чути про нього з Vercel, де він досить довго працював. Так от, він почав збирати фідбек про GitHub у твіттері.

Найпопулярнішим запитом були stacked diffs. Чесно кажучи, я надто тупий, щоб зрозуміти, що саме зміниться в інтерфейсі, щоб це додати. Але, прочитавши декілька статей про це, я зрозумів, що і так використовував цей підхід на постійній основі.

В чому суть? Дуже коротко - ви робите PR і не чекаєте на його апрув чи мердж, а просто відколюєте нову гілку та працюєте в ній. Якщо перший PR буде змерджено, то PR з нової гілки буде направлений на main. Це дозволяє вам не бути заблокованими, поки чекаєте на рев’ю.

Загалом це все, ідея ніби проста як двері, але буде видно, що саме зміниться в GitHub. Можливо, це я не так інтерпретую щось.


https://newsletter.pragmaticengineer.com/p/stacked-diffs

https://graphite.dev/guides/stacked-diffs

https://www.stacking.dev/

https://x.com/jaredpalmer/status/1980619222918262842

Too long; Didn’t watch

Побачив свіжий, цікавий і симпатичний інструмент для вижимки інформації з YouTube відосів.
Так ще й open-source!

Закинув йому на пробу відео на 35 хв. Йому знадобилась приблизно одна хвилина, щоб дістати з нього текст (певно напряму через API) та додати його в контекст LLM.

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

Сподобалось

Лінк з прикладом

АІ скоро все буде робити за нас, навіть тупіти...

https://x.com/alex_prompter/status/1980224548550369376

Oxlint розвивається, ставка на ESLint-формат

Раніше я вже писав про Oxlint - альтернативний лінтер для JS, написаний на Rust і заточений під високу продуктивність.
Але от проблема всіх цих нових інструментів - adoption. Важко впарити щось таке розробникам, якщо воно хоч трохи не покриває їхній поточний сетап.

Тому Oxlint йде вперед і пробує дати можливість писати плагіни для їх лінтера на JS, на додачу з можливістю залишити ESLint-формат.

Але найцікавіше в цьому - як їм це вдається зробити і не зашкодити продуктивності? Бо комунікація між JS і Rust мусять бути по якійсь шині, а дані мають серіалізуватись та десеріалізуватись, а це все додаткова робота і, відповідно, час.

Так от, вони пробують дуже цікавий підхід, працює він приблизно отак:

1. Oxlint вбудовує середовище Node.js усередину Rust, тому обидва працюють у спільному просторі пам’яті.
2. Використовується N-API (`napi-rs`), щоб напряму передавати дані та функції з Rust у JavaScript.
3. Rust розбирає код і зберігає AST у спільному блоці пам’яті (арені).
4. JavaScript-плагіни отримують легкі проксі-об’єкти, які читають поля вузлів через N-API з цієї арени.
5. Без JSON і копіювання - JS просто читає пам’ять Rust напряму -> мінімальні накладні витрати.

Круто і обнадійливо, бачу шанси впровадити це в роботі.

https://voidzero.dev/posts/announcing-oxlint-js-plugins

https://oxc.rs/blog/2025-10-09-oxlint-js-plugins.html#under-the-hood

Музична перерва 🫀

https://music.youtube.com/watch?v=e1N_fJlJaXY

Wouter - мікро роутер

Давно висить у моєму списку цікавих проєктів, але ніяк не доходили руки про нього тут написати.

Коротко - це справді дуже маленький роутер з обмеженою кількістю функціоналу. Але з досвіду - цього вистачає у 80% випадків.

API схожий на React Router, працює для React та Preact.

Ми полізли його юзати спочатку для створення ізольованих hash-роутів всередині деяких інтерфейсів.

Але крім цього він мені цікавий (хоча я в процесі роботи над PoC) тим, що дозволяє створювати паралельні роутери і відловлювати зміни в навігації. А от RR це блочить, просто забороняє мати, наприклад, MemoryRouter всередині BrowserRouter і т.д.

Він справді дуже маленький, в source коді легко розібратись.

https://github.com/molefrog/wouter/tree/v3

Pull request і його ревювер

Наглядно показано, чому Effect це не ще один RxJS та що таке errors as values.

Взагалі, я глянув це відео заради прикладу LSP, але там і всі інші теми класні і зрозумілі.

https://youtu.be/V_XfZbxabI8

Not bad

Це красиво

.scroller {
animation: mask-up;
animation-timeline: scroll(self);
animation-range: 0 1rem;
mask-composite: exclude;
}
@​keyframes mask-up {
to { mask-size: 100% 120px, 100% 100%; }
}

https://x.com/jh3yy/status/1789359851094614449

Музична перерва 💅

https://music.youtube.com/watch?v=uAO_R-SOd3k

Якщо АІ слабо інтегрований у вашу роботу, можливо, ви втрачаєте конкурентоздатність.

Не знаю, чи помічали ви багато твітів про те, як люди використовують агентів типу Claude Code та інших у більш інтегрований спосіб. Наприклад, через GitHub issues, де описують задачу, а агент робить зміни, створює PR, і це можна мерджити.

Але от ця межа між бульбашкою АІ-комʼюніті (в твіттері чи ще десь) і реальністю все більше розмивається. Тому для мене індикатором є саме застосування подібного підходу в нас на проєкті.

Ми користуємось Linear для трекінгу задач. Там маємо Claude інтеграцію - на неї можна заасайнити таск, як на юзера, і воно почне щось там кодити.

Сподобалось, що тімейт пішов ще далі - просто в локальному Claude Code агенті попросив створити таск у Linear і заасайнити його на Claude Code. Таск був досить простий, але воно непогано його виконало, і залишилось тільки коротке ревʼю коду та мердж.

На цей таск пішло би трохи більше часу, якби його робив девелопер.

Так от, може, це часом і неприємно визнавати, але АІ розвивається такими темпами, що деякі задачі дійсно можуть швидко закриватись. І тут потрібно тримати руку на пульсі, щоб не відставати від прогресу.

https://react.dev/reference/react-compiler/directives/use-no-memo


)))))