The state tracking and manual fallback are the most interesting parts to me. For a tool like this, I’d really want a dry-run/audit mode that shows which fields would be submitted to which broker before anything is sent. The awkward threat model is that the tool reduces exposure, but a broken selector could also leak personal data to the wrong place.
I’ve seen LLMs make money most reliably when they’re embedded into an existing
workflow rather than sold as “AI” itself.
One example: a small team built an internal tool for SEO/content teams that
generates structured content briefs and refresh plans from search data.
The value wasn’t faster writing, but fewer failed pages. Clients were willing
to pay because it reduced wasted content spend and made outcomes more
predictable. It ended up as a SaaS with recurring subscriptions rather than
a usage-based novelty.
Another case was customer support tooling for a B2B product. LLMs were used to
summarize long ticket histories, surface likely causes, and draft replies,
but humans stayed in the loop. The business impact showed up as lower support
headcount growth while revenue increased, which leadership cared about more
than raw “productivity.”
Across cases, the pattern seems to be:
- tie the model to a clear economic decision
- charge for risk reduction or revenue lift, not for text generation
- keep humans in the loop where mistakes are costly
Pure “LLM apps” struggled more unless they were tightly scoped or had strong
distribution already.
I’ve noticed something similar, though I don’t think it’s literally “time of day”
so much as changing system conditions.
My working theory is that under higher load, the model is more likely to:
- take broader interpretive leaps
- attempt larger refactors instead of minimal diffs
- “explain its way forward” after a wrong turn rather than reset cleanly
That shows up as rabbit holes and self-reinforcing iterations, especially on
codebases where local consistency matters more than global cleverness.
What’s helped a bit for me:
- explicitly asking for minimal, localized changes
- telling it not to refactor unless necessary
- breaking requests into smaller steps and locking earlier decisions
It could also be variance from routing, context window pressure, or subtle
prompt drift rather than a predictable nightly degradation, but the pattern
of “overconfident refactor spirals” feels real.
A like-for-like experiment with the same prompt and context at different times
would be interesting, though hard to fully control.
I’m not a full-time COBOL dev, but I’ve worked adjacent to mainframe systems
(bank integrations, legacy batch jobs, and data pipelines).
From what I’ve seen, LLMs aren’t really a threat to COBOL roles right now.
They can help explain unfamiliar code, summarize programs, or assist with
documentation, but they struggle with the things that actually matter most:
institution-specific conventions, decades of undocumented business logic,
and the operational context around jobs, datasets, and JCL.
In practice, the hardest part isn’t writing COBOL syntax, it’s understanding
why a program exists, what assumptions it encodes, and what will break if
you change it. That knowledge tends to live in people, not in code comments.
So AI feels more like a force multiplier for experienced engineers rather
than a replacement. If anything, it might reduce the barrier for newer
engineers to approach these systems, which could be a net positive given
how thin the talent pool already is.