My feed

It's been a while since I last published anything on Habr, about 10 years or so, and today is the day to share my small open-source project.

The project, called Gaunt Sloth Assistant, is a CLI AI client built with TypeScript (LangChain.js), distributed via npm, and works on Linux, Windows, and Mac. The user is in full control of the prompts, and forming your own system prompt is encouraged, but it has a default one as well.

GitHub: https://github.com/andruhon/gaunt-sloth-assistant

NPM: https://www.npmjs.com/package/gaunt-sloth-assistant

Gaunt Sloth currently has dependencies allowing it to use a simple JSON configuration for VertexAI, Anthropic, Groq, DeepSeek and OpenAI (consequently everyone else who using OpenAI format, e.g. Inception). Hypothetically, it should work with any model supported by LangChain; there's even a package available for Yandex, which I have never tried, but I think it should work if you install the package and provide a JS config. OLLAMA? It might work; I have never tried, but I will appreciate it if someone shares their experience.

The Gaunt Sloth can review pull requests and match them with requirements from a Jira or GitHub issue, review local diffs, chat, has access to the filesystem, and can write code to the filesystem.

The Gaunt Sloth is a versatile tool with a range of helpful capabilities:

• Reviews pull requests (e.g., 42) and matches them with requirements from a Jira or GitHub issue (e.g., 12).

  • gth pr 42 12

• Reviews local diffs.

  • git --no-pager diff | gth review

• Provides an interactive chat session.

  • gth chat

• Has access to the filesystem to read and write code.

  • gth code

Of course, it has MCP and OAuth, so you can connect to a remote MCP such as Jira and create and edit stories like a boss.

It also has a tiny feature that can log time against a Jira issue when it finishes reviewing a PR. This is not documented yet, but you can find the config example in the release notes or ask me in the comments (as far as I know, Jira MCP can't do that).

Apart from that, you can supply simple local AI tools in LangChainJS tool format, as simple as this:

import { tool } from "@langchain/core/tools";
import { z } from "zod";
const multiply = tool(
  ({ a, b }: { a: number; b: number }): number => a * b,
  {name: "multiply", description: "Multiply two numbers", schema: z.object({ a: z.number(), b: z.number(), })}
);

It is very config and guidelines-driven. I have a separate config in each project, setting it up for me and providing the necessary guidelines, so the AI does not screw up because of a lack of information.
Also, I have a number of non-coding projects. I have a separate one for Jira with detailed instructions on how to work with it and another for writing.

Why, when there is X and Y?

Some months ago, I was looking for a CLI assistant based on LangChainJS/LangGraphJS and didn't find many. There was a factor of curiosity and other factors as well.

The initial intent was to build a tool into which I could pipe a diff and send this diff along with guidelines to the AI, but over time it evolved, new features were built, and potentially, this can be used as a coding agent.

E.g., you type gth code, tell it implement requirements.md, so it would read the file with requirements and go coding.

GeminiCli, ClaudeCode? They were not officially released when I started, and I didn't know they were in development.
Aider, Goose? Sure, they are good and probably better options, but this would be harder to make your contributions and add features you need.

So what?

There are more features I would like to build than I have time for.
Contributors are welcome.
Trying it out and creating an issue, or sharing feedback in Discussions is also a contribution; a PR would be even better.

Некоторые товарищи, например Олег Чирухин на Фейсбуке утверждают, что LLM хорошо пишет на JavaScript / TypeScript и плохо на Verilog / SystemVerilog потому что первого в мире больше. Однако у верилога есть два критических фактора, которых у JS вообще нет. В JS если программа работает долго - это просто неудобство, в Verilog-е если нарушается тайминг внутри такта (задержки в пикосекундах) или результат приходит через 5 тактов, а он ожидался через 4 - все нафиг ломается. LLM не понимает ни тайминг внутри тактов, ни тайминг по тактам (латентность).

Никто не будет из-за этого дурацкого LLM ставить везде hanshake не зависящий от латентности подблоков, снижать пропускную способность блока на порядок или снижать в разы тактовую частоту - скажем вместо процессора с частотой 2 GHz выкатывать на рынок процессор с частотой 20 MHz. И с производительностью по тактам 2 СoreMark / MHz вместо 12 СoreMark / MHz. И при этом большой в разы и с высоким энергопотреблением. Это как продавать автомобили со скоростью и грузоподъемостью велосипеда и весом как самосвал - такое никто не купит.

Тайминг внутри такта (задержки в пикосекундах) только из кода определить нельзя, нужна процедура статического анализа тайминга, который знает задержки конкретной библиотеки ASIC (LLM не умеет делать STA (static timing analysis) и не знает задержек конкретной версии библиотеки скажем на 2 нанометра low power такого-то вендора).

С неумением LLM понимать что происходит в каком такте все интереснее. В принципе это понять можно, но это требует довольно вдумчивого анализа конкретного кода, а LLM это не просто не умеет, а в наглую пишет "for illustration, assume the latency is 1" - типа тоном профессора "для иллюстрации, предположим латентность подблока - 1 такт". А если не предполагать? С предположением все поломается.

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

Написал Олегу:

Тут есть два других фактора: 1. в реальных бизнес-задачах необходимо, чтобы разработчик мог понять например латентность кода подблоков - количество тактов на получение результата. LLM этого не понимает - оно из чужого кода часто и опытному разработчику не очевидно, а запустить симулятор и посмотреть это на диаграммах после симуляции LLM не может. 2. в верилоге есть составляющая которой вообще нет в программировании - таминг внутри такта в пикосекундах. Нужно чтобы схема синтезированная из кода в этот тайминг влезала. И если латентность (количество тактов) из чужого кода еще можно определить (если проанализировать цепочку присваиваний между комбинационной логикой и D-триггерами), то с таймингом вообще напряг. Хотя с таймингом у дизайнера вырабатывается интуиция, например что комбинационное умножение 4-х битных чисел в бюджет на 400 пикосекунд точно влезет, а вот комбинационное деление 32-битных точно не влезет - но все это нужно подтверждать запуском программы статического анализа тайминга, который (та-дам!!) LLM делать не может.

У меня есть коллега (не по Самсунгу, а по образовательным программам), который влюблен в ИИ. У меня есть опасения что он может использовать ИИ для написания некой инструкции, которая включает теоретическую базу SystemVerilog-а. С моей точки зрения это очень дурная идея, так как LLM не следует стандарту, а генерит то, что людям интуитивно "кажется". Для иллюстрации спросил у ChatGPT 4.0 чем отличается wire, reg и logic. Словил 3 ошибки и 2 недочета:

1. Недочет: LLM (как и большинство людей, даже экспертов) забыл упомянуть про разницу в контексте инициализации ("wire a = b" это continuous assignment то есть "wire a; assign a = b;", а вот "logic a = b" это инициализация в момент 0, то есть "logic a; initial a = b;")

2. Ошибка: LLM почему-то думал что "wire a = 1'b0" несинтезируемо в Verilog, но синтезируемо в SystemVerilog.

3. Ошибка: LLM думал, что "always_ff" можно использовать для создания D-защелки (D-latch).

4. Ошибка: LLM думал, что "always_comb" может infer latch.

5. Недочет: LLM забыл про "always_latch".

То есть если скажем преподаватель ленится читать стандарты и книги, но вздумал писать методичку с помощью ChatGPT, то его студенты жестоко пострадают (баг от (1) трудно отлаживать) и будут понимать все "приблизительно".