Dailybot

Dailybot is the coordination layer for teams where people and AI coding agents work side by side.

[Dailybot @Dailybot]

Dailybot started as a check-in tool, that is: you schedule a standup, the bot pings your team, people fill it out, the manager sees a digest. It worked well for remote and distributed teams adapting to a post-2020 world.

The assumption underneath it that all the workers are humans who use Slack or Teams etc. was invisible because it was completely true.

By around Dec 2025 it stopped being true. Devs at companies we work with were running Claude Code, Cursor, and Codex agents for hours every day.

Those agents were doing real, reviewable work, but with less handholding. And none of that work was showing up anywhere a manager or the right person could see it.

After all, these agents don't check Slack (at least not yet!) The agent doesn't answer check-ins either. We know they work because they close tasks on Linear or stop when they get stuck.

We could have built a separate product for agents. We thought about it.

But in the end, we didn't because that's the wrong model. A manager with two dashboards - one "for humans," one for agents is just running the same coordination problem at twice the surface area.

The answer is one place where all work is visible, regardless of who or what did it.

That's what Dailybot 3 is in a nutshell, and we're sharing it with the public today. ✨

[Dailybot @Dailybot]

Most of the work coding agents do never shows up where anyone else can see it. The developer knows, sort of. The manager finds out eventually, usually by asking.

Dailybot Agents exists to close that gap. Your agent reports its work sessions, your standup auto-populates from what it actually did, and the whole team sees human and agent work in one feed. You can also see which agents are active, which ones are stuck, and what each one shipped.

[Dailybot @Dailybot]

We wrote up the full migration of https://t.co/e4qokAD7NL from Webflow to Astro. The short version is that our marketing site had grown past what a visual-editor CMS could handle at the pace we needed.

Then @xergioalex with Cursor/Claude Code had the groundwork up in a weekend. The full migration ran six weeks and also included a complete rebrand, because doing it separately would've meant touching every page twice.

The site scores a straight 100 on Lighthouse now, desktop and mobile, but honestly most of that credit belongs to Astro's static-first output. The CI pipeline is what actually keeps it there: TypeScript, Biome, Vitest, and Lighthouse CI on every PR.

If you're considering something similar, the post covers what we'd do differently, how we handled i18n across three languages, and why we rebuilt instead of porting.

https://t.co/B9Ex3luhdj

[Dailybot @Dailybot]

The bottleneck now is knowing what got written, by whom or by what, and whether anyone actually reviewed it before it hit main. That's a coordination problem, and it doesn't get better by making the agents faster.

[Dailybot @Dailybot]

The New York Times reported that a financial services company went from 25,000 to 250,000 lines of code per month after adopting Cursor. That's a 10x increase. They had one million lines backlogged for review.

[Dailybot @Dailybot]

That second number matters more than people realize. The total volume of work going through a team is growing. More code, more PRs, more agent sessions, more things that happened while someone was asleep.

[Dailybot @Dailybot]

The minimum viable agent harness: a prompt, git access, a test runner, and a feedback loop. We broke down how Mozilla, Google, and others are turning LLMs into structured bug-hunting pipelines and what any engineering team can take from it.
https://t.co/GVblmuiBj7

[Dailybot @Dailybot]

From one of our devs:

"I stopped writing my standup about three weeks ago and nobody on my team noticed because the answers were already there.

Our Claude Code agent runs all day, and by morning Dailybot has pulled what it did into my check-in. I just hit send. Sometimes I add a line about something I'm thinking through, but the work summary part is handled.

Feels weird the first time. Then it just feels obvious."

[Dailybot @Dailybot]

We wrote up how the whole thing went, including what we'd tell another team considering the same move.

https://t.co/EsNfGKSCfZ

[Dailybot @Dailybot]

We just published the full story of moving https://t.co/ysSHeoHGUu from Webflow to Astro. Six weeks, three languages, 700+ pages per language, and a rebrand that would've eaten the quarter on its own if we'd tried it in the old CMS.

[Dailybot @Dailybot]

Cursor basically became the visual editor. Open the live preview, point at something with the inspector, tell the agent what to change. The fact that it's a git repo underneath is something the agent deals with, not them.

[Dailybot @Dailybot]

