DEV Community: Aditya Goyal

Local-first AI explained

Aditya Goyal — Thu, 01 Oct 2026 01:52:01 +0000

Local-first AI means your own device holds the primary copy of your data, and the AI tool works from that copy, sending out only what a given task needs. It does not have to mean the AI model itself runs on your machine, although it can.

The term "local-first" comes from software design. A local-first application treats the copy on your device as the real one. The network is used for sync, sharing and backup, not as the only place your work lives. The application keeps working when you are offline, and your files remain readable if the vendor disappears.

Applied to AI, the same idea raises a useful question: for each part of the tool, where does it run and where does its data rest?

Three things that can be local

It helps to separate three layers, because a product can be local in one and not the others.

Your data. Notes, documents, code, mail, transcripts. Local-first means these sit on your disk in formats you can open without the tool, such as plain text or Markdown.
Your credentials. API keys and sign-ins. Local means they sit in the operating system's secret store, not on a vendor's server. See where your AI keys and logins should live.
The model. The AI that reads the prompt and writes the answer. This may run on your device, or in a provider's data centre.

Many practical setups are local for the first two and remote for the third. That is still a meaningful improvement over a setup where all three live on someone else's servers.

Local models and remote models

Running a model on your own hardware is possible. Open-weight models can be downloaded and run on a laptop or workstation, and smaller ones run acceptably on ordinary machines.

The trade-off is capability against hardware. Larger models generally give better answers on hard tasks, and they need a lot of memory and a capable graphics processor or similar accelerator. The strongest models are typically offered only as hosted services. Smaller local models do well on narrower jobs: transcription, classification, summarising short text, searching your own notes.

So a sensible local-first design is often a mix:

Task	Often runs locally	Often runs remotely
Speech-to-text	Yes	Also common
Search over your own notes	Yes	Sometimes
Short summaries and tagging	Possible	Common
Long reasoning, large coding tasks	Rarely	Usually

The guide on on-device meeting transcription looks at one of these in detail.

What "only what the task needs" means

When a remote model is involved, something has to leave your device. Local-first design is about keeping that to the minimum and making it visible.

In a cloud-first tool, your whole workspace may be uploaded and indexed on the vendor's servers so that the AI can search it. In a local-first tool, the index sits on your machine. When you ask a question, the tool finds the relevant passages locally and sends only those, with your question, to the model.

The difference is between a standing copy of everything and a small, task-sized extract. The guide on what gets sent to an AI provider explains what that extract usually contains.

The benefits

Fewer custodians. If the tool vendor never stores your content, there is one less party to assess, and one less place for a breach to happen.
Works offline, at least in part. Your notes and files are there without a connection. Anything that needs a remote model will wait.
Speed for local operations. Opening, searching and editing do not wait on a server round trip.
Durability. Files in open formats outlive the tool. You can move to another editor or another vendor without an export project.
Clearer answers to compliance questions. "Where is the data?" has a short answer.

The costs

Local-first is not free, and it is worth being honest about that.

You are the custodian. Backups, disk encryption and lost-laptop plans become your job. A cloud vendor's operations team is no longer covering for you.
Sync is hard. Keeping several devices and several people in step without a central server is a real engineering problem. Techniques such as conflict-free replicated data types exist for this, but edge cases remain, and many local-first tools still use a server for sync while keeping the device copy primary.
Hardware limits. Local models are bounded by the machine. Battery, heat and memory all matter.
Shared work needs thought. Team features such as permissions, audit and search across everyone's material are simpler with a central server. Local-first tools have to design these deliberately.
Updates and support. Software running on many different machines is harder to keep uniform than one hosted service.

How to tell whether a tool is really local-first

Marketing uses the term loosely. A few checks cut through it:

Disconnect from the network. What still works?
Find your data on disk. Can you open it with another program?
Ask where your sign-ins and keys are stored.
Ask what is uploaded in the background, not only when you press send. This includes indexing, telemetry and crash reports.
Ask what happens to your data if you stop paying.

If the answers are vague, the list of questions to ask an AI vendor gives a fuller set.

When local-first is not the right choice

Some work is better served centrally. Large shared datasets, heavy model training, and systems that many people must query at once belong on servers. A team with no capacity to manage devices may be safer with a well-run hosted service than with sensitive files scattered across unmanaged laptops. Local-first is a design preference, not a rule. The aim is to know where your data is, and to have chosen that on purpose.

Written by Aditya Goyal, AI-assisted. First published on the Prism Labs website.

Human in the loop: designing approvals people do not skip

