The Kind of AI Adoption I Actually Believe In – Nas' Meanderings

Skip to content

Nas' Meanderings

AI, Blog, Products, Project Management, Startup, Team Management

The Kind of AI Adoption I Actually Believe In

May 6, 2026

One thing I’ve learned building creative and technical teams is that motivation does not come from process alone. It comes from grounded creative freedom.

People do their best work when they have room to make real decisions, but within enough structure that the work connects to a shared goal. That balance creates ownership. Ownership creates motivation. And motivation creates better work than any top-down productivity system can force.

That matters a lot when adopting AI.

The mistake is treating AI as a replacement for the creative agency of the team. If a tool makes people feel bypassed, judged, or competed with, it is not helping, even if it looks efficient on paper. In creative work especially, the human relationship to the work is part of the work.

I’ve run into this directly. Some AI art-generation tools were not comfortable for one of my artists. So I dropped them from production use and kept them in R&D. That was not a rejection of AI. It was a decision about trust, ownership, and the kind of team culture I want to protect.

At the same time, I’ve been using AI heavily around the edges: improving dashboards, syncing issue data, documenting workflows, debugging open-source tooling, and making planning signals more visible. That is where AI has been most useful: not replacing the creative center, but strengthening the infrastructure around it.

AI Works Best When It Supports Human Intent

One area where AI has genuinely improved our workflow is project visibility and planning.

We use Gitea for issue tracking, milestones, and project management. I like it because it is lightweight, open-source, self-hostable, and easy to adapt. But like many open-source tools, some workflows require inventiveness.

Technically, I could have used Microsoft VSO, GitHub Projects, Jira, or any number of commercial planning platforms. I’ve worked with most of them throughout my career. But I intentionally wanted something more in-house and controllable.

Part of that was privacy. Part of it was flexibility. But a major reason was wanting to think about AI integration from the ground up instead of bolting it onto a workflow designed years before modern AI tooling existed.

Right now, a lot of companies are rushing to inject AI into every surface imaginable simply because they can. In many cases, the human impact feels like an afterthought. Creative friction, team trust, ownership, and psychological effects often get ignored in favor of feature velocity or investor narratives.

I wanted the opposite approach.

I wanted a system where AI existed inside a deliberately constrained environment with clear boundaries, inspectable logic, and strong human override mechanisms. A system designed around augmenting the team rather than quietly competing with it.

That philosophy heavily influenced the architecture of the tooling itself.

For example, Gitea does not natively support story points in the way many commercial planning systems do. So I hacked together a convention using labels:

1sp

2sp

3sp

5sp

8sp

13sp

Simple, but surprisingly effective.

Once that structure existed, I built a pipeline around it. Issues, milestones, labels, and project metadata are synchronized into a database and visualized through Grafana dashboards. Milestones effectively became sprint containers. Story-point labels became lightweight planning metadata. The result was a shared operational view of the state of the work.

But the interesting part was how AI fit into the system.

I started experimenting with heuristic-driven estimation pipelines that analyze issue titles, descriptions, metadata, discussion activity, and historical patterns to suggest story-point estimates for tasks that were missing them.

Importantly, the AI is never treated as authoritative.

Human-assigned labels always override inferred estimates. The goal is not to automate judgment. The goal is to reduce bookkeeping friction and fill structural gaps in planning data.

That distinction matters a lot.

AI is extremely useful at maintaining systems around human intent. It becomes much more dangerous when people start treating it as the source of intent itself.

The pipeline eventually evolved into something larger:

issue synchronization

milestone projection

velocity calculations

heuristic estimation

dashboard publishing

release forecasting

snapshotting historical progress over time

A surprising amount of care had to go into keeping the metrics honest.

For example:

Pull requests should not contribute additional story points because the actual work belongs to the issue itself.

Explicit human estimates should always override inferred ones.

Forecasts should become more conservative when scope expands.

Unestimated tasks should not silently distort...