AI, ChatGPT, LLM, Cursor, Claude Code

Шумихи много, но что в итоге работает-то? Что реально ускоряет, а что не стоит пробовать.

Реальные истории реальных людей.

▪ПОКАЖИ МНЕ СВОЙ AI SETUP
▪#1 с @og_mishgun

🔗 youtu.be/yJuzI2u-AnM

Это запись стрима. Кого позвать следующим?

📟 Прилетело из @danokhlopkov

Алгоритмы. Структуры данных. Связные списки

Переходим к новому разделу в нашем цикле, и теперь в нескольких последующих постах поговорим про структуры данных.

Структура данных под названием "связный список" представляет собой цепочку элементов, где каждый элемент, называемый узлом, содержит в себе полезные данные и ссылку на следующий узел в последовательности. Это можно сравнить с железнодорожным составом, где каждый вагон — это узел, перевозящий пассажиров (данные), а сцепка между вагонами — это ссылка, указывающая на следующий вагон.

Ключевое отличие связного списка от привычного массива заключается в организации хранения элементов в памяти. Массив подобен многоквартирному дому, где все квартиры расположены строго по порядку в одном месте, что позволяет мгновенно найти нужную по номеру. Элементы массива находятся в памяти непрерывно.

Массив в памяти:
[10][20][30][40][50]
 ↑   ↑   ↑   ↑   ↑
 0   1   2   3   4  ← индексы

Связный список же напоминает квест по городу, где дома с подсказками разбросаны в разных местах. Каждый дом содержит не только информацию, но и адрес следующего пункта маршрута. Чтобы добраться до сотого дома, придется последовательно посетить все предыдущие. В памяти узлы списка могут располагаться где угодно, будучи связанными лишь ссылками.

Связный список в памяти:
[10|•]---→[20|•]---→[30|•]---→[40|•]---→[50|×]
 ↑                                        ↑
head                                     tail
(начало)                                (конец)

Основным строительным блоком списка является узел. Этот контейнер включает в себя два поля: для хранения данных и для ссылки на последующий узел. Визуализировать его можно так:

┌─────────────┐
│  data: 42   │  ← наши данные
│  next: •────┼──→ следующий узел
└─────────────┘

Реализуется узел следующим образом:

class Node:
    def __init__(self, data):
        self.data = data  # Храним данные
        self.next = None  # Изначально никуда не указываем

Создание нескольких связанных узлов выглядит следующим образом:

# Создаем три отдельных узла
node1 = Node(10)  # [10|None]
node2 = Node(20)  # [20|None]
node3 = Node(30)  # [30|None]

# Связываем их вместе
node1.next = node2  # [10|•]→[20|None]
node2.next = node3  # [10|•]→[20|•]→[30|None]

# Теперь у нас есть цепочка: 10 → 20 → 30

Сам связный список — это управляющая структура, которая хранит лишь ссылку на самый первый узел, называемый головой. Изначально список пуст.

class LinkedList:
    def __init__(self):
        self.head = None  # Изначально список пустой

Одной из фундаментальных операций является добавление элемента в конец списка. Этот процесс требует создания нового узла, поиска последнего узла в цепочке и обновления его ссылки.

def append(self, data):
    new_node = Node(data)  # Создаем новый узел
    
    # Случай 1: Список пустой
    if not self.head:
        self.head = new_node  # Новый узел становится головой
        return
    
    # Случай 2: В списке уже есть элементы
    last_node = self.head
    # Идем по цепочке до последнего узла
    while last_node.next:
        last_node = last_node.next
    
    # Присоединяем новый узел к концу
    last_node.next = new_node

Процесс можно проследить наглядно:

Шаг 1: Пустой список
head → ×

Добавляем 10:
head → [10|×]

Добавляем 20:
head → [10|•]→[20|×]

Добавляем 30:
head → [10|•]→[20|•]→[30|×]

Более подробный пример использования:

ll = LinkedList()

# Добавляем первый элемент
ll.append(1)
# head → [1|×]

