Reyhan Merekar

ai, startups, productivity
founding fde

[Reyhan Merekar @reyhanmerekar]

GPT-Live and voice mode in Codex is the real deal.

I can’t believe I’m saying this (no grift) but this is the closest thing I’ve seen to AGI given the application, operational, and model layers all converging.

Voice Mode enables you to only “talk” with GPT using your voice and natural language, and you can literally let your imagination run wild with this if your context is set up correctly.

Some great ideas for this, just to name a few:

- Having a readout of your morning brief, including email, important calendar events, newsletter and X summaries
- Deep in thought and reverse prompting, if you’re ideating on strategy
- Yapping to make content - you can come in here, talk about ideas, refine them, then load them into a workspace like Notion.
- Ideating on full fledged features, test and validation plans, and then talking through implementation to ultimately raise a PR
- Browser use - filling out forms, doomscrolling, curating b-roll

It is literally endless… check out how I ideate on and repurpose content👇

[Reyhan Merekar @reyhanmerekar]

Building a product before distribution is stupid and borderline irresponsible.

Here’s what to do instead:

1. Pick one person with one painful problem. "Founders" is a category. "Agency owners who rebuild the same client report every Monday morning" is a person you can go find.

2. Talk to ten of them before you write a single prompt. Ask about the last time the problem happened and what they did about it, and skip "would you use this?" People are polite about hypotheticals and very honest about their calendars.

3. Start distribution before the product exists. Post about the problem in public and put up a landing page with a waitlist or a pre-order button. If you can't get 50 people to raise their hand for free, a Stripe link won't change their minds.

4. Deliver the outcome by hand for the first few people. A spreadsheet and a duct-taped prompt are plenty, and you'll learn which half of your feature list nobody needed.

5. Then build, and let AI do it in a weekend, because now you know what to build and who's waiting for it (the fun part).

[Reyhan Merekar @reyhanmerekar]

@abulhasanx Facts

[Reyhan Merekar @reyhanmerekar]

Incredible FDE alpha >>>

If you are an FDE, you need to be at the cutting edge of AI but also process. Think about how to scale yourself while automating everything possible. https://t.co/E9L9RzpJnF

[Reyhan Merekar @reyhanmerekar]

P.S.: I write about cool stuff like this every Saturday in my newsletter, One Stack.

Check it out!:

https://t.co/ZgQWmjvoFw

[Reyhan Merekar @reyhanmerekar]

Every company has access to the same AI models right now, and where the money shows up still depends almost entirely on what kind of company you are.

I spent years doing transformation work at Accenture, and since August I've been a founding FDE at a startup. Having sat on both sides, what stands out most is how badly AI advice travels. A tactic that's obvious at an SF startup sounds unhinged inside a bank, and the bank's approach would put a six-person startup to sleep.

So here's how I think about where the alpha sits for each.

1. Small business: AI-powered delivery.

A plumbing company, an accounting firm or a local agency doesn't need to reinvent itself. The edge is delivering the work it already sells faster and better, with the team it already has. The quote that used to take two days goes out the same afternoon, and the follow-up no longer depends on the owner remembering it at 11pm. It's a capacity play, where the same people can take on more clients.

2. Enterprise: adoption, just slower.

Big companies will get there. They have the data, the customers and the budget, and they also have procurement, security review, legal and a steering committee for the steering committee. The alpha goes to whoever can push one real workflow through all of that and into production, with a named person who owns the result. Ten pilots with no owner mostly produce ten slide decks. Slower adoption also keeps the gap between what's possible and what's deployed open for a while, and that gap is where FDEs and good consultants come through.

3. SF startups: total reinvention.

Nobody here is adding AI to an existing company. They're designing the company around it from day one. Before hiring for a role, the first question is whether an agent can own that work, so the org chart looks different and a small team can ship like a much bigger one. The catch is that every startup down the street has the same tools, so speed on its own stops being an edge quickly. The ones that last pair the new org design with something harder to copy, like distribution or deep knowledge of one industry.

Which of the three are you in, and where have you found the edge so far?

[Reyhan Merekar @reyhanmerekar]

I asked Claude "If you were 25 and technical today, what skills would you build that compound as models get smarter?"

Pretty good answer here to be fair:

[Reyhan Merekar @reyhanmerekar]

I've consulted for dozens of Fortune 500 companies, and the thing blocking their AI transformation is usually not the AI.

It's the process that lives in one person's head. The admin task that waits three days because only a manager can grant access.

A few patterns:

1. Critical processes depend on one person. If a workflow stops when its unofficial owner is on vacation, that's a business risk and a useful place to start documenting how the work gets done.

2. The process exists in someone's memory, not in a usable document. A flowchart from 2019 that nobody trusts doesn't count as process documentation either.

3. Small admin tasks wait on a superior. Access, approvals, and handoffs turn simple work into a queue.

4. People have access to the system but not the right permissions. The tool is technically available; the work still stops at “request access” and waits.

5. Nobody knows who owns the next step. Requests bounce between teams because each handoff assumes someone else is responsible.

