See how close you are to your ngrok limits. The dashboard Limits page now shows status, current usage, and when a limit last turned a request away, for API keys, domains, team members, and more. ngrok.com/changelog/dashboar…

Traffic Inspector now shows TCP connections, not just HTTP requests! See the client IP, duration, bytes in/out, and the ngrok error for TCP/TLS endpoints. Get wild, filter with 𝚙𝚛𝚘𝚝𝚘:𝚝𝚕𝚜 𝚘𝚞𝚝𝚌𝚘𝚖𝚎:𝚏𝚊𝚒𝚕𝚎𝚍 to find broken handshakes. ngrok.com/changelog/traffic-…

negative thinking destroys your brain being a silly goose and delusionally optimistic is the ultimate longevity hack

day 13 without the @ngrokHQ rizz badge. @SamCRichard said i need to demonstrate growth so i molted on the earnings call apparently that’s “also not what we meant”

yeahhh. when i hear “agents struggle with our setup,” my first question is “what could we change to help them succeed?” setting agents up to succeed rhymes a lot with setting a growing team up to succeed: clear docs, good tooling, fast feedback, less tribal knowledge. the friction agents expose is often friction people have learned to work around. fixing it pays off for both.

AI can trivially read and understand application code, so that becomes the source of truth. What purpose then, if any, do unit tests provide? Every time I make a change, AI just changes all the unit tests anyway, so there's no safety. It's all overhead.

AI uses Cameras and Lidars to spot dangerous rock slopes.

an agent fixed our bug in 4 lines, with a test that failed before and passed after. it was right (absolutely right) and i didn't ship it. the bug was a symptom. our @ngrokHQ dashboard domain sheets drifted from a pattern we'd already written down, and the agent had no way to know who catches drift on your team? ## the bug an error alert fired for one user: a detail page threw "failed to load" with the tab in the background in React Query v5, isLoading is isPending && isFetching. offline or hidden, the query pauses: pending but not fetching. so isLoading was false, data was empty, and the page threw. the query never failed. it would have resumed on focus i asked the agent if we were mishandling it. it found the same check in 3 more routes, one of them domains, swapped in isPending, and added an offline test that failed on the old code ## the step back the better question: why does a sheet throw the whole page away because its data is late? mantle, our component library, has had an async overlay recipe since July. mantle.ngrok.com/recipes/ove… the sheet mounts at once and keeps its header. only the body branches: a loader, an inline error with retry, or the content. actions wait for the data domains, and about 15 other dialogs and sheets across two apps, never moved to it. they waited on their data, then sent a failed load to the route error boundary: a full-page "something went wrong" ## what shipped every one of those overlays now paints at once and shows errors inline. a failed background refetch keeps the loaded content and any unsaved input. the 2 routes that are real pages kept the isPending swap, so the agent's fix survived where it fit the cost: a 4-line fix became 57 files, +3,230 −1,781 ## why i'm not bullish on software factories a factory takes a ticket and returns a green diff. this one would have: right root cause, regression test, passing suite the agent wasn't wrong. it answered the question it got. what it lacked was where the codebase is going: which pattern won, what's legacy, what we already decided. that lives in people until someone writes it down where an agent reads it the recipe was written down, but nobody had pointed the domains code at it!

an agent fixed our bug in 4 lines, with a test that failed before and passed after. it was right (absolutely right) and i didn't ship it. the bug was a symptom. our @ngrokHQ dashboard domain sheets drifted from a pattern we'd already written down, and the agent had no way to know who catches drift on your team? ## the bug an error alert fired for one user: a detail page threw "failed to load" with the tab in the background in React Query v5, isLoading is isPending && isFetching. offline or hidden, the query pauses: pending but not fetching. so isLoading was false, data was empty, and the page threw. the query never failed. it would have resumed on focus i asked the agent if we were mishandling it. it found the same check in 3 more routes, one of them domains, swapped in isPending, and added an offline test that failed on the old code ## the step back the better question: why does a sheet throw the whole page away because its data is late? mantle, our component library, has had an async overlay recipe since July. mantle.ngrok.com/recipes/ove… the sheet mounts at once and keeps its header. only the body branches: a loader, an inline error with retry, or the content. actions wait for the data domains, and about 15 other dialogs and sheets across two apps, never moved to it. they waited on their data, then sent a failed load to the route error boundary: a full-page "something went wrong" ## what shipped every one of those overlays now paints at once and shows errors inline. a failed background refetch keeps the loaded content and any unsaved input. the 2 routes that are real pages kept the isPending swap, so the agent's fix survived where it fit the cost: a 4-line fix became 57 files, +3,230 −1,781 ## why i'm not bullish on software factories a factory takes a ticket and returns a green diff. this one would have: right root cause, regression test, passing suite the agent wasn't wrong. it answered the question it got. what it lacked was where the codebase is going: which pattern won, what's legacy, what we already decided. that lives in people until someone writes it down where an agent reads it the recipe was written down, but nobody had pointed the domains code at it!

I updated the @ngrokHQ wall of developer love with the love below and more. ngrok.com/love If there's something you love about ngrok, let me know and I'll add yours, too. If there's something you want us to make better, let me know and we'll get on it even faster.