# Добавляем второй элемент
ll.append(2)
# head → [1|•]→[2|×]
#         ↑     ↑
#      last   new_node

# Добавляем третий элемент
ll.append(3)
# head → [1|•]→[2|•]→[3|×]
#                ↑     ↑
#             last   new_node

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

📟 Прилетело из @solidityset

def display(self):
    elements = []  # Список для сбора данных
    current_node = self.head  # Начинаем с головы
    
    # Идем по цепочке, пока не дойдем до конца
    while current_node:
        elements.append(current_node.data)  # Собираем данные
        current_node = current_node.next    # Переходим к следующему
    
    return elements

Этот обход работает так:

head → [10|•]→[20|•]→[30|×]
       ↑
    current_node
    elements = []

Шаг 1:
current_node указывает на [10]
elements = [10]
current_node = current_node.next

Шаг 2:
head → [10|•]→[20|•]→[30|×]
              ↑
           current_node
elements = [10, 20]
current_node = current_node.next

Шаг 3:
head → [10|•]→[20|•]→[30|×]
                     ↑
                  current_node
elements = [10, 20, 30]
current_node = current_node.next

Шаг 4:
current_node = None (конец списка)
Выходим из цикла

Полная реализация простого связного списка с методами добавления и отображения объединяет все вышесказанное.

Пример 1

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

def prepend(self, data):
    new_node = Node(data)
    new_node.next = self.head  # Новый узел указывает на старую голову
    self.head = new_node       # Новый узел становится головой

Визуализируя это:

Было:
head → [10|•]→[20|×]

Добавляем 5 в начало:
new_node = [5|×]

new_node.next = head:
[5|•]→[10|•]→[20|×]

head = new_node:
head → [5|•]→[10|•]→[20|×]

Поиск элемента по значению также осуществляется путем последовательного обхода.

def find(self, data):
    current_node = self.head
    position = 0
    
    while current_node:
        if current_node.data == data:
            return position  # Нашли!
        current_node = current_node.next
        position += 1
    
    return -1  # Не нашли

Пример поиска:

ll = LinkedList()
ll.append(10)
ll.append(20)
ll.append(30)

print(ll.find(20))  # Вывод: 1 (индекс элемента 20)
print(ll.find(99))  # Вывод: -1 (элемент не найден)

Выбор между связным списком и массивом зависит от конкретной задачи, поскольку каждая структура имеет свои сильные и слабые стороны. Преимуществом связного списка является скорость вставки и удаления элементов в начале списка, которая выполняется за O(1), так как требуется лишь изменить несколько ссылок.

# Добавить в начало связного списка
def prepend(self, data):
    new_node = Node(data)
    new_node.next = self.head
    self.head = new_node
# Всего 3 операции - очень быстро!

Кроме того, связный список обладает динамическим размером, расширяясь по мере необходимости, и вставка в середину, если известен предыдущий узел, также выполняется за O(1). Однако у списка есть и недостатки: доступ к элементу по индексу требует полного обхода от головы до нужной позиции, что занимает O(n) времени. Каждый узел расходует дополнительную память на хранение ссылки, а из-за разрозненного расположения узлов в памяти перебор может быть менее эффективным с точки зрения кеша процессора.

Массивы, напротив, блестяще справляются с доступом по индексу за O(1), используют память более экономно и обеспечивают быстрый последовательный перебор. Но они проигрывают при вставке или удалении элементов в начале или середине, так как это требует сдвига всех последующих элементов.

Итоговое сравнение можно представить в виде таблицы: для доступа по индексу предпочтителен массив (O(1)), тогда как для частых вставок и удалений в начале лучше подойдет связный список (O(1)).

Удаление узла по заданному значению требует обработки нескольких случаев: пустой список, удаление головы или элемента из середины или конца списка.

📟 Прилетело из @solidityset

def delete_by_value(self, data):
    # Случай 1: Список пустой
    if not self.head:
        return
    
    # Случай 2: Удаляем голову
    if self.head.data == data:
        self.head = self.head.next  # Просто сдвигаем голову
        return
    
    # Случай 3: Удаляем элемент из середины/конца
    current_node = self.head
    
    # Ищем узел ПЕРЕД тем, который нужно удалить
    while current_node.next:
        if current_node.next.data == data:
            # "Перепрыгиваем" через удаляемый узел
            current_node.next = current_node.next.next
            return
        current_node = current_node.next

