Архитектура без AI — самый медленный путь к релизу.
AI без архитектуры — суета перед факапом.
// Сунь-Цзы
😁33❤9👍1👎1
Which JS/TS library would you choose for error handling?
Anonymous Poll
8%
Effect
4%
fp-ts: Either
11%
neverthrow: Result
22%
Own implementation
69%
Just throw/try/catch
11%
I’d like to, but I don’t
❤1
Slop Engineering Toolkit:
- Neuroslop types
- Security cosplay
- Vibe architecture
- Happy path tests
- Unreviewed AI code
- Dependency roulette
- AI-generated docs for AI
- Shipping without understanding
- Complexity hidden behind clean syntax
- Neuroslop types
- Security cosplay
- Vibe architecture
- Happy path tests
- Unreviewed AI code
- Dependency roulette
- AI-generated docs for AI
- Shipping without understanding
- Complexity hidden behind clean syntax
💯10🤣7🔥2❤1
Общие принципы того, как архитектура изменилась в связи с AI:
1. Управляющая система должна иметь достаточное разнообразие воздействий относительно управляемого поведения (закон Эшби). Если вы не способны различать, оценивать и корректировать существенные варианты ответов модели, управлять начинает уже она.
2. Пиши с AI то, что мог бы написать сам, но дольше. Иначе ты не можешь проверить результат и стать его владельцем. Потеря контроля начинается там, где нельзя оценить адекватность.
3. AI масштабирует ясность так же хорошо, как бред и туман. Неясная постановка почти всегда даёт неясный результат, много нейрослопа.
4. Каждая сгенерированная строка — тяжесть. Её нужно читать, чинить, объяснять людям и следующей модели. Соревноваться надо не в объеме генерации, а в результате при меньшем коде.
5. Сложность накапливается быстрее, чем способность ее осилить. Человек пишет код, который не поймёт через два месяца; модель — код, который не поправит через пять минут. Главный навык рядом с AI — уменьшение accidental complexity.
6. Документация стала исполняемым контекстом. AI читает markdown, ADR, RFC, issues, расшишифровки. То, что раньше жило в головах, теперь версионируемый артефакт.
7. Паттерны не исчезают. DI, IoC, SRP, идемпотентность, гранулярность, контракты, изоляция нужны, чтобы точно ставить задачу людям и модели.
8. Код должен оставаться понятным человеку. У модели выше предел контекста, но если система стала непонятной даже ей, человеку она уже давно недоступна.
9. Человек остаётся в контуре внимания. Вопрос в том, куда направить внимание: DSL, схемы, контракты, ревью, архитектурные документы.
10. Архитектурные знания нужны почти всем. Не обязательно быть архитектором по должности, но нужно понимать, что генерирует AI и можно ли это принимать в проект.
1. Управляющая система должна иметь достаточное разнообразие воздействий относительно управляемого поведения (закон Эшби). Если вы не способны различать, оценивать и корректировать существенные варианты ответов модели, управлять начинает уже она.
2. Пиши с AI то, что мог бы написать сам, но дольше. Иначе ты не можешь проверить результат и стать его владельцем. Потеря контроля начинается там, где нельзя оценить адекватность.
3. AI масштабирует ясность так же хорошо, как бред и туман. Неясная постановка почти всегда даёт неясный результат, много нейрослопа.
4. Каждая сгенерированная строка — тяжесть. Её нужно читать, чинить, объяснять людям и следующей модели. Соревноваться надо не в объеме генерации, а в результате при меньшем коде.
5. Сложность накапливается быстрее, чем способность ее осилить. Человек пишет код, который не поймёт через два месяца; модель — код, который не поправит через пять минут. Главный навык рядом с AI — уменьшение accidental complexity.
6. Документация стала исполняемым контекстом. AI читает markdown, ADR, RFC, issues, расшишифровки. То, что раньше жило в головах, теперь версионируемый артефакт.
7. Паттерны не исчезают. DI, IoC, SRP, идемпотентность, гранулярность, контракты, изоляция нужны, чтобы точно ставить задачу людям и модели.
8. Код должен оставаться понятным человеку. У модели выше предел контекста, но если система стала непонятной даже ей, человеку она уже давно недоступна.
9. Человек остаётся в контуре внимания. Вопрос в том, куда направить внимание: DSL, схемы, контракты, ревью, архитектурные документы.
10. Архитектурные знания нужны почти всем. Не обязательно быть архитектором по должности, но нужно понимать, что генерирует AI и можно ли это принимать в проект.
👍32❤17🔥3👎1
Добавляем пункты 0 и 11-14 в список
0. Управляй структурой и архитектурой приложения через спецификацию, а не через промпты. Архитектурные решения должны быть явными и проверяемыми артефактами в репозитории, а AI должен подтягивать их в нужные контексты, а не хранить в истории диалога.
11. Изоляция становится еще важнее, потому, что контекст — это тоже архитектурный ресурс. Чем больше модели нужно прочитать, чтобы сделать локальное изменение, тем хуже устроены архитектурные границы. Хорошая архитектура уменьшает необходимый контекст через изоляцию модулей и слоев.
12. Проверяемость! Нужно иметь возможность дешево проверять результат: линтерами, типами, тестами, схемами, контрактами. AI резко снижает стоимость добавления кода, но подымает стоимость владения кодом.
13. Обратимость! Чем дороже ошибка, тем больше нужно уделять внимания возможности отката. Миграция, изменение публичного API, характеристик кода, парадигмы, или архитектурного контракта должны быть под пристальным контролем.
14. AI должен быть ограничен с своих фантазиях: пространство допустимых решений, NFR, constraints, invariants, forbidden dependencies, acceptance criteria, вообще система запретов и красных линий.
0. Управляй структурой и архитектурой приложения через спецификацию, а не через промпты. Архитектурные решения должны быть явными и проверяемыми артефактами в репозитории, а AI должен подтягивать их в нужные контексты, а не хранить в истории диалога.
11. Изоляция становится еще важнее, потому, что контекст — это тоже архитектурный ресурс. Чем больше модели нужно прочитать, чтобы сделать локальное изменение, тем хуже устроены архитектурные границы. Хорошая архитектура уменьшает необходимый контекст через изоляцию модулей и слоев.
12. Проверяемость! Нужно иметь возможность дешево проверять результат: линтерами, типами, тестами, схемами, контрактами. AI резко снижает стоимость добавления кода, но подымает стоимость владения кодом.
13. Обратимость! Чем дороже ошибка, тем больше нужно уделять внимания возможности отката. Миграция, изменение публичного API, характеристик кода, парадигмы, или архитектурного контракта должны быть под пристальным контролем.
14. AI должен быть ограничен с своих фантазиях: пространство допустимых решений, NFR, constraints, invariants, forbidden dependencies, acceptance criteria, вообще система запретов и красных линий.
🔥17👍6💯2❤1
А что если никакого вайбкодинга не существует, весь нейрослоп, как и раньше, генерирует население Индии, а истерия - это просто ребрендинг?
😁45🤣12🤩5🤯3🔥2💯2
В JavaScript уже есть половина того, что нужно для реализации ownership-like, как в Rust, просто она разбросана по разным API:
- using / Symbol.dispose
- DisposableStack.move()
- ArrayBuffer.transfer()
- Proxy.revocable()
- AbortSignal, WeakRef
Поверх этого можно собрать runtime-прототип. Делаю. Без borrow checker и compile-time гарантий, но с вполне полезными affine semantics в рантайме. Ownership в JS появляется не как одна фича языка, а как композиция нескольких независимых механизмов.
- using / Symbol.dispose
- DisposableStack.move()
- ArrayBuffer.transfer()
- Proxy.revocable()
- AbortSignal, WeakRef
Поверх этого можно собрать runtime-прототип. Делаю. Без borrow checker и compile-time гарантий, но с вполне полезными affine semantics в рантайме. Ownership в JS появляется не как одна фича языка, а как композиция нескольких независимых механизмов.
🔥10👍5❤3😁1
Ownership and Resource Lifetime
Pure JavaScript examples of deterministic resource lifetime, ownership, move, borrow, lease, shared ownership, weak references, and RAII-inspired abstractions built on modern JavaScript.
Sources: https://github.com/HowProgrammingWorks/Ownership
Pure JavaScript examples of deterministic resource lifetime, ownership, move, borrow, lease, shared ownership, weak references, and RAII-inspired abstractions built on modern JavaScript.
const timers = require('node:timers/promises');
class AbortScope {
#controller = new AbortController();
signal = this.#controller.signal;
[Symbol.dispose]() {
this.#controller.abort(new Error('Scope disposed'));
}
}
const main = async () => {
let operation;
{
using scope = new AbortScope();
operation = timers.setTimeout(1000, 'done', {
signal: scope.signal,
});
}
try {
await operation;
} catch (error) {
console.log(error.name);
}
};
main();Sources: https://github.com/HowProgrammingWorks/Ownership
❤5🔥5👀2👍1