Aditya Goyal — Wed, 30 Sep 2026 13:52:01 +0000

Human in the loop means an AI agent stops before a consequential action and a person decides whether it goes ahead. It only works if that person actually reads and thinks, so the real design problem is asking rarely, asking clearly and making a considered answer as easy as a careless one.

An approval that is clicked without reading protects nothing. It only moves the blame. This guide covers why approvals get skipped, how to choose what deserves one and how to design the step itself.

Why approvals get skipped

Anyone who has clicked "Accept all" on a cookie banner knows the pattern. Three things cause it.

Too many prompts. If an agent asks permission for every file it reads, the person learns within minutes that the answer is always yes. After that the hand moves before the eyes do. This is often called alert fatigue, and it is well known from fields where people work with many warnings. A system that raises frequent low-value alerts trains people to ignore all of them, including the one that matters.

Prompts that say nothing. "The agent wants to run a command. Allow?" gives the person nothing to judge. If a proper decision requires opening three other windows, most people will not do it.

Trust built on a good record. When an agent has been right many times in a row, checking feels like a waste. People relax, which is natural, and is sometimes called automation complacency. The rare error then arrives when attention is lowest.

None of these is a failing of character. They are predictable responses to poor design, so the fix is in the design.

Decide what deserves an approval

Not every action needs a person. A useful test has two questions: can it be undone, and does it reach beyond the agent's own working area?

Kind of action	Examples	Sensible default
Reading and searching	Opening files, looking things up	Allow without asking
Changes inside a sandbox	Editing files on an isolated copy, writing a draft	Allow, review the result later
Changes to shared things that can be undone	Merging a branch, editing a shared note	Ask, showing the exact change
Actions that cannot be undone or that reach other people	Sending email, paying, deleting, publishing, installing software	Always ask, every time

The more work you can move into the second row, the fewer prompts you need. An agent that works on a copy of a repository can edit freely, because nothing counts until a person merges. See why coding agents should work on a copy of your repo. An agent that prepares an email as a draft can write whatever it likes, because nothing leaves until a person sends.

This is the most effective single move: turn many small approvals into one meaningful review. Rather than approving forty edits one at a time, review one diff. Rather than approving each sentence, read one draft.

Design the prompt so it can be judged

When you do ask, the person should be able to decide from the prompt alone.

Show the actual thing. The full email with its recipients. The diff. The exact command. The name, source and version of the package to be installed. Never a summary in place of the real content, because the summary is written by the same agent whose work is being checked.
Say what will happen and whether it can be reversed. "This will send to four external addresses and cannot be recalled" is different from "this saves a draft".
Put the risky details first. External recipients, deleted files and production systems should stand out, not sit on line thirty.
Give the reason. One line on why the agent wants to do this, linked to the request that started it.
Offer more than yes and no. "Edit first", "ask the agent to revise" and "reject with a reason" all produce better results than a bare refusal, and give the agent something to work with.
Make no the safe default. Closing the window, timing out or pressing Enter by reflex should not count as approval.

Avoid the traps

Blanket "always allow". A remembered permission is sensible for narrow, harmless things such as running the test suite. It is dangerous for broad ones such as running any command. If you offer it, scope it tightly and make it easy to see and withdraw.

Approval by the wrong person. The approver should be someone with the authority and the context to judge. In shared spaces that is usually the owner of the agent or the owner of the thing being changed. See when agents owned by different people work in one room.

Bundles that hide things. Batching is good, but a batch of fifty items where one is unlike the rest is a trap. Group similar things and pull the unusual item out so it is seen.

Rejections that do not stick. If a person rejects something and the agent proposes it again an hour later, people give up. A rejection should be remembered, with its reason.

Urgency. Anything that pushes for a fast answer, such as countdowns or repeated reminders, lowers the quality of the decision. If a decision can wait, let it wait in a queue.

Keep a record

Every approval and rejection should be logged: what was proposed, the exact content at the time, who decided, and when. This has three uses. It lets you trace a problem back afterwards. It shows patterns, such as an approval that is accepted every time without changes, which may be safe to automate, or one that is rejected often, which points to an agent that needs better instructions. And it makes accountability real, because a named person decided on the basis of specific content.

Check that it is working

A few signs are worth watching. If approvals are nearly always granted within a second or two, people are not reading. If nothing is ever rejected or edited, either the agent is perfect or the review is a formality, and the first is unlikely. If people complain about the number of prompts, believe them and cut the number, rather than asking them to pay more attention. Attention is limited, and good design spends it only where it counts.

