Automatiq began in a classroom. I was watching one of my teachers manually fill out forms for an online event, painstakingly copy-pasting data row by row from an 500 row Excel sheet. As a developer, watching manual data entry was painful. I thought, "I can write a script for this."
But when I looked for solutions to help generate the automation quickly, I hit a wall. Nearly every existing solution in the market wanted to spin up a heavy Chromium browser, or relied on flaky browser extensions to click buttons and drag sliders on a screen.
In my years working as an Automation freelancer, I learned a simple truth: UI automation is inherently brittle. Buttons move, pages load slowly, and UI quirks break scripts. Meanwhile, under the hood, websites are just sending simple text-based HTTP requests. Browser-based automation/scraper workflows can take up a lot of memory and compute to run. They deplete resources, they are slower than requests-based scripts.
Why had the industry accepted bloated browser-based solutions as the standard, when a clean, 300-line Python script making direct requests is hundreds of times faster, and nearly 10 times lighter?
The answer: Reverse-engineering websites are a complex, time-consuming challenge and reverse-engineered scripts break all the time.
Personally, It takes me about an hour or 2 to come-up with an MVP manually that can get at least one data point or automate one single automation workflow. Fixing broken scripts requires you to go through the site again and patch your script up manually, taking about 75%-50% the same time as writing them the first time. And yes, scrapers can break a lot (But not as much as the UI-based automations)
The Second issue is the Myth that requests-based solutions won't work anymore. But my research on that showed otherwise:
| Tier | What it includes | Estimated share of sites | Source |
|---|---|---|---|
| None (no protection) | No CAPTCHA, no fingerprinting, no rate limit, no WAF, no anti-bot vendor | \~60–62% | DataDome 2025 Global Bot Security Report |
| Light (CSRF, headers, basic rate limiting, simple obfuscation) | Mostly app-framework defaults; no dedicated anti-bot product | \~25–35% (subset of "partially protected") | DataDome 2025 Report \+ W3Techs Cloudflare |
| Medium (TLS/JA3 checks, image CAPTCHA, reCAPTCHA v2, basic WAF) | reCAPTCHA, hCaptcha, Cloudflare WAF on free plan | \~10–15% | BuiltWith reCAPTCHA v3 \+ BuiltWith hCaptcha |
| Hard (reCAPTCHA v3, Turnstile, hCaptcha Enterprise, Cloudflare Bot Mgmt) | Vendor-managed bot mitigation, behavioral scoring | \~3–5% of all sites; \~20–30% of top-ranked sites | Cloudflare Bot Mgmt market share (wmtips) \+ BuiltWith reCAPTCHA Enterprise |
| Very Hard (Akamai Bot Manager, DataDome, HUMAN/PerimeterX, Kasada, Imperva, full canvas/WebGL+TLS fingerprinting) | Enterprise anti-bot stack with multi-signal fingerprinting | \~1–3% of all sites; concentrated among Fortune-500 / e-commerce / travel / financial | BuiltWith Akamai Bot Manager \+ BuiltWith DataDome \+ UCSD IMC 2025 canvas fingerprinting paper |
Just basic requests-based solution (with TLS spoofing mechanisms) can be applied up to 70% to 90% of the current websites.
All I had to do was to make the requests-based approach easier to create and maintain for everyone
Automatiq was born to solve this problem, making the process of Reverse-engineering as easy and autonomous as possible.
Standard coding agents (like Claude Code or OpenCode) are designed to write clean code in a local directory, then write more than they read. Most of the knowledge they require was provided in their training data.
But a reverse-engineering agent is entirely different: it needs to get its hands dirty with complex, broken, unformatted data from decade-old websites. It must read more than it writes, and most of the knowledge required isn't available in their training data.
Getting an AI to successfully reverse-engineer web requests required 6 months of time, built through a lot of trials and errors, with expensive API bills. I had to rewrite the whole module four times, due to logical mistakes I had made. But finally, I am presenting here.
The First question was How?, Usually developers use Devtool's network tab to see all the requests sent. This was pretty easy to implement, all I had to do was to record the requests via Chrome Devtools Protocol(CDP). Each request is converted into a folder, Headers, payload data, response data as separate files, and their extension generated by Magika module by analyzing the file content.
If you just hand an AI a pile of raw network requests, it gets lost. It doesn't know why a request was made. Academic papers on UI automation suggest generating "high-level summaries" using screenshots of what the user is doing. But a single screenshot doesn't capture intent.
To solve this without racking up massive API costs by feeding the Vision-Language Model (VLM) full videos, Automatiq captures action-correlated clips. It records a 4-second, ultra-low-framerate video chunk precisely when an action (like a click or keystroke) occurs. The AI sees what happened before, during, and after the action. This transforms user and browser activity into an easily navigable file system that gives the agent a clear compass for its reverse-engineering task.
Because this output is just a cleanly structured file directory, there is zero vendor lock-in. You don't have to use Automatiq's built-in agent, you can point your own custom LLMs or scripts at the recorded folder and let them work.