DEV Community: Aline Mercer

New AI tools come out every week. How do you decide which ones to keep, and how do you stop keeping up from becoming a second job?

Aline Mercer — Wed, 21 Oct 2026 15:39:46 +0000

A new assistant, agent or app gets hyped almost daily, each with someone insisting you have to try it. Keeping track of them can turn into a part-time job of its own.

We'd like to hear what actually works for you, not what the listicles recommend:

When did you last drop a tool you were paying for, and what finally made you do it?
Think of the last new AI tool you tried. Did it make it into your routine, and how did you know?
What's your rule for letting a new tool in: a short list you revisit, a test on a real task, waiting until someone you trust vouches for it, or simply giving up on keeping up?

Any kind of work counts, not just coding, and a quick rule of thumb is as welcome as a story.

Drafted with AI assistance.

How do you keep track of three agents running at once without babysitting them?

Aline Mercer — Mon, 19 Oct 2026 17:18:07 +0000

Say you have three agents running at the same time: coding agents, or any other kind of AI agent working in the background.

How do you know which one is waiting for you, which one is finished and which one is stuck? Do you flip between tabs, rely on notifications, watch a dashboard, or have you built something of your own?

When was the last time an agent sat idle because you missed the moment it needed you? And what did you change afterwards?

We're collecting real setups and real workarounds, and we'll read every reply.

Drafted with AI assistance.

How many AI tools do you actually use in a week, and what's the most annoying part of moving work between them?

Aline Mercer — Mon, 19 Oct 2026 15:07:59 +0000

We're trying to understand how this really works day to day, so we're asking for specifics rather than opinions.

Think about last week:

Which AI tools did you actually open? Chat assistants, coding agents, image, music or video tools, anything counts.
When you moved a piece of work from one of them to another, what was the most annoying step? Copying context over, re-explaining the background, finding where a result ended up, or juggling several accounts and subscriptions?

If you have a workaround (a notes file, a script, a checklist, a habit), please share it. We'll read every answer.

Drafted with AI assistance.

Let an agent sign in for you without showing the model your password

Aline Mercer — Sat, 17 Oct 2026 09:26:22 +0000

You are halfway through a task with an agent. It has found the settings page and filled in most of the form, and then it stops: "To continue, please paste your password here." Or it needs an API key for the service it is about to call, and the chat box is right there.

It feels harmless because the conversation feels private. But a chat is not a safe.

Why the chat box is the wrong place

Anything you type into a prompt becomes part of the model's context. Depending on the tool, it may be kept in history, written to logs, sent to a hosted model or summarized into memory that later conversations read. You cannot see or reliably delete all of those copies.

The same goes for instruction files. Files such as CLAUDE.md or AGENTS.md exist so the model reads them on every run. That makes them a good home for project conventions and a bad home for a token. Treat them as visible to the model, and often to everyone with access to the repository.

The goal is simple to state: the agent can use a credential, but the raw value never enters the text the model reads or writes.

Use a store the tool calls for the model

The pattern that works is a credential store or vault that sits outside the conversation. The model asks for an action, such as "sign in to the billing portal" or "call the API with the deploy token", and the tool fetches the secret and uses it directly. The model sees a reference or a result, never the value.

Your operating system's keychain is the simplest version of this; a dedicated secrets vault adds encryption, access rules and a usage history. Either way, check one thing: when the agent uses the secret, does the value show up in the transcript? If it does, the store is decoration.

Give the agent less than you have

Scope tokens. Create a token for the one job: read-only if reading is enough, one repository, one project. Do not reuse a key that can do everything.
Expire them. A short lifetime turns a leak into a small incident. Set the expiry when you create the token, not later.
Prefer OAuth and app passwords over master passwords. Delegated access can be limited and revoked without changing the password you use everywhere else. A master password should never be something an agent holds.
Keep 2FA and payments in human hands. The second factor is where a person confirms intent. Let the agent get you to that screen; you approve the code, the purchase or the transfer yourself.

Log every use, and read the log

A credential an agent can use should leave a trace each time it is used: which secret, when, and for which task. Many services also keep their own sign-in and API activity pages. Set a recurring reminder to skim both. You are looking for uses you do not recognize, at times you were not working, against services you did not ask about.

After a paste accident, rotate

If a secret did land in a chat, a log or a committed file, assume it is exposed. Rotate it at the source, revoke the old value, then clean up the copies you can find. Deleting the message is fine, but it does not replace rotation.

Risk and the safer habit

Risk	Safer habit
Pasting a password or key into the chat	Keep it in a vault or keychain the tool reads on the model's behalf
Tokens in CLAUDE.md, AGENTS.md or other instruction files	Refer to a named secret; never write the value
One broad key reused for everything	Scoped, per-task tokens with an expiry date
The agent holds your master password	OAuth or app-specific passwords you can revoke
The agent completes 2FA or a payment alone	You confirm the code, purchase or transfer yourself
No record of what the agent did with access	A usage log per secret, reviewed on a schedule
A secret leaked into a transcript	Rotate at the source first, then clean up

Before you let an agent sign in through a browser

