HAI: How to Get Your Team to Work Best with AI

Aleksandar Panic — Wed, 05 Aug 2026 14:17:05 +0000

Your team is already using AI to write code. The problem is that everyone is doing it differently. One developer is in Claude Code, another in Copilot, someone on the new team swears by Cursor, and there is always one person on Codex. Each of them has set up their assistant by hand, with their own prompts, their own half-remembered configuration, and no shared idea of how the AI should approach a ticket.

So the result is inconsistent, the knowledge lives in people's heads, and none of the assistants can actually see the Jira ticket or the Confluence spec the work is based on. You end up pasting context into a chat window, over and over, for every assistant on the team.

Helper AI (HAI) is a free, open-source npm CLI that gives your whole team one shared AI workflow, whatever editor each member happens to use. It sets up Claude Code, Copilot, Cursor, and Codex the same way, with the same subagents and the same slash-commands, then pulls your Jira tickets and Confluence specs into plain Markdown the AI can actually read.

Everyone keeps their editor. Everyone gets the same setup. And every assistant on the team can finally reach the tickets and specs the work depends on.

The Same Setup, Wherever Your Developers Work

Four developers on four different editors should not mean four different AI workflows, four different sets of prompts, and four different results on the same kind of task.

HAI installs into each environment where that environment expects to find things. Claude Code gets its config in .mcp.json, Copilot in .vscode/mcp.json, Cursor in .cursor/mcp.json, and Codex in .codex/config.toml. There is an "Any editor" mode too, which lays everything out under .ai/ for manual wiring. Whichever one a developer runs, they get the same MCP server, the same seven subagents, and the same six commands. The team matches without anyone agreeing on an editor first.

Your Tickets and Specs, as Readable Markdown

A lot of the context an AI needs to do a task well does not live in the codebase. The reasoning is in a ticket. The acceptance criteria are in a spec. The screenshot showing the bug is an authenticated attachment nobody can fetch without credentials.

HAI closes that gap. Jira issues and Confluence pages land in a local .ai/ directory as plain Markdown, with comments, links, custom fields, and the page tree kept intact. Because it is Markdown on disk, your assistant reads it the same way it reads your source. It is all git-ignored by default, with no database and nothing proprietary, so switching ticket providers later does not change how anyone works.

Since files are pulled directly from the developer's environment, AI doesn't need to use long and costly searches using standard MCP plugins, everything it needs is already there.

Attachments get handled too. Since they sit behind auth, an AI cannot fetch them directly, so the image_download tool pulls them with the right credentials and caches them locally. Your assistant just reads the file.

Hand It a Ticket, Get Code Back

Setup is a one-time thing. After hai init wires up an editor and runs the first sync, the day-to-day is a single command: hand your AI a Jira key with /implement JIRA-123 and it runs the whole job.

It pulls the ticket over MCP, grabbing every issue that ticket links to in a single pass so the AI has the full picture. It researches the specs and the surrounding code. It drafts a plan. Then, once you approve, it implements the work, running the domain agents in parallel and checking each one.

That last part leans on the seven subagents HAI installs, each with a clear job. A researcher and an architect that read and plan but never touch code. Backend, frontend, and refactoring agents that write it. A security reviewer and a verifier that checks it. The implement command splits work across them by domain and runs them at the same time rather than one after another.

Free, Open Source, and Two Commands to Set Up

HAI is released under Apache 2.0 and runs on Node 16 or newer. It is one npm package, and each teammate sets themselves up with two commands:

npm install -g @2amtech/hai
hai init

hai init walks through picking an AI provider, a ticket source, and a spec source, then runs the initial sync for you, so the .ai/ folder is ready right away. There is no separate pull to run on day one. Reach for hai pull later, mainly when specs change and you want the latest copy locally.

On the source side you can point it at Atlassian for Jira and Confluence, at a Local provider that reads tickets and specs from folders on disk, or at None when you only want the subagents and commands with no ticket system attached.

Everything stays in the repository and out of git. The tickets, the specs, and the credentials are all local. Nothing about your project leaves for anywhere it was not already going.

Check it out at: https://hai.2am.tech

2am.tech Releases SQL Migration Tool to Streamline Database Changes

Aleksandar Panic — Tue, 07 Jul 2026 14:44:27 +0000

Database migrations have a reputation for going wrong at the worst possible moment. Omitted rollback scripts, schema changes applied to production but not staging, credentials hardcoded in a config file that someone committed by accident… These are the kind of incidents that haunt database administrators and backend engineers, and they are far more common than most teams would like to admit.

The SQL Migration Tool (SMT) is a free desktop app and an open-source CLI utility that empowers backend developers and engineering teams with consistency, traceability, and control over database schema management.

Plain SQL By Design

Most migration tools require developers to describe schema changes through a framework-specific syntax or an ORM layer. SMT takes the opposite approach. Migrations are standard .sql files. What gets executed is exactly what was written. The files can be run directly in any database client, independently of the tool, and they live in version control alongside the rest of the codebase.

Scripts are supported which are also SQL files with dynamic replacements which can be run to perform common database maintenance tasks.

SQL files do not have any special annotations so they can still be used in existing Database Administrator's tool of choice.

What It Does

SMT supports MySQL/MariaDB, PostgreSQL, and Microsoft SQL Server. Teams can manage multiple environments from a single project configuration, with each environment tracking its own database changes, so rollouts can be granular. Rollback scripts are plain SQL files as well, with nothing inferred and nothing hidden.

No need for hardcoded credentials. SMT can read credentials from different sources for each environment to connect to the database. For teams working in AWS environments, SMT integrates with AWS Secrets Manager out of the box. Local development setups can use .env files instead. For local or sandbox testing where security is not needed, directly entered credentials can still be provided.

Environment specific database differences like different table prefixes, columns and schemas are not a problem. With Dynamic Replacement support, rather than maintaining separate SQL files for each environment, teams can define environment specific search and replace placeholders so that different environments run a SQL targeting the proper tables at runtime. This means the same migration file can target a different schema name in a test environment versus production one, use different table prefixes per tenant in a multi-tenant setup, or insert different seed data depending on where it is being deployed. One file, cleanly adapted to wherever it runs.

Friendly for both Database Administrators and DevOps

SMT is available both as a desktop application and a CLI package. Both are released under the MIT license and are free for personal and commercial use.

Desktop application allows Database Administrators to add and manage the migrations across many projects with a simple and intuitive user interface. Available for all major operating systems: macOS, Windows, and Linux. Migrations can also be run directly from the GUI app.

For DevOps CI/CD workflows, the CLI can be used to automatically apply these migrations during a deployment. It installs via npm in a single command and can run with zero user interaction needed. It integrates nicely with any environment which can run Node, Bun or Deno runtime.

The SQL Migration Tool is available at: http://smt.2am.tech

DEV Community: Aleksandar Panic