shardullavekar

some x.com influencer claiming that they built a one man company with agents doing everything. Like, hey Claude - create a staffing automation company and a swarm of agents search, reach out, follow ups, and AI voice calls etc. Its bs marketing, I get it but "what if this comes true, not now but in future?" - drives the anxiety. The sandwich framework sounds great until the decision and accountability is passed on to AI with guardrails. The AI in its current state is great to take the feedback and decide the next course of actions.

looks great. any plans of abstracting these functions with an LLM integration?

hence the sharability and subscription. other users need to explicitly subscribe to the page boosters. Else they continue with what they have.

users didnt ask for slow apis either but there they are. I am speaking for the user here and sharing their frustration. Allowing UI modification to fit the user needs should be a default now. The APIs already act as a gaurdrail on what's possible

I created that twitter responder after reading this post (https://news.ycombinator.com/item?id=47568028). That wasn't to call out what SaaS companies should prioratise but to show how easy it would be for a user to do it.

got our extension approved, post which we had no issues.

these embeddable UI could be a direct ask on how users want a workflow, the SaaS vendors can distribute the embeddable UI and see if it clicks with a lot of users. Would push them to create a stable API

> In the end, your obligation as a company, regardless of your product, is to generate profits.

No denying that. SaaS started with a user problem at the center of it and as they scaled, forgot about an individual user. This only presents the user frustration and a possible solution to it.

I think the right step would be to somehow communicate to the vendor that this feature is needed (eliminating the PM backlog BS) and their coding Agents should pick it and build it. The real moat they have is SaaS vendors have everyone believe that trivial feature requests take time to implement.

wondering if all the new browsers in the market have the ability to block such scanning APIs explicitly.

wondering how this fares for languages other than English.

is someone building an agent to manage self hosted infra? A lot of "convenience" issues around self hosting free software would go away.

has anyone come across an r2d3-style explainer for something as high-dimensional as a Transformer's attention mechanism?

jack_pp made a point in the comments, worth noting.

no 2nd thoughts about it, we are only making ffmpeg more accessible and embeddable.

1. download a larger video from s3. 2. Use NLE and cut it into shorts. (crop, resize, subtitles etc.) 3. Upload shorts on YouTube, Instagram, Tiktok.

He does use davinci resolve but only for 2.

NLEs make ffmpeg a standalone yet easy to use tool.

Not denying that major heavy lifting is done by the NLE. We go a step ahead and make it embeddable in a larger workflow.

people intimidated by a CLI tool but find tools like chatgpt easy to use and those who have video editing as a part of larger workflow.

That's exactly how it is implemented!

we took a basic example and described it. (will try adding a complex one)

we have our designer/intern in our minds who creates shorts, adds subtiles, crops them,and merges the audio generated. He is aware of ffmpeg and prefers using a SaaS UI on top of it.

However, we see him hanging out on chatgpt, or gemini all the time. He is literally the no coder we have in mind.

We just combined his type what you want + ffmpeg workflows.

so creators on 100x will create well defined workflows that others can reuse. If a workflow is not found, llm creates one on the go and saves it.

thanks for calling it out, I will correct the before vs after section. But you can describe any ffmpeg capability in plain English and the underlying ffmpeg tool call takes care of it.

true, companies like Descript, Veed, or Kapwing exist because no coders find this syntax intimidating. Plus, a CLI tool stands out of a workflow. We wanted to change that.

We launched Agent4 recently. You can install it from here: https://chromewebstore.google.com/detail/agent4/kipkglfnhnpb...

The one you refer will be taken down soon. Ping me on discord if you need help in trying it.

a built-in mcp server that takes a look at what's broken and communicates with cursor is on our roadmap. Join discord and we will keep you posted there.

It's a chrome extension. Works if you use chrome.

A workflow can have subjective parts too. For example, click on button A if it satisfies certain conditions I wrote in plain English, otherwise click on B.

These subjective elements can be defined with user inputs/prompts.

So a workflow is a literal script with embedded LLM calls for branching or even scraping details where literal script feels tedious.

would be interesting to see if linkedin (and the likes who don't want to be crawled) signs up for the pay-per-crawl that CF may come up with.

I've been building a general browser agent myself, and I’ve found the biggest bottleneck in these systems isn’t capability demos but long-running reliability.

Tools like Manus / GPT Agent Mode / BrowserUse / Claude’s Chrome control typically make an LLM call per action/decision. That piles up latency, cost, and fragility as the DOM shifts, sessions expire, and sites rate-limit. Eventually you hit prompt-injection landmines or lose context and the run stalls.

I am approaching browser agents differently: record once, replay fast. We capture HTML snapshots + click targets + short voice notes to build a deterministic plan, then only use an LLM for rare ambiguities or recovery. That makes multi-hour jobs feasible. Concretely, users run things like:

Recruiter sourcing for hours at a stretch

SEO crawls: gather metadata → update internal dashboard → email a report

Bulk LinkedIn connection flows with lightweight personalization

Even long web-testing runs

A stress test I like (can share code/method): “Find 100+ GitHub profiles in Bangalore strong in Python + Java, extract links + metadata, and de-dupe.” Most per-step-LLM agents drift or stall after a few minutes due to DOM churn, pagination loops, or rate limits. A record-→-replay plan with checkpoints + idempotent steps tends to survive.

I’d benchmark on:

Throughput over time (actions/min sustained for 30–60+ mins)

End-to-end success rate on multi-page flows with infinite scroll/pagination

Resume semantics (crash → restart without duplicates)

Selector robustness (resilient to minor DOM changes)

Cost per 1,000 actions

Disclosure: I am the founder of 100x.bot (record-to-agent, long-run reliability focus). I’m putting together a public benchmark with the scenario above + a few gnarlier ones (auth walls, rate-limit backoff, content hashing for dedupe). If there’s interest, I can post the methodology and harness here so results are apples-to-apples.

At unlogged.io, for some time - our primary focus was to auto-generate junit tests. The approach didn't take off for a few reasons: 1. A Lot of generated test code that no devs wanted to maintain. 2. The generated tests didn't simulate real-world scenarios. 3. Code coverage was a vanity metric. Devs worked around to reach their goals with scenarios that didn't matter.

We are currently working on offering no-code replay tests that simulate all unique production scenarios and developers can replay locally while mocking external dependencies.

Disclaimer: I am a founder at unlogged.io

Yes, we already offer it. In fact, Beepkart has just signed up for a paid support. Use the plugin and let us know if you need support with something immediately.