DEV Community: akshay sharma

Your coding agent can now write the launch post for the feature it just helped you ship

akshay sharma — Thu, 03 Sep 2026 11:00:07 +0000

I ship a feature, and then I don't tell anyone about it.

Not out of laziness. The context switch is the problem. I'm deep in a branch, the thing works, and announcing it means leaving the terminal, opening a doc, re-explaining my product to a chat window that has never heard of it, rewriting the result for three platforms, and finding a scheduler. By the time I've done that I've lost the thread I was on, so I don't do it, and the feature ships in silence.

So we built an MCP server for it. Claude Code already knows what I just built — it helped me build it. It should be able to write the post too.

> write a LinkedIn and X post about the feature I just shipped, then schedule both for Tuesday morning
That's the whole interaction now. It stays in the session I'm already in.

What's actually behind it

The server is the MCP surface for Cadencz, which is a social workspace for founders. The important part for this post is not the app, it's the thing the app has that a raw model doesn't: a Website Brain.

You point it at your URL once. It reads your positioning, your audience, the proof points you actually have, and how you already write. That gets stored. Every draft afterwards starts from your real product rather than from a prompt where you've re-typed "we're a B2B SaaS that helps teams..." for the fortieth time.

That's the difference between an AI that writes posts and an AI that knows what you built. It's most of why AI social content reads like it could belong to anyone — the model has a memory of your prompt, not of your product.

Eight agents work off that same stored context. One reads the site, one works out the brand, one writes your voice guide, one plans, one drafts, and one exists purely to reject weak drafts before a human sees them. That last one produces nothing and improved the output more than any of the others.

The tool surface

Sixteen tools, over streamable HTTP. Eight of them read:

Tool What it does
list_workspaces The workspaces this token can see list_channels Connected accounts and whether the plan covers them list_brains The Website Brains in this workspace query_brain Retrieve product context for a question get_current_plan The current weekly content plan and its items get_plan_usage Allowance usage against the plan's caps list_scheduled_posts Posts committed to publish in the coming days get_analytics Engagement totals per platform over a window

Six of them write:

Tool What it does
compose_post One platform-native post from an idea, grounded in the Brain plan_week Runs Plan My Week across the whole content calendar schedule_post Commits a draft to a time cancel_scheduled_post Pulls a scheduled post back to draft approve_plan_item Approves a plan item into a scheduled post publish_now Queues for immediate delivery

Two are owner-only and don't even appear in tools/list for a token that can't use them: connect_channel_link and get_subscription.

compose_post writes for the target platform rather than producing one blob you paste everywhere. LinkedIn and X have never rewarded the same shape, and cross-posting one paragraph is the fastest way to be ignored on both.

Connecting it
bash claude mcp add --transport http cadencz https://api.cadencz.com/mcp \ --header "Authorization: Bearer cdz_mcp_..."

Any client that sends a static Authorization header works the same way — Claude Code, Claude Desktop, Codex CLI, Cursor. It's also listed in the official MCP registry as com.cadencz/cadencz, so anything that reads from there can find it.

Tokens are minted at Settings → MCP by an account owner. The raw string is shown exactly once; the backend stores only its sha256, so there's nothing to re-reveal and no support path that hands it back to you.

The security model, because you're going to ask

A token that can drive your social accounts is a serious thing to hand to an agent, so three properties matter.

A token acts as the person who minted it, role included. A scheduler's token can compose, schedule and approve. It cannot connect platforms or see billing — those tools don't appear in its tools/list at all, rather than appearing and then failing.

The plan gate runs per request, not at mint time. Downgrade below Pro and every existing token stops working on the next call. Remove a member and their tokens die with the seat check.

The tools that move money don't exist. No checkout, no cancel, no billing portal, nothing that mints credentials. A leaked token must not be able to buy or cancel a plan, and the way to guarantee that is to never build the tool.

connect_channel_link returns a URL where a human connects a platform. It never accepts credentials.

publish_now requires confirm: true as a separate argument. Publishing is irreversible, so it takes a second deliberate decision rather than one that can be inferred from an ambiguous instruction.

And underneath all of it: nothing publishes without human approval, and there's no setting to turn that off. We built the toggle, looked at it, deleted it. Plenty of tools will post autonomously. A founder's voice is the whole asset in the first two years, and handing it to an autopilot to save twenty minutes a week is how everyone ends up sounding identical.

Refusals are structured

A refused call comes back as something the model can act on rather than a wall of prose:

json { "code": "plan_allowance_exceeded", "message": "...", "allowance": "AI generation", "limit": 400, "used": 400 }