Written by Aditya Goyal, AI-assisted. First published on the Prism Labs website.

Why coding agents should work on a copy of your repo

Aditya Goyal — Wed, 30 Sep 2026 01:53:19 +0000

A coding agent should work on its own copy of your repository, on its own branch, so that nothing it does touches your working files until you have read the diff and merged it yourself. Git worktrees are the simplest way to do this: one repository, several separate working directories, each on a different branch.

This guide explains what goes wrong without isolation, how worktrees work, the commands you need and the limits you should know about.

What goes wrong in a shared directory

If an agent edits the same directory you are working in, several problems appear quickly.

Mixed changes. Your half-finished work and the agent's edits end up in the same set of uncommitted changes. Telling them apart later is tedious and easy to get wrong.
Moving ground. The agent changes a file while you are reading or editing it. Your editor, your running development server and your tests all see a project that keeps shifting.
Harder review. There is no clean line between before and after, so there is no single diff that shows what the agent did.
Harder undo. If the result is poor, you want to throw it away. In a shared directory, discarding the agent's changes risks discarding your own.
Collisions between agents. Two agents in one directory overwrite each other's files and run tests against each other's unfinished work. See running more than one AI coding agent.

Isolation solves all five with one idea. The agent's work lives somewhere else until you choose to bring it in.

What a git worktree is

Normally a git repository has one working directory: the folder where the files of your current branch are checked out. A worktree is an additional working directory attached to the same repository. Each worktree has its own checked-out branch, its own files on disk and its own staging area. All of them share one underlying store of commits and history.

That sharing is the advantage over making a second clone. There is no second copy of the history to download or keep in step. A commit made in one worktree is visible from the others straight away, because there is only one repository underneath. You can compare, cherry-pick or merge between them without pushing or pulling anything.

Git applies one rule that helps here: the same branch cannot be checked out in two worktrees at once. Each agent is therefore on its own branch by construction.

The basic commands

Create a worktree in a sibling folder, on a new branch:

git worktree add ../myproject-fix-login -b agent/fix-login

See what exists:

git worktree list

Review the work from your main directory when the agent has finished:

git diff main...agent/fix-login

Merge if you are satisfied, then tidy up:

git merge agent/fix-login
git worktree remove ../myproject-fix-login
git branch -d agent/fix-login

If a worktree folder was deleted by hand, git worktree prune clears the leftover record.

Many agent tools now create and remove worktrees for you. It is still worth knowing what happens underneath, because at some point you will need to find a branch or clean up after a session that ended badly.

A simple workflow

Create a worktree and branch for the task. Name the branch after the task, and the agent if you use several.
Start the agent in that directory with a bounded task and a clear finishing condition, such as a test that must pass.
Let it work freely there. Because nothing counts until you merge, the agent does not need to ask before each edit. This removes most of the small permission prompts that people learn to click through, a problem described in designing approvals people do not skip.
Review one diff. Read it as you would a colleague's pull request. Run the checks.
Merge it yourself, ask for changes, or delete the branch and lose nothing.

The important shift is that review happens once, at a natural boundary, with the full change in front of you.

Things that catch people out

Files git does not track are not copied. A new worktree contains only tracked files. Installed dependencies, build output and local settings files that git ignores will be missing. You will usually need to run your install step in each worktree, and provide any local configuration the project needs. Be careful about copying secrets into a directory an agent can read; give it test credentials where possible.

Disk space and install time. History is shared, but each worktree has its own checked-out files and its own installed dependencies. For large projects this adds up. Remove worktrees when you have finished with them.

Shared machine resources. Separate directories do not give you separate ports, databases or caches. Two worktrees running the same development server will collide on the port. Give each its own, or run one at a time.

Stale branches. If the main branch moves on while an agent works, its branch falls behind. Bring it up to date before you review, so you are judging the change against the current code.

Submodules and unusual setups. Projects that use git submodules or depend on absolute paths may need extra care. Test the process once by hand before relying on it.

A worktree is not a sandbox

This point matters most. A worktree isolates the agent's changes from your working files. It does not restrict what the agent can do on your computer. An agent that can run shell commands can still read other folders, use the network and reach anything your user account can reach. It also shares the repository's configuration and hooks with your main checkout.

For protection against a misbehaving agent or a malicious instruction hidden in something it reads, you need other measures as well: limited tools and permissions, approval for risky commands, and for stronger separation a container or virtual machine. See skills, plugins and tool servers explained for how an agent's reach is decided. Use worktrees to keep work organised and reviewable, and use permissions and sandboxes for safety.

