Use case · Software engineering
An extra engineer in your Slack.
Cedric fixes the bug from the thread, works with your coding agent, and tells the rest of the team what shipped. You review and merge.
$50 in free credits when you sign up. No card needed.
- Say "fix the bug Chris hit" in the channel. Cedric finds the thread, writes the fix, and opens a pull request.
- It works alongside your coding agent: the agent builds with you in the editor, Cedric handles what arrives in the channel.
- Ask "what did the dev team do this week?" and get a real answer with charts, without interrupting a single developer.
- Nothing merges or deploys on its own. Cedric proposes, your team approves.
Fix the bug
The build went red at 03:00 and it was green by 03:04.
Tomás Rivera9:14 AM
@Cedric the checkout PR is failing CI again
CedricAPP9:15 AM
It is the null guard, not flakiness. `checkout(cart)` gets an undefined cart when the session exists but the basket has expired, which the new session test now exercises. I opened PR #4471 with the guard and a regression test. Full suite is green. Want me to request review from the checkout owners?
It reads the real failure
The stack trace, the diff, and the test that broke. Not just "something is red".
It knows flaky from real
A test that passes on retry gets reported as flaky, not papered over with a rerun.
The fix arrives as a PR
A branch, a diff, and a test, reviewed like any other. Nothing merges without a person.
Work with your coding agent
The bug Julie found, fixed before standup.
Marco Ruiz10:02 AM
@Cedric Julie found a checkout bug in QA yesterday, her thread is in #qa. Get it fixed.
CedricAPP10:03 AM
Found her repro in #qa: discounts over 50% showed a negative total at checkout. I handed it to your coding agent with the repro attached, reviewed the patch, and opened PR #4488 with the failing case now passing. Julie is tagged to confirm.
A plain report is enough
"Julie found a bug" works, because Cedric reads the thread where she described it.
It hands work to your agent
Cedric passes the repro and the context to your coding agent, then reviews what comes back.
The reporter closes the loop
Julie confirms the fix on her own repro. The loop ends where it started.
Catch up fast
Forty messages, five lines, and the action items.
Kevin Zhou11:26 AM
@Cedric summarize the incident thread, I am joining late
CedricAPP11:27 AM
Checkout started throwing 500s at 14:12 after deploy `a91f`. Root cause is the payment client timeout dropping from 30s to 3s in that deploy. Rolled back at 14:26, errors stopped at 14:27. Open items: Nadia is writing the postmortem, the timeout config needs a test so it cannot silently change again, and nobody has told support yet. Affected window was 14 minutes, roughly 340 checkout attempts.
See the week
"What did the dev team do this week?"
Lena Brunner2:05 PM
@Cedric what did the dev team do this week?
CedricAPP2:06 PM
23 pull requests merged, 31 reviews, 2 hotfixes, and the payments refactor is most of the way through review. Busiest area: checkout. Charts and the full breakdown are attached, readable without opening the repo.
From the repo, not from memory
The numbers come from the week's actual commits and reviews, not from anyone's recollection at standup.
Readable by non-developers
It says "the export bug is fixed", not the commit hash. Anyone in the company can ask.
Make it a habit
One yes turns it into a Friday report the team never has to write.
The week, in one picture
What the Friday report's chart looks like.
Illustrative week, compiled from the connected repo.
Where to start
Read-only first. Connect more once you trust what it says.
- 01
Add it to your dev channel
One click, and it is present where the build notifications and the incident threads already land.
- 02
Let it read for a week
Summaries and explanations only: "summarize this thread", "why did this deploy fail". Zero risk, and you learn how good it is.
- 03
Connect the repository
Scoped access, read-only is fine to start. Now it can point at actual code when it explains a failure.
- 04
Let it open pull requests
Branches and diffs through your normal review process. Your branch protection rules still apply.
Compared to the alternatives
Bots and scripts already do parts of this well. The difference is what happens when something is not routine.
| CI bot | Dependency bot | Coding agent in the IDE | Cedric | |
|---|---|---|---|---|
| Tells you the build broke | Yes | No | No | Yes, with the cause |
| Explains why in context | No | No | Yes, if you ask it there | Yes, in the channel |
| Opens a fix | No | For versions only | Yes, in your editor | Yes, as a PR |
| Summarizes a human thread | No | No | No | Yes |
| Available to non-engineers | No | No | No | Yes, same channel, plain language |
| Merges or deploys unattended | No | If configured to | No | Never, approval required |
FAQ
No. It opens them, and your normal review and branch protection rules apply exactly as they do for any contributor. Merging and deploying always wait for a human yes.
No. You scope access when you connect the repository, and you can revoke it any time from the dashboard.
They are teammates, not rivals. The agent builds with you in the editor; Cedric handles what arrives in the channel, and it can hand a repro to the agent and review what comes back.
It reports what it found, what it ruled out, and where it got stuck, then hands it back. A good handoff beats a confident wrong patch.
Yes. Support can ask whether a customer's issue is the known bug and get a plain-language answer from the same shared memory the engineers use.
If it exposes an interface Cedric can reach and you grant scoped access, yes. Nothing is connected until you connect it.
Ready when you are
Put Cedric in the dev channel.
Start with summaries, let it open PRs when you're ready. $50 in free credits, no card needed.
$50 in free credits, no card needed.