The codes mirror the app's own 402/403 surface — plan_allowance_exceeded, plan_required, plan_feature_not_included, platform_post_limit_reached, schedule_window, seat_paused, feature_disabled. Every tool resolves the token to the same actor the HTTP API uses and calls the same services, so allowances and quotas fire identically whether the request came from a browser or an agent. There's no second code path to drift.

Things it deliberately doesn't do

It won't post without you. It won't touch billing. It won't take a platform credential. It won't invent a metric to make a post punchier — the Brain rejects claims it can't ground in your actual site, which is the single feature I'd keep if I had to drop the rest.

Try it

Free plan, no card: cadencz.com. MCP is included from Pro.

If you're running an MCP server of your own and want the publishing gotchas — the apex DNS record, the LibreSSL thing, why your auth wall makes you invisible to directories — I wrote those up separately. They cost me a day.

A question for anyone who has moved from momentum posting to a fixed cap.

akshay sharma — Thu, 03 Sep 2026 10:15:26 +0000

A question for anyone who has moved from momentum posting to a fixed cap.

Momentum posting sounds fine in theory. Post when you have something good, skip when you don't.

In practice it means strong weeks and filler weeks, decided by mood rather than a plan.

So the alternative is a hard cap. Four posts a week, no more, regardless of how many ideas are sitting in the drafts folder.

The theory is that a cap forces sharper editing. You have four slots, so only the four strongest ideas survive, and everything else waits or dies.

The counter-theory is that a cap just cuts good ideas early, before they had time to become the strongest version of themselves.

Both can be true depending on the week. That's what makes this worth asking instead of assuming.

If you've tried a fixed weekly cap, what actually changed in your editing process? Did you cut faster, or did you just cut differently?

A scheduler has exactly one job: publish the post at the time you chose. Everything else is decoration on top of that job.

akshay sharma — Wed, 02 Sep 2026 10:15:36 +0000

A scheduler has exactly one job: publish the post at the time you chose. Everything else is decoration on top of that job.

Most comparison posts treat reliability as a bullet point. "Reliable uptime" sits next to "AI captions" and "hashtag suggestions" like they're the same category of feature. They're not. If the AI captions are mediocre, you edit them and move on. If the tool silently fails to publish, you lose the post, the timing, and the trust that made you schedule anything in advance.

Silent failure is the part worth naming. A tool that fails loudly, with a clear error and a retry, is annoying but survivable. A tool that shows a green checkmark while the post never reaches the platform has failed at its only job without telling you. You find out when a client asks why nothing went up, or when three days pass and the feed is empty.

This is why reliability can't be a feature you add later. It's the foundation the rest of the product sits on. Content suggestions, analytics, team workflows — all of it assumes the base layer works. If publishing is unreliable, better AI suggestions just mean better drafts that don't go anywhere.

When evaluating any scheduling tool, ask a different question than "what features does it have." Ask what happens when a platform API changes, a token expires, or a rate limit hits mid-batch. Does the tool tell you immediately, or does it fail quietly and let you find out on your own?

Build logs and engineering specs for scheduling tools spend real space on OAuth token refresh, webhook delivery guarantees, and retry logic — not because it's exciting to write about, but because that's where the actual product lives. The scheduling UI is the visible ten percent. The failure handling underneath is the other ninety, and it's the part that decides whether you can trust the tool with something time-sensitive.

If a scheduler can't tell you when it fails, it hasn't earned the right to be trusted with your calendar.

Case note: a pattern worth naming.

akshay sharma — Tue, 01 Sep 2026 10:15:51 +0000

Case note: a pattern worth naming.

Someone drafting a post opens a new tab to check yesterday's engagement numbers. They come back thirty seconds later and reread the sentence they left half-finished. It doesn't click anymore. They rewrite it, weaker than before.

Observation: the check itself rarely gives new information. Most metrics move slowly. A post from yesterday looks about the same as it did an hour ago. The interruption cost is real, but the insight gained is close to zero.

What actually happens is a context switch. Drafting uses one kind of attention: generative, forward-moving, focused on the next word. Reviewing metrics uses a different kind: evaluative, backward-looking, focused on what already happened. Switching between the two isn't free. Each switch costs a few minutes of re-orientation, even when the check takes ten seconds.

The lesson is plain: treat analytics review as its own scheduled activity, not something to glance at mid-sentence. Pick a fixed time, once or twice a week, and look at numbers only then. Outside that window, close the tab.

This isn't about discipline for its own sake. It's about matching the tool to the task. A draft needs momentum. A dashboard needs distance. Mixing them doesn't make either one better; it just makes both slower.

If you're building tools for writers, this is worth designing around directly. Keep the drafting surface free of live numbers. Put review somewhere separate, with its own entry point, so checking it is a deliberate choice rather than a habit that happens mid-sentence.

What would you add to this observation?

checkout: https://cadencz.com/

Most founders who are also the marketing department hit the same wall. You can write three great posts while building product on

