Manya Singh - Portfolio

Actual AI Architecture Decision Records screen

Context files synced

Agents.md, Aider, AWS Kiro, Claude, Cline, Cursor, Gemini, Github Copilot, Windsurf

Dev Manager

Designing a context management system for AI powered dev teams

TL;DR

Actual AI is a seed-stage startup building an autonomous agent that reads a team’s codebase and manages their coding context, keeping every coding agent aligned. As the founding product designer, I led the 0→1 design of the full product: agent dashboard, onboarding, CLI, GitHub integration, and a Storybook component library. 15 enterprise clients since launch, 1,000 teams on the waitlist. Designed for developers who build with AI, using AI to design and ship it.

Organization

Actual AI

Role

Founding Product Designer

Duration

6 months

Team

CEO, CTO, 8 Developers

Tools Used

// HOW I WORKED

Solo designer on a fast engineering team, shaping what got built and building it with them!

“Led several initiatives to improve the UX with directed feedback from users. She owned our frontend designs and pages in Storybook, led weekly discussions on the user experience and new features, and contributed directly to the source code of our full-stack application.”

Austin Born

· Lead AI Engineer

“Helped us find design consistency in an evolving product at an early stage startup. She balanced forward-looking design direction with providing on-the-fly support to developers during implementation. She also made important contributions in code, creating design system components.”

Brian Perry

· Founding Engineer

// Background

Designing an Agentic context management system for AI Powered engineering teams.

Every codebase runs on decisions called architectural decision records (ADRs). For example: ‘use Tailwind for styling’. Those decisions are the context a coding agent needs. Teams rarely keep them in one organized place. They sit in Slack threads, Word docs and Confluence pages. So when a team builds with agents like Cursor and Claude Code, each agent guesses, and the code drifts.

Actual AI reads a codebase, turns the team’s existing patterns into structured decisions, and syncs them to every coding agent as shared context, so nothing drifts.

01Codebase

Reads the codebase

02Patterns

Recognizes the patterns

03Context

Writes them down as context

04Coding agents

Syncs that context to every coding agent

When I joined as the founding product designer, the agent worked but the product didn’t. It could read a codebase and surface decisions, but what came back was a wall of raw output. The challenge lived in that gap: turning something technically powerful into something a developer would actually believe in.

// IMPACT

Reduction in drop-off after I removed approval steps for patterns already in the codebase.

1,000

Teams on the waitlist since the product launched in May.

Reduction in front-end implementation time after I built components in Storybook.

// WHAT I SHIPPED

Architecture Management Agent

Designed the product experience for an autonomous agent that manages coding context across a team’s entire codebase.

Shipped · Live

Configurations

Gives users control over decisions and agent behavior. Connects to integrations like GitHub and Slack.

Shipped · Live

Onboarding

A smooth end-to-end experience: product tour, setup checklist, and repo analysis that gets teams to value fast.

Shipped · Live

CLI

The same agent capabilities through a TUI, for developers who live in the terminal.

Shipped · Live

Marketing Website

Designed and shipped actual.ai using Cursor in a week.

Shipped · Live

Design System

A tokenized Figma library with matching React components in Storybook, so engineering could build without waiting on design.

Shipped · In use by developers

// USER PROBLEM

Developers don’t trust AI to write their architecture.

The users are AI-powered developers building with coding agents. AI went from writing 27% of code in 2022 to 46%, and in four months the same engineer went from reviewing every line to not reading most of what shipped.

How do you introduce a new way of working?

How do you get a developer to trust an agent that writes to their codebase?

“I don’t trust it to make architecture decisions. I’ll review every line.”

ReviewsOct 2025

“Honestly? I haven’t read most of what shipped this sprint. The agents handle it.”

Doesn’t reviewFeb 2026

// INITIAL OFFERING

A flow built around human approval

The experience I first designed put the developer at every checkpoint. An early product asking developers to let an AI write to their codebase has to earn trust before anything else, so they made every decision and felt in control. The agent surfaces a pattern, the developer reviews and accepts it, then ships it to their codebase as a PR.

Repository decisions

Suggested12DecisionsUpdatesDraftsArchive

RejectAccept

Every pattern landed in Suggested first.

A developer had to accept or reject each one.

STEP 00

Suggested

Agent surfaces pattern

STEP 01

Review & accept

User discusses, accepts

STEP 02

Generate PR

User gives permission

STEP 03

Accept PR

User ships to codebase

// ADOPTION CHALLENGE

Giving users too much control?