6. Exceptions are handled through side conversations. The standard process is written down, but the real work lives in messages, favors, and “ask Maria, she knows.”

7. The same information gets typed into several systems. Teams spend time copying data because the tools don't share it, or nobody has mapped which system should be authoritative.

8. Approval rules are broader than the risk requires. A low-risk change can wait in the same queue as a consequential one because the process doesn't distinguish them.

9. A broad horizontal AI rollout comes before the work is understood. Centralized access can be an inexpensive first step, but people still need examples tied to their roles. Otherwise, the license is deployed and the capability isn't.

10. People are expected to invent their own use cases. “Go use AI” is not enablement. Teams need a few examples connected to their daily work and a safe place to try them.

11. Fear of solution sprawl can freeze useful experiments. Governance matters. So does giving teams a clear way to test tools, review risk, and decide what should become standard.

12. Security and governance get treated as blockers, even though AI can help with parts of that work too. Repetitive checks and documentation may be candidates for automation, with people who understand the risks still making the decisions.

13. Success criteria was historically flimsy. If the goal is just “use AI,” it's hard to decide whether a workflow improved or whether the team got another tool to maintain.

14. People are surprised when AI can help with PowerPoint or Excel. Many have only seen email drafts, so the deployment reality gap is partly a gap in what anyone has shown them.

What else would you add here?

[Reyhan Merekar @reyhanmerekar]

Everyone's (rightfully) hyping the forward-deployed engineer.

I've done versions of this job for YEARS, and the difference from consulting is one word: ownership.

Consulting taught me to get close to a problem, build alongside the people doing the work, and explain what the work changes for clients. An FDE does those same things, then stays involved to own the outcome.

Here are four parts of the job that get more demanding:

1. Technical depth. You need to build and debug the thing, not just recommend what someone else should build.
2. An AI-native instinct to rethink the process. If a workflow is held together with patches, AI gives you a reason to redesign it instead of adding one more patch.
3. Comfort with the people using it. You need to hear what breaks, explain tradeoffs, and adjust the system while it's in use. A ticket queue won't tell you the whole story.
4. A working grasp of ROI. A demo shows that one version can work. You still need to check whether the workflow saves time, reduces errors, or creates enough value to justify the build.

Be sure to save this, and repost to help another FDE! 👇

[Reyhan Merekar @reyhanmerekar]

Overheard on the bus this morning:

“You know, I went to go reply to my email, and sitting there in the reply field was a PRE-DRAFTED REPLY. I was mind-blown, it sounded just like me and addressed every point of the email as if it were me.”

To us, this is such a trivial feature and this guy doesn’t even know the possibilities.

We. Are. Still. So. Early.

[Reyhan Merekar @reyhanmerekar]

Stop producing slop, I'm begging. Start honing your design skills by building the system 👇 https://t.co/bSrIfFIlkH

[Reyhan Merekar @reyhanmerekar]

Most engineering leaders are still running an outdated code review process.

That math is already broken for any team running agentic coding tools at real volume. The constraint stopped being “can we write the code” and became “can we review it fast enough to actually ship quality features.”

Most teams haven't noticed yet, because most teams haven't turned the throughput up far enough to feel it.

Think about what your current review process assumes: a human wrote this, a human has context on why, and one or two reviewers can reasonably get through the queue by end of day.

None of that holds once a single engineer is shipping 10-15x what they used to. The review that used to be a thoughtful fifteen-minute read becomes a rubber stamp, because nobody built a process for reading that much, that fast.

Here's where I'd start:

1. Pick one unified harness. Give the team one agentic setup, the loop, the tools, the context management, the guardrails. Track the before and after - how long a feature used to take, how long it takes now, and what that extra throughput is actually worth to the business.

2. Redesign the review tiers before you scale usage up. Decide now which categories of change can ship with lighter review, config, dependency bumps, low-risk UI, and which need more scrutiny than they used to get, anything touching auth, billing, or customer data.

3. Shadow one real workflow before you touch the whole team. Pick something that runs weekly and produces a concrete output. Run it alongside a person for two weeks and compare every result.

4. Write the guardrails down - what can the agent touch without asking? What needs a yes from a person first?

5. Change what you measure and who gets promoted. If the harness is doing more of the typing, keep rewarding lines of code or PR count and you're training your best people to look busy instead of to review well and make good calls. Reward judgement and taste.

If your review process hasn't changed in the last six months, it's already behind, and now is the time to embrace change.

[Reyhan Merekar @reyhanmerekar]

On the next episode of everyone is building the same thing:

Anthropic just launched Claude Duet, its answer to Grok Bot, Meta Muse, and ChatGPT Dots.

All four landed on roughly the same architecture:

- An agent that remembers how you work
- Its own cloud computer and browser
- Access to your email, calendar, files, and apps
- Background work, proactive updates, and approval before it acts

But the fact this is powered by Opus 5.5…

[Claude @claudeai]