akshay sharma — Sat, 29 Aug 2026 05:35:27 +0000

Most founders who are also the marketing department hit the same wall. You can write three great posts while building product on a good week. Then launch week swallows everything and distribution goes quiet while the product ships.

The usual fix is an automation tool that posts on a schedule. That solves the quiet but its da problem: it posts without you and very often posts things you would not have approved.

So we built Cadencz to split the difference. It is an AI social media manager where you keep launches, decisions, positioning, and audience in one inspectable source of truth. It turns existing company work into drafts across 9 live channels, and you approve every post before it goes anywhere.

The part that matters most for a solo marketer is the approval queue. Nothing reaches a live channel without your sign-off. The AI agents write, the Critic flags weak angles, and you decide. Automation only happens on the publishing step, after your approval.

The workflow runs on a weekly loop. You set aside planning time, the Planner maps the week, the Writer composes drafts, and you review the queue. Cadencz schedules the approved posts across your live channels and the Analyst reports what worked.

Concretely, that collapses the decision-making into one step instead of seven. No separate week of drafts, no forgotten scheduling, no gap where nothing ships for two weeks because you were heads-down on launch.

Two caveats so this reads straight. First, the 9 channels are the only ones live right now; planned connections are not yet available. Second, this was built to keep distribution steady, not to make posts go viral, and there is no guarantee of reach. The Editor and Critic agents keep quality up, but distribution still depends on what you ship and when.

If you want to see whether a weekly planning loop fits how you work, watch the 30-sec demo. It spends most of its time on the approval queue, which is the part you will actually live in.

checkout : https://cadencz.com/

Open any writer's drafts folder and the count looks alarming. Forty, sixty, sometimes more.

akshay sharma — Thu, 27 Aug 2026 10:39:44 +0000

Open any writer's drafts folder and the count looks alarming. Forty, sixty, sometimes more.

That number tells you almost nothing useful. A folder with 40 drafts usually has 2 worth finishing and 38 that are already dead, they just haven't been deleted yet.

Volume feels like the problem because it's the visible thing. You open the folder, see a wall of files, and think you have a backlog to clear. But most of that backlog isn't a queue, it's a graveyard.

Age is the signal that actually tells you something. A draft you touched yesterday is still alive, you're mid-thought. A draft that's sat untouched for three weeks has already answered the question of whether you're finishing it. You're not. The idea cooled, or the moment passed, or you already said it better somewhere else.

Count treats every draft as equal potential. Age tells you which ones are still in motion and which ones are just taking up space. That distinction matters more than the total, because it's the difference between a backlog and a to-do list.

This came up while working on Cadencz, a writing tool for people who post regularly. Draft count used to be the headline number in the interface, the thing you saw first. It got replaced with draft age instead, because that's what actually predicts whether something gets finished.

You don't need special software to test this yourself. Next time you open your drafts folder, skip the count. Sort by last modified date instead, and look at what's been sitting untouched the longest.

Anything older than two or three weeks is probably not coming back. Delete it, or admit it's done and move on. The goal isn't a smaller number. It's a folder where everything left is actually still alive.

checkout: https://cadencz.com/

A full calendar is not a strategy. It just means every slot has something in it.

akshay sharma — Wed, 26 Aug 2026 09:45:16 +0000

A full calendar is not a strategy. It just means every slot has something in it.

Most tools in this category optimize for the wrong variable. They measure whether a post went out on time, not whether it was worth sending. That's a scheduling problem, and it's mostly solved.

The actual hard problem is upstream of scheduling. It's deciding what's worth saying this week, out of everything you could say. A calendar can't do that for you. It just holds whatever you put in it, good or mediocre.

checkout: https://cadencz.com/

Here's the tell: a founder with 20 scheduled posts and no clear point of view is not ahead of a founder with 3 posts and a sharp one. The first founder has a fuller calendar and a weaker signal. The second one has less content and more attention.

Filling slots is a volume problem. Deciding what deserves a slot is a judgment problem. Most scheduling tools quietly assume the first is the job. It isn't.

If you already know what's worth saying, a scheduler is fine. It's a queue, and queues are useful. But if you're staring at an empty calendar wondering what goes in Tuesday's slot, more scheduling features won't help. You need a way to filter ideas before you need a way to publish them.

That's the gap worth naming. Not "how do I post more consistently," but "how do I know which draft is actually good." Tools that only solve the first question will keep producing full calendars with nothing in them worth reading.

What does your process actually use to decide what's worth sending, versus what's just filling a slot?

Open a folder of old drafts and you'll see a wall of dates.

akshay sharma — Wed, 26 Aug 2026 09:44:18 +0000

