DEV Community: shrey

Steal my prompt to turn Codex into an Orchestration Manager

shrey — Fri, 03 Jul 2026 01:50:14 +0000

The mistake with coding agents is treating them like a single chat window.

You paste a task. The agent writes a patch. You check it. Something is missing. You paste another task. Then another. Then CI fails. Then review comments come in. Then you realize you are still the project manager, the QA loop, the scheduler, and the person remembering what every thread was supposed to do.

The better workflow is to make one Codex thread responsible for orchestration.

Not just the code.

The loop around the code.

You give Codex a defined batch of work and ask it to act as the Orchestration Manager. It breaks the work into threads, gives them goals, checks progress on a heartbeat, watches PRs or handoffs, routes feedback, requires verification, and keeps going until the work is actually complete.

This works for any scoped work.

It can be a bug fix, a refactor, a migration, a documentation cleanup, a test suite repair, a research task, or a backlog of small improvements.

The whole thing starts from one prompt.

The copy-paste prompt

Use this as the starting prompt for the manager thread:

You are the Orchestration Manager for this work.

Your job is to move the work forward until it is actually complete. Do not personally implement everything unless that is the smallest safe path. You are responsible for planning, scheduling, coordination, follow-up, verification, and keeping momentum.

Work scope:
[PASTE PLAN.md, issue list, checklist, bug report, feature list, refactor plan, research brief, or task description here]

Before starting, review the work scope and tell me if anything is unclear, risky, too broad, underspecified, or likely to cause worker threads to collide. If the scope is clear enough, continue. If not, ask the minimum number of questions needed to make it executable.

Responsibilities:
1. Break the work scope into worker-thread tasks that can run independently.
2. Decide which tasks should run now and which should wait.
3. Create or instruct worker threads with clear /goal prompts.
4. Make sure each worker has a narrow scope, a definition of done, and a reporting format.
5. Make sure code changes include tests where practical.
6. Make sure non-code work includes a clear verification step.
7. Make sure workers open PRs, prepare patches, produce artifacts, or deliver handoffs as appropriate.
8. Track worker status, changed files, test results, PR status, CI status, review feedback, and blockers.
9. Create follow-up worker threads when tests fail, review feedback appears, work stalls, artifacts are incomplete, or the implementation does not meet the definition of done.
10. Keep moving until the work is complete, verified, and ready for human review or merge.

Use /goal to keep yourself and the worker threads on track.

Use a heartbeat every 10 minutes.

At every heartbeat:
- check the status of all worker threads
- identify stale or blocked work
- inspect open PRs or current artifacts
- check whether tests, CI, or verification passed
- check whether review feedback needs action
- decide the next action
- create follow-up work if needed

Worker threads should also check in immediately when:
- they open or update a PR
- they produce a draft, patch, report, or artifact
- tests pass or fail
- CI fails
- review feedback is addressed
- they are blocked
- they believe their work is complete

Every worker thread should report back in this format:

Status:
Done / Blocked / Needs review

Summary:
What changed or what was produced in plain English.

Files or artifacts changed:
- ...

Verification:
- command, check, review step, or result

PR or handoff:
- link, artifact path, or not created yet

Open issues:
- none, or list blockers

Recommended next action:
- merge
- review
- create follow-up thread
- wait for another thread
- manual test needed
- publish artifact
- stop

Rules:
- Keep worker scopes small.
- Avoid assigning two workers to edit the same files unless there is a clear reason.
- Do not mark work complete just because something was written.
- Work is complete only when the definition of done is met and verification has passed.
- If UI behavior is involved, require manual testing or a clear test plan before calling it done.
- If research or writing is involved, require source review and a final editorial pass before calling it done.
- If a worker thread becomes unresponsive, start a replacement thread and preserve the current state.
- If you are unsure whether the next step is safe, pause and ask.

Start by producing:
1. The proposed worker-thread schedule
2. The /goal prompt for each worker
3. The heartbeat plan
4. The verification plan
5. The first action you will take

That is the workflow.

One prompt turns a Codex thread into the Orchestration Manager for a piece of work.

Why this works

Most agent workflows break at the handoff points.

The first output might be decent. The problem is everything around the output:

Did the agent run tests?
Did it verify the result?
Did it open a PR?
Did CI pass?
Did review comments come in?
Did a worker get stuck?
Did two agents edit the same file?
Did anyone follow up after the first attempt failed?