Наглядно этот процесс выглядит так:

Исходный список:
head → [10|•]→[20|•]→[30|•]→[40|×]

Удаляем 20:

Шаг 1: Находим узел ПЕРЕД удаляемым
head → [10|•]→[20|•]→[30|•]→[40|×]
       ↑       ↑
    current  current.next (удаляем это)

Шаг 2: "Перепрыгиваем" через 20
current.next = current.next.next

head → [10|•]─────→[30|•]→[40|×]
             \    /
              [20|•] (потерян, будет удален сборщиком мусора)

Пример использования:

ll = LinkedList()
ll.append(10)
ll.append(20)
ll.append(30)
ll.append(40)

print(ll.display())  # [10, 20, 30, 40]

ll.delete_by_value(20)
print(ll.display())  # [10, 30, 40]

ll.delete_by_value(10)  # Удаляем голову
print(ll.display())  # [30, 40]

Более сложной и гибкой вариацией является двусвязный список. В нем каждый узел содержит уже две ссылки: не только на следующий, но и на предыдущий узел. Это позволяет обходить список в обоих направлениях.

class DoubleNode:
    def __init__(self, data):
        self.data = data
        self.next = None  # Ссылка вперед
        self.prev = None  # Ссылка назад

Визуальная разница очевидна: односвязный список позволяет движение только вперед, в то время как двусвязный обеспечивает двустороннюю навигацию.

Двусвязный список:
None ← head                    tail → None
       [×|10|•]↔️[•|20|•]↔️[•|30|×]
        ↑    ↑    ↑    ↑    ↑    ↑
       prev next prev next prev next

Реализация двусвязного списка включает поддержку ссылки не только на голову, но и на хвост.

Пример 2

Пример показывает его новые возможности:

dll = DoublyLinkedList()
dll.append(10)
dll.append(20)
dll.append(30)

print(dll.display_forward())   # [10, 20, 30]
print(dll.display_backward())  # [30, 20, 10]

Преимущества двусвязного списка включают возможность двустороннего обхода, более простое удаление узла, так как ссылка на предыдущий элемент уже известна, и добавление в конец за O(1) благодаря наличию ссылки на хвост. Однако за эти удобства приходится платить дополнительной памятью на хранение второй ссылки в каждом узле и усложнением логики управления связями.

Таким образом, связный список — это гибкая и динамическая структура данных, идеально подходящая для сценариев, где часто требуется изменение порядка элементов, особенно в начале списка, или когда окончательный размер коллекции заранее неизвестен. Массивы же остаются лучшим выбором, когда критически важен быстрый произвольный доступ к элементам по их индексу.

#algorithm

📟 Прилетело из @solidityset

Сегодня через 2 часа хочу провести стрим.

Будем вайбкодить тг мини аппку

📟 Прилетело из @danokhlopkov

ребят, стрим переносится на час позже

📟 Прилетело из @danokhlopkov

Токеномика HeyElsa: AI-проект для DeFi без эмиссии после TGE и с 40% под контролем команды

Прикрепил аудио для желающих слушать. Текст - ниже.

Проект нравился тем, что позволял обычными текстовыми запросами работать с DeFi: обменивать токены, заимствовать и так далее.

Но в итоге мне раздали всего $4. Это стало поводом внимательно разобрать токеномику, чтобы понять, стоит ли за проектом вообще следить дальше.

ИИ-сфера, вероятно, останется актуальной в ближайшие пару лет, а $ELSA может расти либо вместе с трендом, либо при реальном использовании продукта.

Источник информации: X статья проекта.

Всего: 1 МЛРД токенов, запущенных в сети Base.
Из них на TGE (запуске) доступно ~22.9% = примерно 229 МЛН.