Equally, keep the step that leaves your machine under your own control. An agent can commit to its branch as often as it likes. Pushing to a shared remote, opening a pull request and merging are better kept as decisions a person makes.

Written by Aditya Goyal, AI-assisted. First published on the Prism Labs website.

What actually gets sent to an AI provider when you ask?

Aditya Goyal — Wed, 30 Sep 2026 01:52:48 +0000

When you ask an AI model a question, the provider receives the whole request, not only the sentence you typed: hidden instructions, the earlier conversation, any attached files or retrieved passages, and descriptions of the tools the model may use. The model has no memory between requests, so everything it needs to know must be sent again each time.

That second point surprises people. It is the key to understanding what leaves your device.

Models are stateless

A large language model, as served over an API, does not remember your last message. Each request stands alone. The appearance of memory in a chat comes from the application, which resends the conversation so far along with your new message.

So by the tenth message in a long chat, the request contains messages one to nine as well. If you pasted a long document in message two, that document is sent again with every later message in that conversation, unless the application trims or summarises the history. Some providers offer caching so that repeated content is cheaper and faster to process, but the content is still part of the request.

The parts of a typical request

Part	What it is	Who wrote it
System prompt	Standing instructions: role, rules, tone, format	The application
Conversation history	Earlier messages and replies	You and the model
Your new message	The question you just typed	You
Attachments	Files, images, pasted text	You
Retrieved context	Passages the application looked up for this question	The application
Tool definitions	Names and descriptions of tools the model may call	The application
Tool results	Output from tools called earlier in the task	Your systems
Parameters	Model name, length limits and similar settings	The application

Alongside the content, the request carries the usual network details: an API key or session token that identifies the account, your IP address, and headers naming the client software.

Retrieved context: the part you do not see

Many AI tools search your documents before asking the model. This pattern is called retrieval-augmented generation. The application finds passages that look relevant and places them in the request, so that the model can answer from them.

This is useful, and it is also the easiest place for more to leave your device than you expected. You typed one line. The application may have added several pages from your files. A well-designed tool shows you what it attached. The guide on AI answers with sources explains why this pattern is worth the trade.

Agents send more than chats

An AI agent works in a loop. It asks the model what to do next, runs a tool, sends the result back, and repeats. Each tool result becomes part of the next request.

For a coding agent, that means file contents, directory listings, command output, error messages and test logs all go to the provider as the task proceeds. If a command prints an environment variable that holds a password, that password is now in a prompt. If the agent reads a configuration file with credentials in it, the same applies.

This is why the set of tools and files an agent can reach matters so much. The guide on skills, plugins and tool servers covers how those are granted.

What is usually not sent

Files the application never read. A model cannot browse your disk. It sees only what the application places in a request. The risk lies in how much the application is allowed to read, not in the model reaching out.
Your password for the provider. A request carries a token or key, not the password itself.
Other applications' data. Unless a tool or integration has been connected that fetches it.

Treat these as the normal case, not a guarantee. What a particular application reads and uploads in the background, such as indexing, telemetry and crash reports, is a question for that vendor.

What happens at the other end

Once a request arrives, the provider processes it and returns a response. What happens afterwards depends on the provider, the plan and your settings. The points that commonly vary are:

how long prompts and outputs are retained, and in which logs
whether content may be used to train or improve models, and whether that is opt-in or opt-out
whether staff or automated systems may review content, for example for abuse monitoring
where the data is processed geographically
which other companies process it on the provider's behalf

Consumer plans and business or API plans from the same provider often have different terms. Do not rely on a summary written by someone else, including this one. Check the provider's current terms for the exact plan you use.

There may also be an intermediary. If you use an AI feature inside another product, the request may pass through that product's servers before reaching the model provider. That adds a custodian. The guide on data custody in AI explains why each hop matters.

How to keep requests small

Start new conversations for new topics. Old history stops being resent.
Paste the relevant section, not the whole document.
Remove what the model does not need. Names, account numbers and identifiers can often be replaced with placeholders without harming the answer.
Keep secrets out of files and output an agent can read. Use a proper secret store. See where your AI keys and logins should live.
Limit what agents can reach. Give each one the folders and tools the job needs, no more.
Prefer tools that show you the request. If you can see what was attached, you can correct it.

None of this requires avoiding hosted models. It requires knowing that the unit of disclosure is the full request, and shaping that request with care.

This is general information, not legal advice. If you handle personal or regulated data, check your obligations with your own adviser.

Written by Aditya Goyal, AI-assisted. First published on the Prism Labs website.