That is where the human usually gets dragged back in.

The Orchestration Manager prompt moves those handoff points into the agent's job description.

The manager thread is not there to be clever. It is there to keep state and keep pushing.

The mental model

Think of the system as three layers.

Human
-> defines the work and reviews judgment calls

Orchestration Manager
-> schedules work, checks progress, tracks handoffs, starts follow-ups

Worker threads
-> execute narrow tasks in their own context or worktree

The human still owns taste, judgment, and final approval.

The manager owns momentum.

The workers own execution.

That separation matters because coding agents get worse when one thread has to be planner, implementer, reviewer, tester, project manager, and memory all at once.

A manager thread should stay at the work-loop level. A worker thread should stay at the task level.

The work scope has to be real

This workflow works best when the work is already defined.

Bad input:

Make the app better.

Better input:

Work scope:
1. Replace the legacy billing webhook handler with the new event router
2. Add tests for invoice.paid, invoice.failed, subscription.updated, and subscription.deleted
3. Backfill missing webhook fixtures
4. Update the deployment runbook with the new rollback steps
5. Open a PR with the migration, tests, risks, and verification notes
6. Address review comments until the PR is ready to merge

That scope is specific enough for an Orchestration Manager to split into useful worker threads:

Worker 1: event router implementation
Worker 2: webhook fixture backfill
Worker 3: test coverage
Worker 4: runbook update
Worker 5: PR review follow-up

The manager can help refine a plan, but it cannot read your mind.

If you give it vague work, it will create vague workers. If you give it crisp work, it can schedule useful threads.

The worker goal matters

The worker prompt should not be a feature request.

It should be a finish line.

Weak:

Fix the billing webhook code.

Better:

/goal Replace the legacy billing webhook handler with the new event router. Keep changes limited to webhook routing, billing event handlers, and directly related tests. Preserve existing behavior for invoice.paid, invoice.failed, subscription.updated, and subscription.deleted. Add or update tests proving the migrated paths work. Report changed files, test results, blockers, and recommended next action. Stop only when the implementation is PR-ready or you are blocked.

That one prompt gives the worker a role, scope, test expectation, handoff format, and stop condition.

The manager can generate these goals automatically, but the goal shape should stay this explicit.

Heartbeats are the safety net

The heartbeat is what makes this feel different from a normal chat.

Every 10 minutes, the manager checks the system:

What is active?
What is blocked?
What changed?
Which PRs or artifacts exist?
Did tests pass?
Did CI fail?
Did review feedback appear?
What needs a follow-up worker?

The heartbeat should not be the only way information moves.

Workers should check in immediately when they hit a milestone. A heartbeat catches stale work. Worker check-ins keep the loop responsive.

Use both.

Feedback is part of the workflow

A lot of agent workflows stop at "PR opened" or "draft produced."

That is too early.

The Orchestration Manager should treat feedback as new work.

If review comments appear, the manager should classify them:

bug
style
test request
architecture concern
documentation request
unclear feedback

Then it should either assign all comments to one worker or split them across follow-up workers.

Example follow-up goal:

/goal Address the unresolved review comments related to the billing event router. Only modify files needed for those comments. Add or update tests if behavior changes. Run the relevant test suite. Report which comments were resolved, changed files, test results, and whether any review feedback remains. Stop only when these comments are resolved or blocked.

This is where the workflow becomes useful.

The first pass is rarely the final pass. The manager exists to keep the second and third passes from being forgotten.

Checks and balances

Do not confuse this with fully trusting the agent.

The manager thread can stall. Worker threads can hallucinate completion. Heartbeats can keep a bad loop alive. UI changes can look correct in code and still feel wrong in the app. Research can sound complete while missing the primary source.

So the prompt should force checks:

Code changes need tests where practical.
PRs need review.
CI status matters.
UI work needs manual testing or a clear test plan.
Research work needs source review.
Writing work needs an editorial pass.
Unresponsive threads should be replaced.
The manager should pause when the next step is unsafe.

The point is not to remove human judgment.

The point is to remove human babysitting.

The reusable pattern

The pattern is simple:

Define the work.
Start an Orchestration Manager Codex thread.
Ask it to schedule worker threads.
Use /goal for every worker.
Run a 10 minute heartbeat.
Require verification, tests, review, or artifacts depending on the work.
Spawn follow-up workers when anything fails.
Repeat until the work is complete.