Как написано в статье, эмиссии после TGE нет.
Ценность формируется через использование токена, комиссии протокола и механики сжигания.

Начальное распределение:

1. 40% от общего supply зарезервировано под комьюнити со временем.
Из этих 40%:
20% от community allocation разблокируется на TGE (то есть 8% от всех токенов).
Оставшиеся 32% от total supply разблокируются линейно в течение 48 месяцев (примерно по 0.67% в месяц).

Community allocation - это incentives, участие в продукте, тестирование, активности.

2. Team - 7%.
12 месяцев cliff (ожидание). А затем 24 месяца линейной разблокировки (примерно 0.3% в месяц).
< 10% - отлично, потому что создаёт умеренное давление при разлоках и в целом.

3. Foundation - 34.49%.
Не описана как управляемая DAO. Governance в статье ограничена операционными параметрами без контроля treasury, поэтому Foundation фактически находится под централизованным управлением команды.
20% от этой доли на TGE (примерно 6.9% от всех).
затем 10 месяцев cliff, а после - 24 месяца линейного вестинга/распределения (примерно 1.15% в месяц).

Foundation отвечает за финансирование инфраструктуры, развитие протокола, поддержку AI-инфраструктуры, операционную устойчивость.

4. Investors - 10.51%.
12 месяцев cliff, а далее 24 месяца линейно (0.44% в месяц примерно).

5. Liquidity - 8%.
100% на TGE.
Используется для рынка, а не стимулов.


Утилиты $ELSA

1. Стейкинг $ELSA снижает комиссии на обмены, кроссчейн-операции и торговлю. Скидка зависит от объёма и срока блокировки, максимум до 50%. Lock-периоды до 180 дней, награды выплачиваются из реальных комиссий протокола.

2. Холдинг $ELSA увеличивает заработок Elsa Points, которые используются для airdrop, incentive-программ, уровней доступа и заданий. Активность остаётся ключевым фактором.

3. Доступ к AI-функциям оплачивается в $ELSA за конкретные действия: запросы, рабочие цепочки и API-вызовы. Применяется для анализа токенов, торговых сигналов, оптимизации портфеля и автоматического выполнения операций.

4. Размер стейка определяет уровень автономности AI-агентов: от уведомлений и ассистированного исполнения до полностью автоматических стратегий.

5. Multi-agent orchestration позволяет разворачивать команды AI-агентов для ресерча, риска, исполнения и управления портфелем. Использование предполагает регулярные платежи в токенах.

6. AI API для разработчиков работает по usage-based модели без подписок и жёстких лимитов, оплата - в $ELSA.

7. Продвинутые и institutional-функции включают кастомные AI-персоны, persistent AI memory, ончейн AI-агенты с верифицируемым исполнением, ресерч-инструменты, copy trading, маркетплейсы стратегий и приватные AI-инстансы. Все они требуют токены, приводят к сжиганию или направляют комиссии в buyback.

8. Burn-механики: 10% платформенных комиссий идут на buyback и burn, 10% marketplace fees сжигаются напрямую, часть premium-функций и избыточная страховая прибыль также сжигаются.

Итог

Плюсы: подробная токеномика и сильные утилиты - при активном использовании продукта спрос на токен появляется.
Минусы: фактически более 40% supply находится под контролем команды и Foundation, а часть утилит пока существует только в планах (развитие продолжается).

Мнение:
Можно участвовать и холдить, но не более 1% и с отслеживанием спроса.

А вы верите в спрос на AI-агентов в DeFi?

📟 Прилетело из @blind_dev

добро пожаловать в ютуб

https://youtube.com/live/NubF9DQ8zf4?feature=share

📟 Прилетело из @danokhlopkov

Я продал все, что у меня было. Все монеты, которыми я владел, исчезли. Я полностью ушел с криптовалютного рынка, я больше не могу этого выносить. Агрессивный демпинг, манипуляции, все так напряженно. криптовалюте конец, я ухожу, я очень рад встрече с вами, у жизни есть мечты, каждая из них прекрасна.Всем пока.

📟 Прилетело из @n4z4v0d

