DEV Community: Dani Grant

Introducing The Valentines Day Debugger – AI debugging hints for your relationship problems

Dani Grant — Fri, 14 Feb 2025 20:19:55 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1890423272875196896-601'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1890423272875196896&theme=dark" }

Now you can capture all the debug details of your relationship problems. Diagnose & fix issues faster, complete with AI hints!

Software engineers are telling us this is saving hours of their time.

Let us give you a tour!

1-click send to friend chat

Instant replay for critical moments

AI helpfully offers suggestions

We're just kidding, but we hope this made you smile! Happy Valentine's Day from your friends at Jam.dev 💜

We built an AI bug reporter with Gemini 2.0

Dani Grant — Thu, 06 Feb 2025 16:04:49 +0000

It’s insane that bug reporting is still done by hand. People are terrible at writing bug reports. That’s how you end up with hours of back-and-forth for a 5 min fix. "What browser?" “Is it still happening?”

But this is a problem you can fix with tools. Humans are inherently error-prone when it comes to reporting bugs, but computers aren’t. Imagine a tool that plugs into devtools and grabs: session recording + network logs + error traces + AI that writes a summary and repro steps.

A few years ago, we built a tool that captures all the information you’d get in a HAR file plus screen recording and packages it into a link for engineers. (Like a screen recorder plus DevTools). It’s called jam.dev and people use it to capture more than half a million bugs each month now (which we are really excited about!)

Today we added an AI inside that analyzes all of the session data and errors/traces in the console and network logs and writes a concise description of the bug and lists out the exact repro steps, complete with timestamps mapped to the screen recording. It’s built with Gemini 2.0 which we used while in experimental mode. We chose Gemini because of Gemini’s native ability to process videos (which other LLMs don’t have).

I’d love for you to try it out and let me know your thoughts. My email is dani@jam.dev and I hope to hear from you.

Try it: jam.dev/ai

Demo: https://x.com/jamdotdev/status/1887523689518014891

I think people are going to have a large role in testing software for a long time (as long as humans are the users, humans need to be testers too), but what doesn’t need to be manually done is collecting debug information and writing it up into a ticket. Like Kasparov and Deep Blue, the strongest collab is human + computer paired together –– humans to their strengths, computers to theirs.

By the way, we’re hiring engineers and working on building AI for debugging, de-duplication and auto-resolution and if these are problems that excite you, we’d love to chat: jam.dev/careers

9 lessons we learned building Jam in 2024

Dani Grant — Thu, 02 Jan 2025 17:36:55 +0000

Thank you for being a part of Jam this year! We crossed 6 million Jams, 170k users, shipped 31 new features and an entirely new Jam for your helpdesk, saved engineers 50+ years of debugging time (!) and got to meet 2,000 of you at a Jam meetup.

Everyone who Jams is a builder trying to make some corner of the world better through software. Y'all are awesome.

So, we wanted to end the year by sharing with you — builder to builder — 9 lessons we learned at Jam this year. And if you feel inspired, I'd love for you to let me know a lesson you learned building your product.

1. Small teams, high ownership

This year we grew from 11 to 20 people, and split from one team into specialized pods. And… small teams with true ownership run faster and do more than I ever thought possible.

2. Quality requires engineering discipline

It's a practice you have to keep. You don't just work on performance "this quarter". It's a mindset and a practice you stick to every day.

3. Getting over our process allergy

When you're small, it's important to be allergic to process. But as you grow, a bit of process is needed so you can do more things than anyone can keep in their head. This year we added just a few templates, checklists and weekly reviews. At first I was resistant, but now can't imagine how else we could manage so many parallel projects going on at any given time.

4 Treat everything as user experience

Even if it's an email, it's still a user experience. It takes longer to craft everything when you think like that. But, you end up shipping things that you're excited for users to experience! And that's super fun.

5. Great dev teams do the boring things well

Investing in the boring things unlocks you to move on to new problems. Docs, testing, deployment, infra. It's really boring to upgrade your servers, but all that investment means we get to go even faster now ("and sleep better" says the currently on-call engineer).

6. 1 + 1 designers = 3 designers

I used to worry that adding a second designer would slow us down, because instead of one person having all the context, they would need to coordinate. But actually, when we grew the design team, we were able to do even more because they had thought partners to think through our hardest design challenges. That was really cool to see.

7. The simple version is better

When in doubt, ship the simplest thing. The live Jam product today started as an internal project called "Simple Jam". The live Jam pricing started as an internal project called "Simple pricing". The simplest version is simply better.

8. Hire people who awe you

Hire people who love what they do. Hire people who care so darn much, you can't help but smile when they share. The joy of building things happens in moments, day to day, week to week. The people you get to build with are everything.

9. Time moves really fast in a startup

A lot of things change in a year. Things grow up quickly. Cherish the moments :)

Now, onto 2025! Excited to continue the Jam journey with all of you. Thanks for being a part of it. Happy new year!

💜, the Jam team:

Our ex-cloudflare team built a tool that extracts debug data from screen recordings

Dani Grant — Mon, 25 Nov 2024 18:07:26 +0000

Hey DEV Community! 4 years ago, an ex-Cloudflare team and I started building a product — trying to make bug reporting a lot less painful.

Our tool is called Jam and it makes it pretty much impossible to create vague bug reports (like I used to when I was a PM). It's really hard as a non-engineer to send useful debug info!

If you care a lot, you'll take the time to include a screenshot or a screen recording of the bug. But, sometimes the important info is what's right outside the boundaries of the screenshot – or the developer needs to know what happened right before the video? Or needs to know some info like what account you're logged in with, and if there are any errors in the console, and you can't tell that from a screenshot or video.

Debugging is the worst part of engineering - but it's not actually because of the fixing, it's all the back and forth required to reproduce & get to the debugging! This context gap should be filled by tools.

Our goal was to make it really easy for people to log bugs in a format that gives developers all the context they need, right there in the bug report.

We tried 7 different versions of Jam to solve this problem, until we landed on what it is today - a browser extension you click when you want to catch a bug.

It's basically a screen recorder, except Jam auto-captures:

console logs
network requests
repro steps
session & user details
device & OS
backend logs

There's some extra debug tooling in there for websockets and graphql too (we love/hate graphql, but that's besides the point.)

You can see an example of what the captured data looks like here: https://jam.dev/c/96149346-3cb1-439a-b4d0-fed8181ea036

2 years into this version of Jam, our tool is used by over 150,000 people to fix more than 5 million bugs! That's really awesome, but there's so much more to do.

We really want to build something that makes this part of the job suck less. So, I wanted to open up for discussion here and get your feedback.

Jam is free to use forever (we've got a paid plan for companies who need it, but we will always keep a large free plan - after all, we learned to build products at Cloudflare).

I hope you'll check it out and let us know what you think: https://jam.dev

My email is dani@jam.dev, feel free to reach out anytime.

By the way, we're hiring engineers and if making debugging a lot more efficient is a problem that excites you, we'd love to chat: jam.dev/careers