This was the first time the product had been in front of users. I ran testing in two parallel tracks through Toptal and managed both.

Users tested

Two parallel tracks

Friends and Family

Moderated usability session

2 X UW Research Team

Structured Usability Study with Partner Research Teams

FINDING 01

Every step felt like one too many

Users hit the multi-step flow and bounced. They were being asked to weigh in on things they didn’t feel they needed to.

FINDING 02

But they wanted more visibility into what the agent was doing

Less control over decisions. More visibility into the work. Show too much and they’d shut down. Show nothing and they wouldn’t trust it.

// THE PIVOT

Not every decision needs a decision

The agent was reflecting back patterns the team had already written into their code. Asking developers to approve them meant ratifying decisions they’d made months ago. So I split what the agent surfaced into two states instead of one.

Patterns

Agent sorts

Already in your codebase

automatic

New to your codebase

Decisions 0

After the change, drop-off in the flow fell by 30%.

// FINAL SOLUTION

The system that turned an untrusted agent into a tool developers rely on.

Testing showed developers wanted to know what the agent did and why. Once they had that, the approval steps only slowed them down. So I designed around information: the full picture at the moments that matter, and quiet everywhere else.

Home dashboard: Cut through the noise of a complex agentic workflow and see exactly what needs your attention right now.

Developers using coding agents are managing decisions, PRs, context syncs, and repo analysis all at once. The dashboard surfaces only what is unresolved or urgent. Nothing is buried.

Repository decisions: Every architectural choice your team has made, with the most time-sensitive ones always at the top.

PRs that conflict with active decisions come first because they are already in review. Patterns flagged but not yet synced come second. Decisions currently being generated come last. That order came directly from how developers told me they think about their day.

The architecture agent: Make one change to a decision, and every coding agent your team uses gets the updated context through a PR.

These are high-stakes, high-trust actions. A developer changing a decision needs to see exactly what will be affected before committing. The interface shows the scope of every change upfront: which agents, which files, what the diff looks like.

// Glimpse into the backend

The engineers handed me raw JSON, and I turned it into something a developer could actually understand.

onboarding / telemetry.json

{ "org_id": "c8a367d7-af4b...", "repo_unique_id": "500a18db-bbe5...", "state_counts": {"suggested": 143}, "total_count": 143, "deleted_count": 0, "archived_count": 0, "pending_commits_y": 0, "unanalyzed_files_y": 172, "files_analyzed_y": 160, "patterns_observed_y": 1011908, "patterns_evaluated_y": 109, "candidates_ready_y": 52, "candidates_claimed_y": 52, "total_suggestions_generated": 143, "last_repo_change_at": "2026-02-27 04:59:03", "updated_at": "2026-02-27 05:05:00", "repos_leased_y": 5, "files_batched_x": 160, "patterns_observed_x": 0, "patterns_evaluated_x": 109, "suggestions_generated_x": 50, "suggestions_target_y": 350, "candidates_claimed_x": 52, "workflow_status": "complete", "git_file_data_count": 0, "git_blame_snapshot_count": 0 }

stages

Discoveryfiles analyzed

160

Analysispatterns evaluated

109

Generationdecisions produced

143

Raw agent output, grouped into stages

One number per stageBuilt in Cursor

Testing showed developers wanted to see what the agent was doing while it analyzed their repo. The raw payload had the answer, but buried in too many numbers. So I broke it into three stages, Discovery, Analysis, Generation, and showed only the final number from each.

// Handoff

What my handoff looked like.

I kept my own repository where I could iterate fast on the application and our client POCs. This also ensured I got buy-in from my founder and developers early. I had also built out the Storybook components that were already in use, and developers started reusing a lot of them. This helped the team ship quickly.

manyas-designs

Application

New pages

New page 1NEW

New page 2NEW

Redesigned pages

Redesigned page 1REDESIGN

Redesigned page 2REDESIGN

Client POCs

Client POC 1POC

Client POC 2POC

application / new-pages / new-page-1

Card

Chart

Table

Button

Controls

State

DefaultLoadingError…

Version

CurrentHappy pathEdge cases

Connected to Storybook

Button

Card

Table

Chart

Used by developersIn production code

// Reflection

What I learned.

Learning new tools is part of the job.

Cursor, Claude Code, v0, Bolt: the AI tooling landscape shifted constantly. I built this product while learning these tools. The designers who understand these tools are the ones who can actually design for the people using them.

Being open to change.

The tools changed, the product changed, and the way developers worked changed, all within a few months. I had to be willing to throw out a working version when the ground shifted.

Up Next