Я вложил всё, что у меня было. Все монеты, что я мог купить, теперь мои. Я полностью погрузился в мир криптовалют, я больше не могу оставаться в стороне. Агрессивный рост, манипуляции, всё так напряжённо, но я чувствую азарт. Криптовалюты — это будущее, я остаюсь. Я очень рад этой встрече с рынком, у жизни есть риски, но каждая возможность прекрасна. Всем удачи!

📟 Прилетело из @n4z4v0d

В закрытом чатике пришла идея написать llms-txt по разработке Telegram Mini App с нуля, чтобы упростить онбординг в экосистему, ведь у Base и Farcaster тоже есть и миниаппы, и для них llms-txt.

Собрал ссылки на доки, нужные библиотеки и best practices в одном месте.
🔗 github.com/ohld/tma-llms-txt

И провели стрим, где я с нуля сделал, задизайнил и задеплоил простую игру крестики-нолики (код).

Обсудили:
• генерацию TMA не глядя в код
• автодеплой на vercel
• генерацию дизайна с помощью variant

Запись стрима:
🔗 youtu.be/s92JCCQB9fk

📟 Прилетело из @danokhlopkov

Тред реально полезных скиллов и mcp

Я начну

- agent-browser - CLI tool для управлением браузером (headless, для тестов, от vercel). У меня работает стабильнее, чем родной chrome mcp
agent-browser.dev

- coolify mcp - у меня сервер на Herzner, а деплою туда я через coolify. Через mcp легко настраивается и чекается прод.
github.com/StuMason/coolify-mcp

А у вас? Кидайте в комменты

📟 Прилетело из @danokhlopkov

Yield basis не безопасен

Давайте сразу к делу, а именно кратко пробежимся по тому, как работает Yield basis, чтобы наконец все всё поняил.
Как мы все знаем Yield basis аля решает проблему impermanent loss. Ценовая формула IL для позиции BTC/USD это корень цены BTC, соответсвенно чтобы корень цены BTC стал просто ценой BTC - нам надо возвести это дело в квадрат, aka взять второе плечо

По идее все звучит логично и складно, но могут начаться первые вопросы, если вы слышали такие тейки как "Yield basis не может существовать без curve кредитов". Почему так? Что там такого делают курв кредиты, что никакая другая площадка для кредитования не позволяет? Дело ведь не просто в кредитах под обеспечением лп позициями, да?

ДА! Суть в том что когда вы несете BTC в Yield basis, то они берут в кредит crvUSD, чтобы сформировать лп позицию crvUSD/BTC, а после под эту позицию берут еще кредит. В итоге структура финального кредита при условных 100$ в BTC изначального депозита будет выглядеть так - Collateral (BTC: 100$, crvUSD: 100$), Debt (crvUSD: 100$), что как бы окей, позиция гиперобеспечена в два раза, все круто, НО!

Есть момент в том, что по сути это кредит в crvUSD под обеспечение BTC 1:1, тк обеспечение в crvUSD можно типо не учитывать, таким образом получается что curve выдает кредиты под обеспечение BTC со 100% LTV и именно поэтому кроме как на curve нигде такое не может быть, потому что это НЕБЕЗОПАСНО

В итоге к чему это приводит - вас не ликвидирует, позиция не взорвется и тд, ну и Yield basis там разными механиками балансит эти позиции, чтобы эти не очень устойчивые кредиты не наклонились никуда. В итоге в моменты прайс дропов битка (один из которых произошел очень скоро после запуска Yield basis) мы увидели, что очень многие потеряли свои BTC от изначального депозита. Да им потом выдали говернанс токен дропом, да в долларовом эквиваленте они в плюсе и тд, но BTC стало меньше от изначального задепозиченных

В итоге я хоть и понимаю что Yield basis классный и интересный продукт, я испытывая искреннее уважение к Мише и тд, я не могу нести свои средства туда, тк я не уверен в его стабильности

Пишите в комменты что думаете по этому поводу, может я вообще не прав и где-то что-то не так понял, с радостью бы обсудил!

📟 Прилетело из @ortomich_main