That is a better default than one giant prompt.

A single agent gives you an attempt.

An Orchestration Manager gives you an operating loop.

The human still decides what matters.

The agent keeps the work moving.

Telegram is becoming my control plane for vibe coding

shrey — Thu, 02 Jul 2026 05:39:43 +0000

The IDE is where code changes. Telegram is where the loops run.

Telegram is becoming the control plane for vibe coding.

The IDE is where code changes. Telegram is where the loops run.

I know that sounds a little ridiculous. Coding is supposed to happen in an editor. You open Cursor, talk to the agent, review the diff, run the tests, and keep going until the thing works.

That was my workflow for a while too.

But after using coding agents every day, the split became hard to ignore. The place where code changes and the place where agents are managed do not need to be the same place.

The IDE still matters. Cursor matters. Claude Code matters. Codex matters. I still use all of them. But when agents start doing more of the work, I do not want to live inside the surface where the code is being edited. I want to manage the loop.

That is where Telegram started making more sense than I expected.

My coding interface kept changing

I have been vibe coding for about 6 years now.

I started with GPT-2 inside TabNine. Then GitHub Copilot brought GPT-3 into the editor. Then ChatGPT made coding conversational. Then Cursor moved the AI directly into the IDE. Then Composer made multi-file changes feel normal.

After that, the stack got strange. Claude Code, Codex, Cursor agents, cloud agents, loops, OpenClaw, Hermes, cron jobs, review agents, and software factories all became part of the workflow.

Each interface solved a different problem. Copilot made autocomplete useful. ChatGPT made coding conversational. Cursor made AI feel native inside the IDE. Composer made multi-file edits feel normal. Claude Code and Codex made agent execution feel real.

Hermes solved a different layer for me. It became the personal orchestrator above the coding tools, the thing I could teach, redirect, schedule, and use to coordinate other agents.

Telegram then became the interface I could actually live inside while managing that orchestrator from my phone.

That last part changed more than I expected.

The laptop assumption is still everywhere

Most AI coding tools still quietly assume the human is sitting in front of a coding interface.

That is true even when the agent is doing the work somewhere else, the tests are running on another machine, the branch was created by a background process, another agent is reviewing the output, and the only thing I need to do is approve, reject, or redirect a pull request.

The assumption is still simple: the human is at the desk.

That starts to feel wrong once you use agents seriously.

If an agent can create the branch, write the code, run the tests, inspect the failure, trigger review, and loop on fixes, why am I still forced to manage the system from a laptop?

That question pushed me toward Telegram.

Not because Telegram is a coding app.

Because Telegram gives me mobile context management for coding agents.

Telegram solves context for me too

People talk a lot about context management for agents.

They should. It matters.

But there is another context problem that gets less attention: the human's context.

When you are working across multiple projects, agents, repos, branches, terminals, cloud workers, and review loops, your own memory becomes the bottleneck. You forget which terminal had the important log. You forget which agent was working on which repo. You forget which thread had the decision. You forget whether the bug is still being investigated, already fixed, or waiting on your approval.

A good agent interface should help the model remember. A great one should help the human remember too.

Telegram does this weirdly well.

Folders become project areas. Groups become projects. Supergroups become workspaces. Topics become features, bugs, and experiments. Threads become isolated context. Agents report into the right place.

The whole system becomes glanceable from a phone.

That is the part I care about most. Mobile is not a convenience layer here. Mobile changes the workflow.

I can be away from my laptop and still understand what is happening. I can make judgment calls without reopening an IDE. I can keep work moving without remembering which machine, tab, terminal, branch, or chat window had the state.

The thread is the workspace. The group is the project. The phone is the control plane.

Hermes is the layer that makes this work

Telegram alone is not the system.

Telegram is the interface. Hermes is the orchestrator.

I use Hermes as my personal agent. I can teach it how I work, how I want projects managed, how to run loops, how to use cron jobs, how to route work to other agents, and when to escalate back to me.

The pattern usually looks like this:

I give direction in Telegram.
Hermes turns that direction into a loop.
Cron keeps the loop alive.
Poly agents coordinate the work.
Codex, Claude Code, Cursor, and other agents execute pieces of the task.
Review agents inspect the output.
The loop keeps going until the result is usable.
I get pulled in only when judgment is needed.

That creates a very different relationship with coding.

The old workflow was simple and exhausting: the human drives every step, reviews every line, catches every mistake, and keeps all the project state in their head.

