I Built a Comment Sync. It Built an Intelligence Layer.
I built a comment sync between RT and Jira. Three unintended benefits showed up that nobody planned for.
A director in a meeting assumed we already had two-way comment sync between Request Tracker and Jira. We didn't. We had one-way - Jira into RT. He said we should have both.
I'd already built the one-way bridge. Wrote about it in I Make Tools. Extended it to create tickets in reverse in twenty-two minutes during a demo, which became The 22-Minute Feature. The API connections existed. The architecture was clean.
So I took it as a challenge and wired up the two-way sync.
What happened next is the point. Not the sync - that was straightforward. Three things showed up that nobody planned for and nobody predicted.
The tools started solving problems we didn't know we had.
1. The SQL Graveyard Came Back to Life
Request Tracker sits on top of a SQL database. Years of tribal knowledge lived there - specific SQL commands that fixed obscure production issues, one-off solutions to problems that crop up every six months, workarounds that only one person remembered.
The data wasn't in a queryable state for most engineers. RT's interface buries information in ticket threads - you'd need the exact ticket number or raw SQL access to find anything. The knowledge was there, but it wasn't discoverable. Dark data. Useful, inaccessible, slowly forgotten.
When I synced those comments into Jira, Atlassian's Rovo - their AI intelligence engine - suddenly had context it didn't have before. Not the full RT database (yet), but the last seven days of comment activity flowing in continuously. SQL fixes, one-off solutions, tribal knowledge trickling out of RT and into something that could actually index it.
We noticed it almost immediately. Specific SQL commands that used to require hunting through RT - or digging through someone's personal or shared Postman collection - were surfacing through Rovo. Fixes that took an hour of archaeology to find? Seconds. The team stopped reinventing solutions to problems someone had already solved eighteen months ago.
Nobody built a knowledge management system. A comment sync accidentally created one.
2. Status Updates Without the Nagging
Every Scrum Master has felt this pain. You need accurate cycle time data, but developers hate updating ticket statuses manually. Tickets sit in "To Do" long after work has started. Cards move to "In Progress" days late. Your flow metrics are suspect because the data entry is voluntary and nobody volunteers. You can backstop it by asking at every Daily Scrum, "Is your ticket in the right status?" - but that's you doing the computer's job again.
Frustrating.
I've talked about this friction before. In Stop Generating, Start Building, I called it the kind of administrative toil that computers should be doing for us. Manual status updates look productive but produce unreliable data.
With comments syncing both ways, we detect when a team member posts a comment in RT - something as simple as "looking into it" or "checking the logs." A Jira automation with a regex check determines whether the comment came from a team member, and if so, moves the corresponding ticket to In Progress automatically.
No nagging. No Slack reminders. No "hey, can you move your card?"
Cycle time data is cleaning itself up. Becoming more accurate every day. Not because I built a status-tracking tool - because comment activity became a proxy signal the automation could act on.
Passive measurement beats active reporting every single time. Reduce the friction of data collection, and the data gets better on its own.
3. The Tax Man's New Best Friend
This one caught me off guard. Completely.
Modern build systems that are properly instrumented already track when code hits production. CI/CD pipelines, deployment dashboards, release tags - if your stack is current, you've got timestamps. But what about legacy systems? What about work that flows through RT into production without touching a modern pipeline?
When a ticket gets marked as done in our RT-Jira system, it logs a timestamp. I built that for operational visibility - knowing when changes actually hit production versus when someone remembered to close the ticket.
Turns out Finance needs exactly that data.
R&D tax credits require documentation proving when development work was completed and when it reached production. That's usually a manual mess - someone in Finance chasing down engineers, product owners, or product managers: "When did this feature go live? Can you prove it?" Spreadsheets. Emails. Calendar archaeology.
The sync created an automated audit trail. A verifiable, timestamped record of when work started (comment detected), when it was completed (ticket resolved), and when it reached production (deployment logged). All without anyone in Finance asking for it.
A developer tool accidentally became a governance asset. That sentence still feels weird to type.
The Second-Order Effect
What do you call it when your tool starts solving problems you didn't build it for? Systems thinkers call them second-order effects - the consequences of consequences. You solve Problem A, and the fixes for Problems B, C, and D show up uninvited.
Most teams justify automation by the problem it solves. Build a sync to see comments? ROI is "time saved not copying comments manually." Clean. Simple. Fits on a slide.
But the real ROI lived in problems nobody knew existed until the data showed up somewhere useful. Tribal knowledge retrieval. Passive metrics. Compliance documentation. None of these were in the acceptance criteria. None were in the original user story. They emerged because bridging two siloed systems created a feedback loop that surfaced value nobody anticipated.
The 18th State of Agile Report says 41% of organizations cite lack of visibility into work. That number has sat in the top five for a decade. We keep trying to solve it with dashboards and status reports.
Maybe the answer isn't another dashboard. Maybe it's connecting the systems that already have the data and letting AI do what it's actually good at - sifting through massive volumes of information that no human has the time or patience to read. Thousands of RT comments, years of ticket history, patterns buried across databases. AI doesn't get bored. It doesn't skip tickets because it's Friday afternoon. Point it at the data and let it surface what matters.
What This Means for Builders
If you've read through this series - I Make Tools, Stop Generating Start Building, The 22-Minute Feature - you've watched an arc. Sensing a problem. Building a tool to see it. Building faster. And now this: the tools building intelligence layers we didn't design.
I didn't plan any of these three benefits. I planned a comment sync. The comment sync planned the rest.
It is for this reason that I keep saying: don't just build tools to solve a task. Build them to unify your data. When you bridge two siloed systems, you aren't just saving time. You're creating conditions for the AI to make connections humans weren't making - because humans couldn't see the data in the first place.
Your tools aren't just doing what you told them. They're telling you things you didn't know to ask.
Try this Monday: Look at two systems your team uses that don't talk to each other. Not email and Slack - something structural. The ticketing system and the deployment pipeline. A CRM and a project tracker. The support queue and the sprint board.
Now ask yourself: what would happen if they did?
You might be sitting on an intelligence layer you haven't built yet.
Continue Your Journey
The Second Brain: The complete guide to building a personal AI operating system that captures, organizes, and retrieves your digital life - the same architecture behind the RT-Jira integration in this post.
Build, Don't Generate: Full slide deck on why AI generation is a commodity and how to shift to building reliable software systems.