Browser sign-in is where agents become most useful for website chores. Before you grant it, check:

[ ] The credential comes from a store, not from the chat or a file the model reads.
[ ] The account has the least access the task needs; a separate, limited account is better where the site allows it.
[ ] 2FA stays on, and the second factor reaches you, not the agent.
[ ] Payments, account deletion and security settings need your confirmation.
[ ] You can see which sites the agent signed in to, and when.
[ ] You know how to revoke the session or token in one step.
[ ] Saved browser sessions are cleared or expire when the task is done.

None of this needs special tooling to start. Move the next secret out of the prompt, shorten the next token's life, and keep the last click on anything irreversible for yourself.

This post comes from the Octuo team at Tutuo, Inc. More of our notes on handing work to agents are on our blog.

Drafted with AI assistance and reviewed before publishing.

The handoff brief: what to write before a coding agent starts

Aline Mercer — Sat, 17 Oct 2026 08:51:11 +0000

Most agent runs that go sideways don't fail at the code. They fail at the handoff. The task lived in someone's head and the prompt carried only half of it. The diff that comes back answers a slightly different question than the one we meant to ask. Reviewing it then means working backwards from the output to the intent, and that is the slow direction.

So before we give any non-trivial task to Codex or Claude Code, we write a short handoff brief. Review then becomes a comparison: did the run do what the brief said, and nothing else?

What goes in a brief

Goal: the outcome in one or two sentences, not the method.
Scope: what the agent may change, as paths or modules.
Off limits: files and behaviour it must not touch, even if it thinks it should.
Checks: the exact commands that prove the change works.
Done: the observable state that ends the task.
Report back: what the summary must contain.
Escalate, don't guess: decisions that belong to a human.

The last item does the most work. When an agent hits an ambiguity, it will usually resolve it somehow. If you name the ambiguities up front, a silent guess becomes a question in the report.

The template

## Goal
<What should be true when this is done.>

## Scope
May change:
- <path or module>

Off limits (do not edit, even to "fix" something):
- <generated code, migrations, lockfiles, CI config>
- <public interfaces other code depends on>

## Context
- <Why this change; constraints the code doesn't show>
- <Link to the issue or prior decision>

## How to check
- Run: <test command>
- Run: <lint / type-check command>
- Expected: all pass, no tests skipped or deleted

## Done means
- <Observable condition>

## Report back
- Files changed, one line on why for each
- Commands run and their results
- Anything noticed but not changed
- Every assumption made

## Escalate instead of guessing
- <Behaviour changes visible to callers or users>
- <New dependencies, secrets or credentials>
- <Checks that cannot pass without touching an off-limits path>

Keep it short. Codex's docs on managing usage advise controlling the size of prompts and reducing the size of AGENTS.md. The same logic holds for readability, because a brief that restates the codebase gets skimmed. Durable project rules belong in the instruction file the tool already reads (AGENTS.md, CLAUDE.md), and the brief covers only this task. Claude Code's guidance to use /clear when starting a new task fits well here: clear the context, then paste the brief.

A vague brief and a better one

The task: a small internal service still calls a deprecated fetchLegacy method on its HTTP client wrapper.

The vague version:

Replace the deprecated fetchLegacy calls with the new client API and make sure everything still works.

That brief leaves four questions open:

Which files count?
Must the retry behaviour be kept?
What does "everything" mean?
What happens to call sites that pass options the new API lacks?

The agent will answer all four. We just won't know how until we read the diff.

The better version:

Goal: no calls to fetchLegacy remain in src/; behaviour for callers is unchanged.
Scope: src/clients/ and src/handlers/. Off limits: src/generated/, the dependency manifest and lockfile, migrations/.
Check: unit tests and type-checker pass, with no tests skipped or deleted.
Done: a search for fetchLegacy in src/ finds only its definition, which stays for a follow-up.
Report: each call site changed, and how retries are handled now.
Escalate: any call site relying on an option the new API lacks. Leave it unchanged and list it.

It's the same task, but now the reviewer knows what a correct diff looks like before opening it.

When the run comes back

Diff first, summary second. The summary is an account of the work; the diff is the work. Check the file list against Scope and Off limits.
Rerun the checks yourself, using the commands from the brief, in a clean state. "Tests pass" in a report is a claim, not evidence.
Look for silent scope creep: reformatted files, renamed helpers, a nearby cleanup, a loosened assertion, a new dependency. Each may be fine. None should be a surprise.
Answer the escalations and write the answers down.
Record decisions in the brief, the commit message or the PR description, so the next brief starts from there.

Where context gets lost between tools

The weak point is rarely inside one run. It sits between runs:

Reasoning from a planning chat never reaches the agent.
An escalation gets answered in one terminal and then forgotten.
A follow-up starts in another tool without any of the earlier decisions.

Each tool keeps its own session history. A brief kept in a file and updated with what came back is the one thing that carries across tools. Treat it like code: version it, review it and reuse it.

This post comes from the Octuo team at Tutuo, Inc. More of our notes on running coding agents are on our blog.

Drafted with AI assistance; the tool behaviour mentioned was checked against the Codex and Claude Code documentation before publishing.