Open a folder of old drafts and you'll see a wall of dates. "draft_oct14," "draft_nov02," "idea_3." None of it tells you what's actually inside.

Three weeks after writing something, the date is useless information. You don't remember what happened on October 14th. You'd have to open the file to find out, and if you have forty drafts, that means opening a lot of files.

The fix is simple: name the file after the idea, not the day you wrote it. "why_hooks_matter" tells you exactly what's inside before you click. "draft_oct14" tells you nothing except that you were at your desk that day.

This sounds small, but it changes how you search. Looking for a draft becomes a scan of filenames instead of a re-read of five documents. You're matching against a thought you already have, not reconstructing one from a timestamp.

It also exposes weak drafts faster. If you can't name a file after its idea in under five seconds, the idea probably isn't clear yet either. The naming step doubles as a clarity check before you've written a full post.

One concrete takeaway: go rename your next five drafts. Skip the date, use the one sentence that describes what each draft is actually about. You'll notice which ones don't have a clear sentence yet — that's useful information too.

Check out: https://cadencz.com/

I cut my coding agent's token usage 61% by giving it a code graph

akshay sharma — Wed, 10 Jun 2026 15:27:31 +0000

My coding agent has a goldfish memory. Every session runs the same way: I ask, "Who calls parseToken?" and it opens seven files, reads forty kilobytes, and, half a minute later, tells me something it could have told me on day one if it remembered the shape of my code.

It never remembers. Every conversation starts from zero, so it greps, reads, burns tokens, and every so often invents a function name that was never there.

I got tired of paying for that, so I built GraphPilot. It's a local MCP server that indexes your TypeScript/JavaScript repo once and lets the agent query its structure instead of re-reading files. Here's what I found measuring it.

The actual problem

Coding agents reason well and remember nothing. The structural questions they ask all day ("where is this defined?", "who calls it?", "what breaks if I change it?") have exact answers sitting in the code, but the agent re-derives them from raw text every time, because nothing survives between sessions.

You pay for that three ways. The obvious one is tokens: re-reading files to answer a question you already answered is pure waste. Then there's accuracy, because grep finds the string save without knowing which save you meant, so the agent guesses. And the one that actually worries me is refactor safety. "What does renaming this break?" is the question that matters most, and a file-by-file agent is worst at exactly that question.

GraphPilot fills the gap as persistent structural memory.

How it works

The CLI parses your repo with tree-sitter and builds a graph. Every function, class, method, interface, type, and enum becomes a node; every call becomes an edge. The graph gets written to ~/.graphpilot/, and an MCP server hands it to the agent over stdio.

Four tools:

gp_recall finds where a symbol is defined
gp_callers lists who calls a symbol (the reverse lookup)
gp_impact computes the blast radius of a change, depth-bounded
gp_index re-indexes after edits

Every response carries a file:line @ sha anchor, so the agent can quote its source and you can jump straight to the line. And when a name is ambiguous, say two files both export save, the answer tells you instead of quietly picking one and pretending it was sure.

The numbers

I ran a real coding agent (claude-sonnet-4-5) against fastify, a Node.js framework of about 300 files, on 40 structural questions. First with nothing but file reads. Then with GraphPilot's four tools. Same model, same questions, same repo.

Metric	Without	With GraphPilot
Total tokens	2,796,760	1,088,276
API cost	$8.88	$3.68
Correct answers	33/40	37/40

That's 61% fewer tokens, and it got four more answers right instead of trading accuracy for speed. By question type, "who calls X?" dropped 82% and impact analysis dropped 73%.

Now the part most launch posts skip. It doesn't help everywhere. Flow-tracing questions like "trace a request through the middleware" come out roughly even, because the agent still has to read code to answer them. Plain dependency checks save about 7%. I publish those numbers too. A tool that claims to win at everything is hiding something.

Local-first, and I mean it

GraphPilot never makes a network call. Indexing is tree-sitter running on your machine, and your source never leaves it. There's no telemetry and no update check, and that part is enforced rather than promised: an ESLint rule bans http, fetch, and axios imports in the source, and CI fails any PR that tries to add one. The graph sits in ~/.graphpilot/ at mode 0600.

Try it

npm install -g @graphpilot-oss/graphpilot
graphpilot index ~/code/my-app

Then point your agent's MCP config at graphpilot mcp. It works with Claude Code, Cursor, Cline, Windsurf, and Continue.

It's TypeScript and JavaScript only right now (tree-sitter-typescript handles TS, TSX, JSX, and JS in one grammar). Python is probably next if people ask for it.

It's Apache-2.0, on GitHub at graphpilot-oss/graphpilot. The benchmark is reproducible, script and method in the repo, so if you think I measured it wrong you can check yourself.

One thing I'd actually like to know: what structural questions do you ask your agent most, and which ones am I not measuring yet?