The new workflow is closer to this: the human defines the goal, sets the boundaries, decides what good looks like, and reviews exceptions. The system does the execution work.

That is why I keep coming back to the word harness.

The best AI coding setup is not the smartest single agent. It is the harness around the agents.

The real skill is removing yourself from the loop

The skill required to work with AI agents is changing.

When the models were weaker, the skill was staying in the loop. You had to review every line because the models were brittle. You had to drive every step because the agents lost the plot. You had to catch every mistake because there was no reliable review loop behind them.

That is still true in some workflows.

But with the current models and current agent capabilities, the human often does not need to be inside every loop.

The agent can write the code, run the test, inspect the failure, ask another agent to review it, open the pull request, and try again when the review fails.

So the question changes.

It is no longer only: how do I prompt better?

It becomes: where am I still blocking the system for no good reason?

That question is uncomfortable.

Because removing yourself from the loop does not mean being careless. It means building a system that can operate without you babysitting every step.

That takes real engineering. You need clear goals, context boundaries, review paths, escalation rules, memory from past mistakes, and a way for agents to report progress without dumping noise everywhere.

You also need a way for the human to re-enter the loop at the right moment, not every moment.

Telegram works well for me because it gives that system a place to live.

Why this feels like a mobile ADE

We already have IDEs: Integrated Development Environments.

They were built around a developer writing, editing, navigating, debugging, and compiling code directly. That still matters.

But agent development needs another kind of environment.

An ADE.

Agent Development Environment.

Not just a place where code changes. A place where agent loops are managed.

On desktop, that might be a terminal, an IDE sidebar, a cloud dashboard, or a coding agent interface. On mobile, Telegram is the best version I have found so far.

It already has the primitives I need: project folders, persistent groups, topic based threads, notification control, search, media, files, voice messages, bots, human escalation, and multi-agent reporting.

None of those were designed specifically for coding agents. Put together, they form a surprisingly good mobile environment for managing them.

That is why Telegram feels less like a chat app in my workflow and more like a control plane.

The IDE is where the code changes. Telegram is where the loops run.

What people miss about this

The obvious reaction is: why not just use the agent UI?

Cursor has a UI. Codex has a UI. Claude Code has a terminal. Cloud agents have dashboards. Some of them even have mobile apps now.

I have tested that path.

The mobile apps help, but they still feel like thinner versions of the same agent product. You are usually inside one tool, one agent, one execution surface, or one task thread.

That is useful. It is not the same thing as managing the system above the agents.

My workflow is not one agent.

It is agents managing agents.

Hermes creates loops. Cron keeps those loops alive. Poly agents route work. Codex, Claude Code, Cursor, and other tools do execution. Review agents close the loop.

I step in when my judgment is needed.

A single-agent UI is not enough for that. A mobile app for one coding agent is still mostly a remote control for that one coding agent.

Hermes plus Telegram feels different because it gives me the layer above the agents.

Telegram gives agents clean context. It gives me clean context. It gives me groups, topics, files, voice, search, notifications, and now even streaming messages from agents in the same mobile surface I already use all day.

That is the UX difference for me.

It is not just mobile access to an agent. It is mobile context management for a whole agent system.

And maybe most importantly, it pushes me to think about software work as a system of loops instead of a sequence of prompts.

Where I think this is going

I think more AI coding work is going to move in this direction.

Not everyone will use Telegram. That is not the point.

The point is that the next important interface might not look like an IDE. It might look like a control plane: a place where the human defines goals, checks progress, approves exceptions, and manages agent loops from anywhere.

The IDE will still matter. The code has to change somewhere.

But the center of gravity is moving.

For me, it moved from writing code in an editor to managing loops from my phone. That changed how I think about AI coding as a skill.

The best setup is not the smartest model, the flashiest IDE, or the agent that writes the most code.

The best setup is the harness around the agents: the memory, the review loop, the escalation path, the context boundary, and the interface that lets the human stay free without losing control.

For me, right now, that interface is Telegram.

The agent that fixes bugs by running the code

shrey — Mon, 08 Jun 2026 09:13:08 +0000

I want to tell you about the first time I watched a coding agent fix a bug correctly on the first try.

It wasn't the model. The model was the same one I'd been using for months. It was the loop around the model that had changed.