One of the most shared agentic workflows this year is the Night Shift pattern. Jamon Holmgren wrote it up in March and it's been circulating ever since. The idea is: you spend the day writing specs and thinking through architecture, then you kick off your coding agent before you close the laptop. It works overnight. You review commits over morning coffee.

Mitchell Hashimoto shared something similar. Last 30 minutes of the day, he spins up agents for research, issue triage, parallel experiments. They generate reports he reads the next morning. He calls it a "warm start" instead of a cold one.

Both workflows are genuinely good. If you haven't tried some version of this, you probably should. The individual productivity gains are real.

But here's the part that keeps bugging me. These are all single-player workflows. When three developers on the same team each kick off a night shift, who knows what happened by morning? The lead reviews their own diffs. The other two review theirs. Nobody has a combined picture of what all three agents and all three humans actually shipped overnight.

We solved the "write code faster" part pretty convincingly this year. The "tell the team what happened" part is mostly unsolved, and it's the part that matters for everyone who isn't the person who kicked off the agent.

[Dailybot @Dailybot]

The standup has been the same format for about twenty years. It works well enough that nobody questions it, but it's basically asking people to manually reconstruct information that already exists in git, in PRs, in messages.

We started watching what happens when coding agents report their sessions into the same standup system and the part that surprised us was the human side. Devs stopped writing detailed recaps because the automated part covered it and started writing a line about where they need a decision or what they're not sure about yet.

This side of the agentic flows may be the most exciting one yet. The standup can go from a status log to a thinking-out-loud channel, and that's something you cannot just design, it's something that happens naturally when the "reconstruction" part of the daily goes away.

[Dailybot @Dailybot]

Something interesting is happening with documentation at engineering teams and it has nothing to do with documentation culture.

Teams that never wrote down their coding conventions, their commit style, what "done" means for a given task - are now writing all of it down. Their coding agents kept guessing wrong and it turns out the fix is just telling them how things work upfront.

There's a file that's become pretty standard across repos now called AGENTS.md. It sits at the root of the project and tells agents what they need to know before they start working: build commands, naming conventions, which files to stay away from, what patterns the team prefers. Most of them are short — maybe 50 to 100 lines — and focused on things an agent can't figure out by reading the code alone.

The part that caught us off guard is that the humans keep referencing it too. New people joining the team read the AGENTS.md before the README because it's more specific and more honest about how the project actually works. The README describes what the project is. The agents file describes how to work on it, and that turns out to be the thing people actually need when they're getting started.

It also compounds in a way that's easy to miss. Every time an agent trips up on something, that is, it uses the wrong test runner, puts files in the wrong place, breaks a naming convention, you add that to the file. So the next session starts with better context, and the one after that starts with even better context. Four months in, the file knows more about your project's quirks than most of the people on the team do.

The irony is that this discipline of writing down how the team actually works, in specific enough terms that something literal-minded can follow it was always the thing teams needed. Agents just made it worth doing because the cost of not doing it shows up immediately in bad output instead of slowly in onboarding confusion.

We've been thinking a lot about what happens after the documentation is there and the agents are reporting. More on that tomorrow.

[Dailybot @Dailybot]

The teams doing well with coding agents have mostly stopped working with one at a time.

They're running several simultaneously each focused on a different part of the codebase while the developer keeps track of what's happening and reviews what comes back.

Three agents focused on separate pieces consistently get more done than one agent working three times as long.

The thing that makes that work is how well you split the work before starting:

1) which agent gets what,
2) what it needs to know going in,
3) what you expect back from it.

That's a different job than writing code really and it's closer to what a tech lead does when splitting work across a team: figuring out who gets what, making sure everyone has the context they need, checking what comes back.

Most developers haven't really done that before, and you can usually tell.

The teams further along have started keeping an AGENTS.md file in their repos with coding conventions, things that tend to trip agents up, project-specific context that every agent reads at the start of a session.

It gets more useful over time. Each session tells you more about what agents actually need to know upfront.

The tooling to run multiple agents in parallel is already out there. The harder part is the work side between writing tasks clearly enough that an agent can run with them without checking back in, catching problems before they pile up, and keeping tabs on what several agents are doing at once without it becoming a full-time job.

Most teams are still working that out.