Comments 46
В общем, елси говорить про код, то я в полной мере не знаю как работает тот или метод, т.к. полностью доверял ИИшке пистаь код. Но все общая логика всегда в моем контексте
Я уже писал что код написанный нейронкой уже не твой. Какзалось бы ну согласился на микроменджмент с ИИ-джуном аутистом, и ладно.. но когда он переписывает существенную часть кода из-за требований которые ему никто не ставил щедро сдабривая их галлюцинациями, то это начинает пугать. Контроля над кодом и приемственности как таковой нет, он превращается в одноразовый продукт.
Верно, но пользователя программы это вообще никак не волнует. Он хочет играть в точки. Цель выполнена? Да. Прога работает? Работает. И да, это только начало, лет через 4-5 такие "прожки" будут программироваться на раз-два.
Не факт. Судя по скорости роста окна контекста могут все еще не укладываться. Но вот это все нормальный программист за пару дней напишет сам, если не быстрее, потому что на все тривиальное уже почти есть библиотека в ноде/пиионе. Для сравнения возьмите хоть nicegui против реакта с бэкэндом на питоне. Скорость разработки простых софтин процентов на 50-100 выросла. И дальше их тоже будет только больше, а ИИ по сути нужно на каждый новый фреймворк переобучать иначе только бесконечно бужет перечитывать доки и не факт что не налажает если весь док в контекст не влезает.
Эти проблемы рано или поздно решат. Дообучение на новые фреймворки проблем точно не вызовет. Просто наступит момент когда будет создан фреймворк именно для ИИ, и программисту не нужно будет его изучать. Будет справка, что умеет фреймворк и как им пользоваться )) В любом случае, как раньше уже не будет 100%. Привыкайте к новой реальности.
Вопрос в оптимизациях. У нас программы от мясных разработчиков тормозят, а что будет на нейрослопе?
Задача не была сделать своим кодом, код написанный ИИшкой. Задача была, а вообще можно ли сделать что-то рабочее, не зная ЯП, а зная только алгоритм как должно быть. И вроде как оно очень даже может быть. Я думаю чрезе год-два ИИшки научаться более детально дердать контекст по коду. А сейчас, как описал, это прям боль, потому что ИИшка начинает переписывать то, что совсем может не касаться конкретного вопроса и потому его надо все "кормить" актуальным кодом
Задача была, а вообще можно ли сделать что-то рабочее, не зная ЯП, а зная только алгоритм как должно быть.
Можно, а зачем? Я сделал так так приложение на для проверки баланса на Котлин. Но поддерживать это тяжелее чем написать самому
Кстати, пытал его писать понятный код. Да я не вчитывался, но вырвать кусок из кода и разобраться, вроде можно. Вот кусок метода...
_removeEnemyDots(inside) {
const enemy = this.lastPlayer === "blue" ? "red" : "blue";
const newDots = [];
let removed = 0;
for (const dot of this.dots) {
const idx = dot.y * this.width + dot.x;
const owner = this.dotOwner.get(this._key(dot));
if (owner === enemy && inside[idx] === 1) {
this.removedDots.push({
x: dot.x,
y: dot.y,
color: owner // red или blue
});
this.connections.delete(this._key(dot));
this.dotOwner.delete(this._key(dot));
removed++;
continue;
}
newDots.push(dot);
}И понятное название метода, и нормальные переменные
Его можно попросить отдельно комментировать чуть ли не каждую строку кода (мой выбор - поблочно). То есть что тут цикл или ветвление и ежу понятно, а чего он крутит - лучше пусть пишет комментарий. Это ненамного больше займет токенов а понятности коду добавит нехило.
А тут вообще ничего не подписано, надо вчитываться в имена методов, конечно сложно.
Ерунда какая то. Начинает проигрывать - просто обнуляет доску и начинает сначала.
как и говорил выше это вообще МВПха, багов явно много будет, а так хотелось бы более развернутое описание бага. В статье не сказал, но в игре есть ограничения. На кол-во комнат одновременно, на игру -15 минут, на ожидание подключения после выхода одного из игроков (ждет 30сек и обновляет комнату, но победитель получает 10 очков свои). И сейчас сразу видно еще пару багов, которые записаны в блокнотике и ждут своего свободного времени на исправление.
Кстати комнаты ждут своих игроков явно из-за неосведомленности игроков что надо делать, мало игроков, входят\выходят из комнат, комнаты пустые - игра не может состояться.
И ботов нет
О, а это идея, для начинающих может быть будет полезно, но это прям затратно по ресурсам будет. А то чем он будет думать? Сейчас это все крутиться на самой маленькой VPS)))
Бот может пользоваться ресурсами клиента.
обратка логики на сервере же. Или как это сделать? Дайте идею
Логика игры на сервере, а логика бота в браузере. С точки зрения сервера это два игрока на одном клиенте делают ходы по очереди. С точки зрения пользователя один ход делает он а второй за оппонента скрипт в браузере.
Идея. Но не повешает ли это браузер по памяти?
От алгоритма зависит. Тут ничего сказать не могу, но перебор монтекарло который до нейронок был штатным в го вообще память не использует. Правда для него нужно на клиенте правила держать минимальные. Думаю можно останавливать, если любая группа была захвачена.
Спасибо, записал себе на листочек ожидания дорабток
Потому что боты - это не просто более менее стандартный сайт. Для них самих нужно нейросеть обучать (ну если конечно есть цель сделать бота, с которым было бы интересно играть). Вряд ли с этим хоть как-то сейчас LLM справится.
А хороший ИИ ИМХО спросил бы не хотите ли Вы пропатчить/переиспользовать готовые библотеки доступные тут https://www.npmjs.com/search?q=keywords%3Abaduk&page=1&perPage=20
Что-то не могу понять - а чем эта игра от Го отличается?)
Вы совершенно правы, сходесть с ГО огромна, но она проще. Немного упрощенная механика, просто окружай точки и захватывай их. А в ГО сам захват точек и правла расположения точек немного сложнее
Например тем что в Го можно играть под взятыми камнями. Разные игры совсем.
Цель: в классических Точках - окружить как можно больше точек соперника, в Го - замкнуть как можно большую территорию (но захваченные камни идут в бонус).
В Точках можно создавать окружения с пустыми позициями внутри, в Го - нет.
В Точках позиции внутри окружения остаются окруженными навсегда, в Го - захваченные камни исчезают и их позиции снова становятся валидными для следующих ходов. Это вносит новую концепцию в игру - Ко. Суть в том, что нельзя, чтобы следующий ход в точности повторял предыдущую позицию на доске (иначе это может приводить к зацикливанию).
В Точках нельзя спасовать, т.к. это бессмысленно, в Го спасовать можно и иногда нужно, чтобы закончить игру. Зато в Точках можно заземлиться, чтобы тоже закончить игру, когда дальнешее продолжение не имеет смысла.
В Точках стандартное поле считается 39*32, в Го - 19*19.
В Го нельзя играть на уроке природоведения, а в точки/феодала можно.
А зачем было копировать код из ЧатаГПТ, почему не поручить дело агентской IDE. Она и тесты бы сделала и прочее. Кроме того, Opus 4.5 или даже Gemini 3 с такой задачей легко справляется. Ставьте Антигравити со студенческой подпиской пока это "бесплатно".
Забавно. Попросил сделать наивную реализацию и смоделировать проблемы проектирования и отладки.
Простите, не могу свернуть длиннопост под кат.
Реальный процесс (без постзнания)
Шаг 1: Начинаю наивно
// "Просто массив, чего мудрить"
let board = [];
for (let y = 0; y < 15; y++) {
board[y] = [];
for (let x = 0; x < 15; x++) {
board[y][x] = null;
}
}
let currentPlayer = 'red';
let score = { red: 0, blue: 0 };
function makeMove(x, y) {
if (board[y][x] !== null) return false;
board[y][x] = currentPlayer;
checkCaptures();
currentPlayer = currentPlayer === 'red' ? 'blue' : 'red';
draw();
return true;
}
Шаг 2: Пишу flood fill
function checkCaptures() {
// Идея: найти что окружено
const visited = {};
const queue = [];
// Начинаем с границ
for (let i = 0; i < 15; i++) {
queue.push([0, i], [14, i], [i, 0], [i, 14]);
}
while (queue.length > 0) {
const [x, y] = queue.shift();
const key = x + ',' + y;
if (visited[key]) continue;
if (x < 0 || x >= 15 || y < 0 || y >= 15) continue;
if (board[y][x] === currentPlayer) continue; // стена
visited[key] = true;
queue.push([x+1, y], [x-1, y], [x, y+1], [x, y-1]);
}
// Всё что не visited и принадлежит противнику — захвачено
for (let y = 0; y < 15; y++) {
for (let x = 0; x < 15; x++) {
const key = x + ',' + y;
if (!visited[key] && board[y][x] === opponent(currentPlayer)) {
board[y][x] = 'captured_' + board[y][x];
score[currentPlayer]++;
}
}
}
}
Шаг 3: Первые баги
// Баг 1: opponent не определён
function opponent(player) {
return player === 'red' ? 'blue' : 'red'; // забыл написать
}
// Баг 2: проверяю captured_red как строку
if (board[y][x] === 'red') // не матчит 'captured_red'
// Баг 3: после захвата точка мешает своим же окружениям
board[y][x] = 'captured_' + board[y][x];
// теперь это не 'red' и не 'blue', логика ломается
// Баг 4: мутирую board во время итерации по нему
for (...) {
if (!visited[key] && board[y][x] === ...) {
board[y][x] = ...; // влияет на следующие итерации?
}
}
Шаг 4: Начинаю костылить
// "Ладно, сделаю типы клеток"
// board[y][x] = { type: 'dot', player: 'red' }
// board[y][x] = { type: 'captured', player: 'red', capturedBy: 'blue' }
// board[y][x] = null
// Теперь везде проверки:
if (board[y][x] && board[y][x].type === 'dot' && board[y][x].player === 'red')
// Забыл проверить null:
if (board[y][x].type === 'dot') // TypeError: Cannot read property 'type' of null
Где я бы застрял
Час 1: Базовая структура, отрисовка — ОК
Час 2: Flood fill — вроде работает
Час 3: Тестирую сложные случаи — баги
"Почему эта точка не захватилась?"
console.log(board)
console.log(visited)
Смотрю на стену объектов...
"А, я мутировал board и теперь
captured_red не считается стеной..."
Час 4: Фикшу, ломаю другое
"Теперь двойное окружение не работает"
Конкретные проблемы без типов/иммутабельности
Проблема 1: Строки вместо enum
// Опечатка — молчаливый баг
currentPlayer = 'Red'; // было 'red'
// Забыл case
if (cell === 'red') { ... }
else if (cell === 'blue') { ... }
// а captured_red? а null?
Проблема 2: Мутация ломает инварианты
function checkCaptures() {
// ... нашёл captured позиции ...
for (const pos of captured) {
board[pos.y][pos.x] = { type: 'captured', ... };
// ОЙ: это влияет на следующий вызов flood fill
// если я проверяю несколько контуров
}
}
Проблема 3: Неявные зависимости
function checkCaptures() {
// Читаю currentPlayer — глобальный
// Мутирую board — глобальный
// Мутирую score — глобальный
// Кто вызвал? С каким состоянием?
// Можно вызвать дважды? Идемпотентно?
}
Проблема 4: Отладка состояния
// Что-то сломалось. Какой был board до этого вызова?
// Не знаю, я его перезаписал
// В иммутабельном мире:
const board2 = makeMove(board1, pos);
const board3 = applyCaptures(board2, captures);
// Все промежуточные состояния доступны
Что бы помогло (осознаю по ходу)
// После часа багов я бы сам пришёл к:
// 1. Константы вместо строк
const PLAYER = { RED: 'red', BLUE: 'blue' };
const CELL = { EMPTY: 'empty', DOT: 'dot', CAPTURED: 'captured' };
// 2. Чистые функции для логики
function findCaptured(board, player) {
// Не мутирует board, только возвращает список
return capturedPositions;
}
// 3. Отдельный шаг применения
function applyCaptures(board, positions) {
const newBoard = JSON.parse(JSON.stringify(board)); // копия
for (const pos of positions) {
newBoard[pos.y][pos.x] = ...;
}
return newBoard;
}
// То есть... я бы переизобрёл иммутабельность
Таблица: когда что помогает
Этап разработки │ Мутабельный JS │ Иммутабельный/Типизированный
─────────────────────────┼────────────────┼─────────────────────────────
Первые 30 минут │ ✅ Быстрее │ ❌ Больше кода
Простые случаи работают │ ✅ Ок │ ✅ Ок
Сложный баг в алгоритме │ ❌ Ад │ ✅ Легче изолировать
"Почему захват сломался" │ ❌ console.log │ ✅ Чистая функция — тестирую
Добавить undo │ ❌ Переписывать │ ✅ Уже готово (история)
Рефакторинг │ ❌ Страшно │ ✅ Типы ловят
Вывод (честный)
Первый час: Мутабельный JS быстрее
Второй час: Примерно одинаково
Третий час: Иммутабельность начинает окупаться
Четвёртый+: Без типов/иммутабельности — боль
Для MVP "лишь бы работало":
JS мутабельный — ок, потом выкинешь
Для "работает надёжно":
Типы + иммутабельность экономят время на отладке
Ключевой инсайт: я бы сам пришёл к иммутабельности через боль. Вопрос — тратить час на баги или сразу писать чисто.
Для игры "Точки" конкретно — алгоритм окружений достаточно сложный, чтобы иммутабельность окупилась.
Если говорить про время за которое всё было сделано, то ориентировончо это заняло примерно недели 1,5-2 если говорим про 3-4 часа в день
Опытный программист сделал бы за 8 часов, простите.
Не, ну тут-то думать надо, баги обрабатывать. А так всё сливаешь ИИшке, описываешь баги, пусть сам думает, что и как писать =)
I’m the operator with my pocket calculator
Я оператор со своим карманным калькулятором
I’m the operator with my pocket calculator
Я оператор со своим карманным калькулятором
I am adding and subtracting
Я складываю и вычитаю
I’m controlling and composing
Я контролирую ситуацию и сочиняю музыку
I’m the operator with my pocket calculator
Я оператор со своим карманным калькулятором
I’m the operator with my pocket calculator
Я оператор со своим карманным калькулятором
I am adding and subtracting
Я складываю и вычитаю
I’m controlling and composing
Я контролирую ситуацию и сочиняю музыку
By pressing down a special key, it plays a little melody
При нажатии на специальную клавишу воспроизводится небольшая мелодия
By pressing down a special key, it plays a little melody
При нажатии на специальную клавишу воспроизводится небольшая мелодия
I’m the operator with my pocket calculator
Я оператор со своим карманным калькулятором
I’m the operator with my pocket calculator
Я оператор со своим карманным калькулятором
Кто то в 2026 всё ещё сомневается что ии может сделать онлайн тетрис?
Цель игры - захватит как можно бОльшую территорию.
Именно такая? Обычно в русских Точках нужно захватить как можно больше точек соперника, а территория никак не учитывается. И что является территорией в вашем случае: площадь или количество позиций внутри окружения? Последнее кажется более правильным. Как при этом учитываются точки внутри окружений, это +1 очко как в Го?
Сложность была в том, что надо было выявлять замкнутые фигуры, обход по древу и другие логические "издержки".
На самом деле этот алгоритм не особо сложный, дерево не обязательно использовать. Можно использовать алгоритм заливки или последовательный обход точек внутри потенциального контура.
Пришла идея считать кол-во окрашенных пикселей в захваченной территории.
Если так считается итоговая территория, то это очень плохая идея. Если территория - это площадь, то достаточно посчитать количество треугольников внутри окружения и умножить на 0.5, т.к. треугольник - это минимально возможная площадь. Если позиции, то просто посчитать алгоритмом заливки.
Если что - я с единомышленниками работаем над созданием бота сверхчеловеческого уровня для классических Точек (в которых нужно захватывать точки, а не территорию). Делаю его на основе открытого движка KataGo: https://github.com/KvanTTT/KataGoDots
Да, в целом правила Точек легче правил Го, однако в Точках стандартный размер 39*32, что намного превышает стандартный размер в Го 19*19 - это является усложняющим фактором.
Попробовать поиграть с уже существующими ботами можно на площадке https://notago.ru (они сильны в тактике, но все еще имеют слабые стороны, которые легко эксплуатировать).
При создании игры не руководстовался какими-то определнными правилами Русских точек или Го, не было каких-то стандартов поля, в основе был листик в клеточку и просто ставить точки на пересении линии и стараться захватить бОльшую территорию. Да для интереса ввел подсчет очков по такой логике. Захват вражеской точки - 1 очко, каждая захваченная новая территория за 1000 единиц - 1 очко, за захват вражеской территории удвоенная награда. Т.е. захватили территорию размером 1200, в ней вражеская территория размером 900, то подсчет будет такой. Новая территория 1200-900=300. Вражеская территория 900*2=1800, итого 1800+300=2100, вот и 2 очка и 100единиц территории.
Тоже примерно также начал писать расширения для своих целей. Попробовав несколько популярных ии остановился на квене; чатжипити постоянно начинает придумывать что то левое или кардинально менять код, дип сик по началу идёт нормально, но позже тоже начинает выдавать дичь (прочие не пробовал). У квена тоже не всё гладко, и есть неприятности с интерфейсом в некоторых случаях. Но опять же с оговоркой про "совсем не знать ЯП" - скорее всего ничего рабочего не получится. Нужно знать хотя бы основы и английский на достаточном уровне, чтобы хоть частично понимать код, который тебе дали. А так чтобы сказал ИИ чат боту "сделай мне игру" и через 5 минут он тебе запаковал продукт, такого нет и не будет ещё очень долго.
Мой вариант игры написанной с Grok https://khanin.info/ig
Реально ли вайбкодингом без профильных знаний написать простую игру и захватит ли ИИ программистов в ближайшем будущем?