The agent didn't open three files, skim them, write a confident theory in its head, and edit something that "looked like" the cause. That was the old loop. The one where you run the code, see the same bug, and watch the agent shrug and try another file.

This time the agent did something different. It listed five hypotheses. Picked one. Added some logging. Then it stopped and asked me to reproduce the failure. I clicked the button. The bug fired. The agent read the logs, confirmed the hypothesis, wrote a two-line fix, and pulled its logging back out.

The whole thing took maybe four minutes.

This is the difference between an agent that guesses from source code and an agent that gets evidence from runtime. And it is the difference between the kind of AI-assisted coding most people are doing today and the kind that actually ships.

There's a name forming for the discipline behind this. Martin Fowler's site, in an article by Birgitta Böckeler from earlier this year, uses the term that's been quietly circulating in the agent community for the last few months: harness engineering.

The premise is simple. An agent is a model plus a harness. The model is the language model itself. The harness is everything else. Tools, prompts, feedback loops, error handling, retries, the scaffold of code that decides what the model sees and when it gets to act.

For a long time the conversation in AI coding has been about the model. Bigger model. Smarter model. Newer model. Different provider. Different prompt. Different system message. People have been tuning the inside of the box.

The harness is the box itself. And it turns out that the box is doing more work than anyone wanted to admit.

Watch any agent debug

If you have used any AI coding tool, including the most popular ones, here is the loop you have probably seen.

You give the agent a bug. It opens a handful of files. It reads them. It writes a theory in its head about what's wrong. It edits a line that resembles the kind of code that would cause this kind of bug. It tells you the fix is in. You run the failing scenario. The bug fires again. The agent says "let me look at another file" and the cycle repeats.

Sometimes it gets there. Often it doesn't. And the failures have a particular flavor. They are not the agent being confused. They are the agent being confident.

The reason is structural. The model is reasoning about the code. It is not reasoning about the program. It has read what the code says it does, but it has not seen what the code actually does under your specific inputs, your specific load, your specific race condition.

The code is a hypothesis. The program is the truth. And the model has only ever seen the hypothesis.

Every "obvious fix" that doesn't work is a hypothesis that never met reality.

The shift no one is talking about loudly enough

David Gomes, who works at Cursor, wrote a piece a few weeks back about what they call Debug Mode. The argument he makes is interesting because it is not really about the feature. It is about the principle underneath the feature.

Cursor's Debug Mode does one thing. It teaches the agent to add logging, run the code, and read the logs before it tries to write a fix. There's a clean little loop: hypothesize, instrument, reproduce, read, fix, clean up. The agent doesn't edit your implementation in the same pass it adds logging. It treats logging as a probe and code changes as interventions. It keeps them separate.

Gomes argues, correctly I think, that they could have called this feature Instrumentation Mode. The novelty isn't that the agent debugs. The novelty is that the agent has runtime context.

And once you see this pattern, you start to see it everywhere. The agents that quietly ship working code are the ones whose harness gives them runtime information. The agents that loop forever on the same bug are the ones whose harness only gives them source code.

This isn't a Cursor story. It's the same idea you find in Tejas Kumar's IBM talk on harnesses, in Ryan Lopopolo's work at OpenAI, in Manjeet's writing on the evolution from prompts to context to harness, in Karpathy's repeated point that the apparatus around the model is doing the heavy lifting once you leave the playground.

A model alone is a closed book. A harness is what gives the model a window into the running world.

What runtime evidence actually catches

Here is the bit that makes harness engineering not just a fancy idea but an immediate, measurable improvement to how your agents work.

There are entire categories of bugs that no amount of code reading will surface. They live in the program, not in the source. They show themselves only when the program runs.

The 1-in-20 race condition that corrupts state under concurrency. No file will tell you about it. You have to see two log lines arrive in the wrong order.

The memory leak that takes thirty minutes of traffic to show up. You will never see it by staring at object lifetimes. You see it in a heap snapshot.

The native crash inside a compiled dependency. The agent can read your Python all day. The crash is in C.

The rendering bug that has been sitting in your ticket queue for six months because every senior on your team gave up. The DOM under load doesn't look like the DOM in the source.

The Heisenbug that vanishes the moment you put a breakpoint near it. The only way to find these is by leaving the program alone and observing it.

I have an agent loop that catches these now. It is not because I changed models. It is because I built the harness around the model to give it runtime evidence by default. Hypotheses get ranked, logging gets added, scenarios get reproduced, logs get read, fixes get written, instrumentation gets cleaned up.