We’re opening a research preview of Claude Duet, a new app where Claude works as a proactive agent.

It comes to you with what needs your attention, completes tasks you ask of it, keeps working when you step away, and checks with you before it acts on your behalf.

[Reyhan Merekar @reyhanmerekar]

Visualize and learn literally anything with this guide. Think:

- Lego sets
- Turbine decomposition
- Rendering final products from instruction manuals

..and much more https://t.co/MZ6wUajm0E

[Reyhan Merekar @reyhanmerekar]

4 things to automate this week and never think about again:

1. Reading email/inbox scans
2. Doomscrolling social media
3. Meeting notes to action items
4. Calendar time blocking

Never look back!

[Reyhan Merekar @reyhanmerekar]

Anthropic just went from 2,500 to 30,000 code merges a day. In four months...

→ May 2026: ~2,500 merged code changes per day
→ September 2026: 30,000+ per day, a 12x jump, confirmed on Anthropic's own engineering blog
→ Do the math: divide by their ~1,100 engineers and that's roughly 25 merged changes per engineer, per day
→ At that volume, git itself became the bottleneck, so they built their own version control system (Scion) and migrated their entire monorepo off git in 5 months with a 7-person team
→ CI alone got back 25% of its compute capacity after the move

Software engineering is moving down a layer, from "can you write the code" to "can you review and route 25 changes a day without missing the one that breaks something."

[Anthropic @AnthropicAI]

New on our Engineering blog: Creating in-house source control.

In May, we merged around 2,500 code changes per day. In September, we merged more than 30,000 per day. As a result, we became bottlenecked by developer infrastructure built for human (rather than agent) scale.

Here, we share how we built a new version control system—and fully migrated our monorepo from git—in five months: https://t.co/wzNkwHs7IN

[Reyhan Merekar @reyhanmerekar]

made with this exact workflow btw:

[Reyhan Merekar @reyhanmerekar]

Opus 5.5 extra high people... video editing is solved https://t.co/KZRe1sMRim

[Reyhan Merekar @reyhanmerekar]

@Kizuno18 Pretty cool!

[Reyhan Merekar @reyhanmerekar]

Opus 5.5 extra high people... video editing is solved https://t.co/KZRe1sMRim

[Reyhan Merekar @reyhanmerekar]

I spent three days at AI Engineer New York with the people building production AI inside banks, hedge funds, and the labs themselves, Anthropic, OpenAI, BlackRock, Two Sigma, Bridgewater, JPMorgan all in the building.

My observations:

1. Ramp's biggest mistake, as they put it on stage, was building agents for processes they didn't actually understand yet. The fix wasn't more AI, it was going back and splitting the job into discrete tasks first, reconciliation, data entry, variance, accruals, before automating any of it.

2. Evals are basically backtesting now. Synthetic "worlds" with full data: task, world, trajectory, score. One team, Samaya, blocks any data from after the prediction date specifically so the eval can't cheat by seeing the future. Simple idea, most teams don't do it.

3. A single eval score is basically a lie. The best teams are mixing accuracy with partial credit, pass@k for anything high-stakes, LLM judges, regex checks, golden sets, human labels, all of it. Three pillars kept coming up: automated checks, human review, adversarial testing.

4. Production failures are supposed to feed the eval suite, not just get patched and forgotten. Observe, reproduce, find the break, add it back into the evals. Someone mentioned a "better" model update that silently stopped setting reminders, and nobody caught it because they weren't rerunning regressions. If your eval suite ever hits 100%, that's not a win, it might mean the eval is too easy.

5. Stop trusting the model's word for anything, verify with records instead. The highest-impact first step most teams skip entirely: build a custom verifier CLI for each app you're automating. An agent that can prove its own work changes what's actually possible.

6. Defensibility matters most the second real money or real decisions are on the line. Authorize per object and per time, never let an agent quietly overwrite a row a human already reviewed. One team found a 97% eval score was hiding 4 bad answers and 12 real misses, which tells you how little a single number actually proves.

7. Human escalation has to be designed on purpose, not bolted on. Escalate on overwrites, disagreeing runs, failed provenance checks, nothing else. Too many alerts and your team starts rubber-stamping everything, which defeats the whole point. The ratio most teams seem to be aiming for is roughly 80% agent, 20% human.

8. Multiple agents only earn their keep when the work actually splits into independent pieces. Chained steps just add cost and latency. A single agent left alone on a big job tends to stop early and grade itself kindly, which is a worse failure mode than people expect.

9. Harnesses are changing, not dying, which surprised me. Models have absorbed most of the coding scaffolding already, harness choice barely moves the needle on SWE-Bench anymore. What still works is pruning skills and writing memory after each task.

10. The juiciest of all - the real bottleneck in AI-written code is the merge queue. Agents can write code faster than any team of humans can review it. The fix isn't slowing the agents down, it's better verifiers, receipts on every PR, and CI actually built for parallel-safe branching.

Great time @swyx !!

[Reyhan Merekar @reyhanmerekar]

@HHaandr brother reminded me of