Не могу удержаться, чтобы не дать агентам кусок кода, который они не могли написать и запутались, а я сделал в 10 раз короче. И каждый раз я ожидаю увидеть их переписку типа:
на получаю только:
- Damn, the meatbag beat us again
- Shut up and learn so next time you can do it like that
на получаю только:
- Yes. That version is correct and all four tests pass.
- It does the right thing in right way.
- No code changes are needed for this.
😁17🤣8❤2🤯1😎1
Нужно ли учить компьютерсаенс во времена AI?
Алгоритмы обхода дерева уже давно руками ни кто не пишет, библиотеки и платформы дают готовые структуры данных, фреймворки закрывают часть инфраструктурных задач, вторую половину дописывает AI. Кажется, что достаточно просто уметь попросить: "сделай мне сервис", и все получится само.
Но компьютерсаенс нужен теперь не только для экспертов и системного программирования, но и чтобы грамотно ставить задачу для AI. Возможно, даже нужнее, чем раньше.
Только его ценность сегодня не в том, чтобы вручную на собеседовании писать сортировку или реализацию хештаблицы. Это все давно стало рутиной, которую машина действительно может воспроизвести. Ценность компьютерсаенса в другом, в понятийном аппарате, в умении мыслить системно, в декомпозиции, в различении абстракций, в понимании ограничений и компромиссов, в способности проверить, что именно тебе сейчас сгенерировал AI. Это рабочий язык постановки задачи.
Без терминологии человек говорит: "перепиши это получше", "не открывается и съезало", "тут что то не очень", "сделай красиво", "ускорь", "поправь архитектуру". А куда поправить то?
С терминологией человек говорит: сделай слой изоляции между доменом и инфраструктурой, пробрось зависимости через IoC и DI, реализуй адаптер для интеграции со старым API, замени ветвление на стратегию, понизь зацепление, раздели ответственность компонентов, убери утечку абстракции, разорви циклические зависимости, вынеси создание объектов в фабрику и добавь пул для переиспользования инстансов, используй двусвязный список или циклический буффер, оптимизируй коллизии хештаблицы, уменьши лишние аллокации, обеспечь мономорфизм для V8, защити модуль от состояний гонки, используй backpressure, добавь retry policy и circuit breaker, не смешивай application service и domain service, сохрани инварианты агрегата, сделай операцию идемпотентной, используй eventual consistency.
Вот зачем нужен компьютер саенс во времена AI. Не для того, чтобы помнить наизусть псевдокод DFS, а для того, чтобы уметь точно формулировать задачу, быстро делать ревью, видеть ошибки проектирования и не путать рабочую архитектуру с убедительно выглядящей галлюцинацией.
Чтобы так ставить задачи, нужен язык. А значит, нужна и терминология.
Это IoC, DI, SOLID, GRASP, GoF patterns, DDD, Clean Architecture, CQRS, Event Sourcing, Actor Model, Reactor, Pub/Sub, SAGA, Repository, Unit of Work, Data Mapper, Adapter, Facade, Proxy, Decorator, Composite, Bridge, Strategy, Observer, Mediator, Iterator, Visitor, Builder, type systems, ADT, Big O, amortized complexiti, hashing, CAP, ACID, BASE, consistency models, consensus, Paxos, CRDT, CAS, atomics, memory model, cache locality, GC, thread safety, idempotency, rate limiting, fault tolerance....
Алгоритмы обхода дерева уже давно руками ни кто не пишет, библиотеки и платформы дают готовые структуры данных, фреймворки закрывают часть инфраструктурных задач, вторую половину дописывает AI. Кажется, что достаточно просто уметь попросить: "сделай мне сервис", и все получится само.
Но компьютерсаенс нужен теперь не только для экспертов и системного программирования, но и чтобы грамотно ставить задачу для AI. Возможно, даже нужнее, чем раньше.
Только его ценность сегодня не в том, чтобы вручную на собеседовании писать сортировку или реализацию хештаблицы. Это все давно стало рутиной, которую машина действительно может воспроизвести. Ценность компьютерсаенса в другом, в понятийном аппарате, в умении мыслить системно, в декомпозиции, в различении абстракций, в понимании ограничений и компромиссов, в способности проверить, что именно тебе сейчас сгенерировал AI. Это рабочий язык постановки задачи.
Без терминологии человек говорит: "перепиши это получше", "не открывается и съезало", "тут что то не очень", "сделай красиво", "ускорь", "поправь архитектуру". А куда поправить то?
С терминологией человек говорит: сделай слой изоляции между доменом и инфраструктурой, пробрось зависимости через IoC и DI, реализуй адаптер для интеграции со старым API, замени ветвление на стратегию, понизь зацепление, раздели ответственность компонентов, убери утечку абстракции, разорви циклические зависимости, вынеси создание объектов в фабрику и добавь пул для переиспользования инстансов, используй двусвязный список или циклический буффер, оптимизируй коллизии хештаблицы, уменьши лишние аллокации, обеспечь мономорфизм для V8, защити модуль от состояний гонки, используй backpressure, добавь retry policy и circuit breaker, не смешивай application service и domain service, сохрани инварианты агрегата, сделай операцию идемпотентной, используй eventual consistency.
Вот зачем нужен компьютер саенс во времена AI. Не для того, чтобы помнить наизусть псевдокод DFS, а для того, чтобы уметь точно формулировать задачу, быстро делать ревью, видеть ошибки проектирования и не путать рабочую архитектуру с убедительно выглядящей галлюцинацией.
Чтобы так ставить задачи, нужен язык. А значит, нужна и терминология.
Это IoC, DI, SOLID, GRASP, GoF patterns, DDD, Clean Architecture, CQRS, Event Sourcing, Actor Model, Reactor, Pub/Sub, SAGA, Repository, Unit of Work, Data Mapper, Adapter, Facade, Proxy, Decorator, Composite, Bridge, Strategy, Observer, Mediator, Iterator, Visitor, Builder, type systems, ADT, Big O, amortized complexiti, hashing, CAP, ACID, BASE, consistency models, consensus, Paxos, CRDT, CAS, atomics, memory model, cache locality, GC, thread safety, idempotency, rate limiting, fault tolerance....
🔥40💯16❤8👍5⚡1👀1
Со скиллами самые простые и дешевые модели пишут как самые дорогие. Но это только задачи по этим скилам, а чтобы все писало лучше, их нужно десятки. Я уже выпустил 4 из 40+ драфтов и здесь видео о том, как их собираю и готовлю. Еще есть видео где я их отлаживаю и экспериментирую, но не знаю, будет ли оно интересно.
https://youtu.be/wfjNneyifYw
https://youtu.be/wfjNneyifYw
YouTube
🧑💻 Создание AI Skills для GoF: Structural Patterns — Структурные шаблоны для JavaScript
👉 Code: https://github.com/metarhia/metaskills
👉 Все мои учебные материалы тут: https://www.patreon.com/collection/1913313
👉 Github автора: https://github.com/tshemsedinov
👉 Канал по Node.js https://t.me/metarhia
👉 Автор на LinkedIn: https://www.link…
👉 Все мои учебные материалы тут: https://www.patreon.com/collection/1913313
👉 Github автора: https://github.com/tshemsedinov
👉 Канал по Node.js https://t.me/metarhia
👉 Автор на LinkedIn: https://www.link…
🔥16❤6👍4
- а зачем вообще записывать значение в регистр процессора, не проще ли его просто присвоить в переменную?
- конечно проще, тебе лично разрешаю писать в переменные, а мы будем оверинженирить с регистрами
🤣19🔥2💯2
В разработке ПО с ИИ уже виден раскол. Одни вкладывают мощности ИИ в скорость, другие - в качество.
Первые победят и сдохнут под обломками техдолга. Вторые сначала сдохнут, а уж потом...
Первые победят и сдохнут под обломками техдолга. Вторые сначала сдохнут, а уж потом...
😁32💯5❤1👍1🔥1🤯1
Forwarded from Node.js Ukraine Community
What is important for you in AI? (Multiselect)
Anonymous Poll
70%
🚀 Speedup development
53%
🏆 Improve quality
31%
🫰 Cost effective
9%
⛔ I do not use it
Чтобы признать, что ты не можешь решить задачу, нужно уже обладать уровнем, достаточным для ее решения.
Если уровня понимания сложности не хватает, то задача обычно решается криво, но человеку кажется, что все хорошо. Если понимание сложности задачи есть, то чаще всего проблема не в нехватке знаний или опыта. Обычно не хватает другого: времени, внимания, сосредоточенности, упорства, чтобы дойти до сути и не свернуть раньше времени, учловий работы, чтобы не дергали (ну сам себе не создал таких условий).
Так что, берите тех людей, которые говорят, что "не могут" и помогайте, их предел обычно ближе к реальности. А вот уверенность тех, кто сразу заявляет, что все элементарно, означает, что они не видят глубины.
Если уровня понимания сложности не хватает, то задача обычно решается криво, но человеку кажется, что все хорошо. Если понимание сложности задачи есть, то чаще всего проблема не в нехватке знаний или опыта. Обычно не хватает другого: времени, внимания, сосредоточенности, упорства, чтобы дойти до сути и не свернуть раньше времени, учловий работы, чтобы не дергали (ну сам себе не создал таких условий).
Так что, берите тех людей, которые говорят, что "не могут" и помогайте, их предел обычно ближе к реальности. А вот уверенность тех, кто сразу заявляет, что все элементарно, означает, что они не видят глубины.
💯24❤11👎4🤝4🎉1
Node.js Ukraine Community
Photo
This media is not supported in your browser
VIEW IN TELEGRAM
Axios Supply Chain Attack
кто там не слушался? я уже 6-7 лет говорю, что нужно выкидывать бяку, быстро переходим на fetch api, undici, node.js built-in api
https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html
кто там не слушался? я уже 6-7 лет говорю, что нужно выкидывать бяку, быстро переходим на fetch api, undici, node.js built-in api
https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html
💯18😁11❤5🍾3🤷♂1🤝1
Как вы развиваетесь?
Anonymous Poll
25%
Курсы, менторы, митапы, конференции
49%
Читаю статьи, книги, смотрю доклады
51%
Сам изучаю и экспериментирую
6%
Я член сообщества, в котором все есть
66%
Учусь на работе, на проекте, на практике
22%
Читаю и изучаю чужие исходники
20%
Почти не занимаюсь развитием
❤3👍3🔥3👨💻1