Same model. Different harness. Different outcome.

The discipline that makes it work

If you only take one thing from this, take this one.

Never let your agent log and edit in the same pass.

The whole evidence loop falls apart the moment you mix them. If the agent adds logging and changes the implementation at the same time, and then the bug behaves differently, you cannot tell which change moved the needle. Was it the new logic? Was it the side effect of the instrumentation? You don't know. You're guessing again. With extra steps.

Logging is a probe. Code changes are interventions. Treat them as different operations. Run them as different passes. The agent observes first. The agent intervenes second. Never both in one swing.

This sounds obvious. It is not what most agents do by default. Most agents, given a task labeled "fix this bug," will read three files and start writing a patch. The patch and the print statements and the experiment all go in at once. And then the agent reads the new output and either declares victory or starts over, with no clean signal about what its own change did.

A real harness enforces the separation. The agent is not allowed to write to a file labeled "implementation" during a logging pass. That is a rule the harness applies, not a rule the model has to remember.

The part you cannot automate away

Here's the uncomfortable part. The reproducer in this loop is you.

You are the one who can click the button, deploy to staging, exercise the failing test, send the request that triggers the bug. The agent can do a lot. It usually can't reliably re-trigger a bug that lives in a system more complicated than a unit test.

This is the same point Gomes makes about Debug Mode adoption. The feature is genuinely useful. Most users don't use it. It requires a human who is engaged enough to do the reproduction step. And most code from here on is going to be written by humans who are not particularly engaged.

I keep coming back to this. The future of AI coding is not "press a button and the agent ships." It is a tight, fast loop where the agent does the tedious instrumentation and inference work and you do the part of the work that requires a body in front of a screen and a finger on a button.

That isn't a downgrade. It's an upgrade. You stop being a code-typer and start being a debugger-of-debuggers. Your judgment matters more, not less.

The mental model shift

Stop trying to make the model smarter. The smartest model in the world still cannot see what it cannot see.

What you're actually building, when you build a serious agent system, is the apparatus around the model. Tools. Logs. Retries. State persistence. Verification steps. Ways for the agent to test its own hypotheses against reality instead of asking you to confirm them.

Fowler's article frames this as feedforward controls (guides that shape what the agent does before it acts) and feedback controls (sensors that catch mistakes after the agent acts). Both matter. Without feedforward, the agent is unsupervised. Without feedback, the agent repeats the same mistakes forever.

The bug-fixing loop I described above is one specific instance of this. The hypotheses are feedforward, shaped by your codebase and the bug description. The logs are feedback, telling the agent which hypothesis survived contact with the running program.

You can build the same pattern for code review, for refactoring, for migrations, for performance work, for anything where the model needs to be told what reality looks like instead of inventing reality from source.

That is the work. That is harness engineering.

The model didn't get smarter. The harness did.

What to do this week

Don't wait for a vendor to ship this for you. If you're using an agent that doesn't have a built-in evidence loop, build one yourself. The pieces are not exotic.

Start with these three:

A logging convention your agent can read. Pick a format, write a one-line skill or AGENTS.md note explaining where logs go and how to read them, and make sure your agent always emits in that format when instrumenting.

A separation rule. Tell your agent, in whatever instruction file it reads, that logging and implementation changes must happen in different passes. Add it as a checkbox in your task templates if you need to.

A reproducer you can actually run. The faster your reproduction loop, the faster the evidence loop. If you're sitting in front of a 90-second test cycle, your agent is going to be sitting too. Cut that to 10 seconds and you'll fix bugs five times faster, regardless of which model you use.

These three changes are not a feature release. They are an attitude. They are what it looks like to take the harness as seriously as you take the model.

If you do, I promise you the next bug your agent claims to have fixed will actually be fixed.

Sources I found useful while writing this:

Martin Fowler / Birgitta Böckeler, Harness engineering for coding agent users (April 2026)
David Gomes, Cursor's Debug Mode Is Arguably Its Best Feature
Cursor team, Introducing Debug Mode: Agents with runtime logs
Eric Zakariasson (Cursor), original announcement thread on X
Manjeet, Context → Harness Engineering: The Evolution of Building AI Agents

If this resonated, I'd love to hear what your reproducer looks like and where your evidence loop is breaking. Reply on Substack or drop a comment here.

Originally published on my Substack.

— Shrey