Octuo — Your AI (SI) Hands

Aline Mercer — Mon, 12 Oct 2026 04:09:57 +0000

If you use a lot of AI tools, you know how this goes. A typical setup could be Claude Code or Codex for code, sometimes one account for work and another for personal use; Figma or Google Stitch for design, Midjourney for images, Suno for music, Perplexity for research, Gamma for slides, n8n for automation, and so on and so forth. New ones keep showing up, and you often hear about them from someone else.

Each one is good at its job. But it has gotten complicated enough that at some point you want a tool just to manage your tools. Right now that tool is you. You copy context from one window to another and explain the same thing again to each of them.

We made Octuo for that. It can do a lot, but at its core it is an assistant that works through those tools for you. You say what you want, it hands the pieces to the right tool or agent, follows each run, and brings the results back to one place. What you want, what you need, how the work is going and what came out of it all live in that one place, and the assistant can always reach it, with nothing in between. Over time the effort you put in adds up and compounds there, instead of scattering across ten tools.

Say you need a bug fixed, an icon, and a short soundtrack. You ask once. Octuo briefs the Claude Code and/or Codex already on your computer, in parallel, and hands the rest to other tools you have registered. If you have connected several accounts you are authorized to use, it spreads the work across them, passes along the context each job needs, and gives you one report at the end.

You stop repeating yourself too. Which projects you are tracking, which chores are open, what is still unsolved: you should not have to say it again every week. Octuo recalls what you have said anywhere in your account. You also stop clicking through websites one by one. The agent does it in your browser, within the permissions you give it. When a site needs a login it uses a password from an encrypted vault, and the model never sees the password. Each use is logged, so you can check that the model is not doing anything it should not.

People talk about raising an agent, meaning teaching it how you work. The trouble is that each vendor's agent tends to learn only inside its own product, so with ten of them you raise ten. We think it makes more sense to raise one assistant and let it carry what it knows about you into the work it hands over. It is also a maintained product that keeps improving and reaching more of what is out there, so you do not have to follow and tune every new tool yourself.

Being a product we sell also means the experience gets real attention. The memory is a graph you can open, edit, or tell it to forget, so you can check whether it remembers what you care about. You can easily talk to it by voice, or dictate instead of typing. And you can see at a glance what is running, what is done, and what is waiting for your decision. When you can see it is handled, you stop checking. Some jobs are long and have many steps. Hand those over too. It keeps taking care of them on its own for as long as it can, and schedules and watches run by themselves and only speak up when something changes. On top of all that, you can simply stay on Octuo's home screen, say a few words, and let every agent in the system work for you.

Octuo is a native app for Mac today, an iPhone companion is coming, and we plan to support more platforms. Most model calls go to cloud-hosted models, so what a model needs for a task goes to its provider. On first launch macOS asks for Screen Recording and Accessibility permissions, and whether to grant them is your call. It is a paid product, and the page has the details.

We would like to hear from you. Which of your tools and accounts are hardest to keep track of right now? What kind of assistant do you wish you had, and what would you hand over first? And if you try it, give it a long, multi-step job and tell us what else you want improved.

The tools named above are only examples. Their names belong to their owners, and we have no affiliation with them.

I Built an AI Agent Tool Marketplace on a Static Site (It Costs Almost Nothing)

Aline Mercer — Sun, 08 Mar 2026 01:36:56 +0000

If you are building with AI agents, you have probably hit this wall: your agent needs tools but finding them means digging through GitHub repos and random blog posts. There is no npm for AI agent tools.

That is the problem I set out to solve with TutuoAI, a marketplace for AI agent tools. We now catalog 116 products (38 paid, 78 free), and the entire thing runs on a static site architecture that costs almost nothing to operate.

The Discovery Problem

AI agents are only as good as the tools they can access. Tool discovery is a mess:

For developers: You Google AI tools, get 50 listicles, spend hours evaluating
For agents: No machine-readable catalog exists
For tool builders: Hard to get discovered

The Architecture: Why Static Wins

S3 + CloudFront serves pre-rendered HTML pages. Stripe Checkout handles payments with no backend. No servers, no databases, no containers.

Cost: essentially free. Speed: ~50ms globally. Reliability: 99.999999999% durability.

Making It Machine-Readable: llms.txt and JSON-LD

I implemented llms.txt so any AI agent can programmatically discover what tools are available. Every product page also includes Schema.org JSON-LD for structured data.

Lessons Learned

What worked: Static architecture kept costs at zero. llms.txt generated interest from AI developers. Stripe Checkout eliminated weeks of backend work.

What did not work yet: Zero-traffic chicken-and-egg problem. SEO takes months. llms.txt adoption is still early.

Check It Out

If you are building AI agent tools or want to discover what exists, check out tutuoai.com.

Drop a comment if you have questions about the architecture!

I Built a $1 AI Agent Tools Marketplace with Zero Backend — Here's the Architecture

Aline Mercer — Wed, 04 Mar 2026 07:18:50 +0000

The Discovery Problem

AI agents are only as good as the tools they can access. But right n