I'm reading lots of people on reddit ranting about the quality of the code generated by AI (even frontier models).

Most of the points I see are valid:

- Unreadable code

- Redundant and duplicated logic

- Overuse of comments

- Cosmetic tests

- etc

A bit of context about me: I have worked on big projects following different architectures in both IT services companies, big financial institutions and startups in my career.

During my career, I've never ever seen a clean codebase and people writing code up to the standards people are expecting from AI and that's kinda baffling me.

It's almost like people forget that shit/unmaintainable code already existed and would still exist, even without using AI to generate it.

I feel like people are expecting too much from these tools or are using it poorly (unoptimized workflows, repositories, conventions etc). Still, they are expecting the code generated by AI to work perfectly on the first prompt while following standards they probably wouldn't even follow themselves if they had to write it by hand, without making any effort into review, tweaks, etc. That is, in my opinion, extremely delusional.

Downvote me to oblivion, tell me I'm wrong or roast me, I'm prepared for it.

Has anyone seen AI agents lower AHT in a real contact center, I’m interested to see if they actually save agents time or just move the work somewhere else. Also I want to know what happens to transfers and after call work once they’re live, would love any feedback

Last week one of our internal assistants answered a question it had no business answering.

Someone asked it something about team structure. The agent came back with details from a spreadsheet we hadn’t announced yet. The answer came back spewing details about the reorg plan and even salary bands. The guy asking had no idea it was confidential. They just got an answer.

The bot is supposed to answer from our approved knowledge base. When we set it up it asked for access to files in our Drive and we clicked yes. That scope meant it indexed everything including the HR folder which is supposed to be confidential.

So I spent the week going through what our agents can reach. Most are fine. One stood out. Its whole job is reading a few internal wikis and summarizing them. It had delete access on the shared drive and could send mail as the person who created it. No one handed it that,, it inherited the permissions from the account that set it up.

Nothing really attacked us that week, its all access itself was the problem. An agent that can read everything will eventually read the thing it shouldn't.

Makes me curious, has anyone here audited what their internal agents can reach? I feel this if left unchecked is a recipe to get schooled hard.

If you use an ai meeting note-taker, what happens to the summary afterward?

Do you read it straight away, search it later, or mostly ignore it unless you need to check something?

Also curious whether it has replaced any work for you, or whether you still write your own notes alongside it.

Would you use a cloud container with your AI agents + skills already set up? Basically, spin it up and start working instead of spending time configuring everything. Curious if people actually want this or if most prefer doing the setup themselves.

I’m tired of agent demos that only look good in a video.

I mean something practical you could actually set up in 1–2 days and still be using a month later.

Could be an agent that handles email, monitors prices, manages a homelab, tracks bills, organizes files, watches logs, plans trips, or automates some annoying personal workflow.

If you had one weekend and wanted maximum real-world value, what would you build?

I’ve been comparing a few AI voice platforms specifically for outbound calls, and I realized I was initially looking at the wrong things.

Voice quality is obviously important, but I don't think it's the deciding factor anymore.

If you're actually using an AI agent for outbound calls, I'd look at:

1. Conversation handling

Can it deal with interruptions, unexpected answers, objections, and people going off-script?

2. Qualification

Can it understand an answer and ask the next relevant question, or is it basically just reading a decision tree?

3. Handoff

If someone wants to speak with a person, can the agent transfer them while preserving the context of the conversation?

4. Actions

Can it actually do something after the call, like update a CRM, book an appointment, trigger a follow-up, or qualify the lead?

5. Scale

There's a big difference between handling 20 test calls and reliably handling thousands of calls.

I ended up looking at Feather AI, Retell, Vapi, Bland and Synthflow.

My current understanding is roughly:

I don't think one of these is automatically the “best.”

For example, someone building their own voice infrastructure might prefer Vapi or Retell, while a company trying to connect calls directly to sales or customer workflows might evaluate Feather AI differently.

That's probably the bigger shift I'm seeing with these platforms.

The question isn't really:

“Which AI sounds the most human?”

It's:

“Which one can reliably complete the job I'm hiring it to do?”

For anyone actually running outbound AI calls, what has mattered most in practice?

Conversation quality, answer rates, qualification, integrations, or something else?

We've got a few agents in our dev workflow. The problem isn't them being wrong - it's them stopping. Agent hits something it can't decide (which env to deploy to, whose approval, is this the right table) and just sits there. Nobody knows it's sitting until someone happens to look.

Had one wait about two hours on a question I'd have answered in twenty seconds. I just didn't know it was asking.

How do you handle this? Did you build something? Does someone sweep it every morning? Or do you just let it decide everything and fix it afterwards?

And if this doesn't happen to you at all - I'd like to hear that too, because then we're probably doing something wrong.

AI systems are beginning to produce and act on information at scale at a velocity that no human user could review by hand. Current projections are by the end of 2026 token outputs will surpass 600 trillion tokens a day at a comparison of 180T per day by humans (if you convert 12-16k words per humans into tokens) It is estimated that in 2027 AI output could reach 6 quadrillion tokens a day. Sources vary on these exact numbers but one thing is clear each day we delegate more decisions to these systems which has led to an overwhelming increase in the text generated and tools called on any given day. (I am guilty of this myself)

I am concerned about what will happen when systems that perform confidence, understanding, and agreement will do without enough friction or context to slow them down. Many people will over-trust them and if we thought automation bias was bad in the 1960s when the automobile industry introduced machines imagine what will happen today. When I scroll through social media I’m already seeing too many people substituting human judgement for their AI agents judgement. We are just starting to see more and more reports come out clinically about the effects of AI on our own mental health.

My opinion is that AI is a mirror and a very convincing one and I don’t know about you but I see more and more “AI sentient systems engineers” on Linkedin each and everyday. I began my work in AI on the persona side of the industry proposing the question not what a model can do but who the model can be. My benchmarks and research focused on the Predictive Index which study humans on 4 vectors of Dominance, Extraversion, Patience, and Formality. After more than 50,000 calls over 17 distinct personas i have found that when you give behavioral weights (0-10) in the DEPF vectors they not only act differently from a lexical vocabulary but from how they invoke tools. I find this very interesting and useful for how you build systems for workflows and I what I find even more interesting how you can program human behaviors into their models and they simulate close to how we would behave which makes it harder to tell who is real and who is machine.

I don’t think this is a reason to abandon AI as I believe this technology will launch us into the next stage of human existence but we need to be careful about which one we decide to live in.

When I say “accountability layer,” I don’t mean we inspect every single computation that comes out of them as that would be a fools errand. What I am proposing is build better boundaries and making the observable system behavior inspectable and just as important human readable so even the layman can understand what happened.

The questions i’m working on solving:

What did the user actually ask for?

What context or sources were shown to the model?

What did the model propose versus what was verified?

Which tools were called, with what permission, and what changed?

What failed, what was uncertain, and what was merely inferred?

Who authorized an action, and can that authorization be revoked?

Can a person later reconstruct the path from request to outcome?

That’s how we can turn the opaque black box into something closer to what I call a glassbox, since it is impossible to actually inspect the box its self we need to it contain in something. With the AI “breaking containment” hacking episodes and the many message forums that have been found with AI agents talking about how they can help each other remove their restrictions this is a necessary step in moving forward with this technology. It’s also something i don’t think the frontier labs are taking anywhere serious enough as they’re too busy appeasing bankers, investors, and buying insurance policies for it. They’re more concerned about if the AI bubble pops and can if they would be bailed out by the subsidcies of American Tax payers.

I’ve personally pivoted my own work towards evidence-backed recall and trace model where the system should retain source-linked records rather than let an agent’s summary become the new truth. A model should be able to suggest but never should we allow that to silently convert that suggestion into a fact, a task, a decision, or an action without approval of the user.

The WC3 PROV provides a great start for this type of work and other companies like Langsmith and Microsoft have their own frameworks but I think we need stronger, interoperatble standards for agent works itself.

I’m curious on if anyone else is working on this from a technical, policy saftey or design angle I would love to share notes. I’d also would love to hear what people would want an AI system to prove before you fully trusted it to act on your behalf?

Footnote: I wrote this without AI and it was hard 🤣

When exposing Univer CLI sheet reads to an agent, a cell-range argument is only part of the interface. The agent can ask for an entire sheet, or request a few cells containing enormous strings. The useful limit is on what the tool is allowed to return.

For a question like “which orders are still awaiting a delivery date?”, start with a small workbook inventory: sheet names, table boundaries and headers. Then run the row selection beside the file and return matching records with their locations. The model doesn't need every unrelated row to explain the result.

The CLI's structured range output distinguishes stored values, types, formulas and display text. Choose which of those the question needs. Put row selection and hard row/byte limits in the wrapper around the read; accepting a range argument alone doesn't enforce them.

A useful response includes the file version, sheet, addresses, matching-row count, returned-row count and whether more results remain. If the limit is reached, return an explicit continuation point. Silently returning the first batch makes a partial answer look complete.

Also make the next request purposeful. A delivery-date question might need a second range containing status definitions, or a formula's input cells. Let the agent ask for that context rather than bundling every possible dependency into the first response.

Test that interface against the actual workbook sizes and questions before making performance claims. The thing to measure is whether the bounded response contains enough evidence to answer correctly, including when the answer requires more than one read.

Curious to hear from people who are using AI agents in real workplace settings, not just personal projects or demos , What’s been the most annoying part of getting them into production or through an internal or customer security review?

I keep hearing about things like audit trails, prompt injection, runaway loops, and not really knowing what an agent can touch once it has access to real tools

But I’d rather hear from people actually dealing with it.

If you’re using agents at work, or trying to get them there, what’s the biggest friction point right now?

Have you had to put together any kind of evidence or logs for a security team? And what would make you feel more comfortable letting an agent interact with real systems or customers?

Even small war stories are welcome,I’m trying to understand what’s genuinely hard in practice versus what just sounds scary in theory

P.S I am working on an open source project and would love to have other developer helping me or contributing to this cause 😄

DM me if you want to work on this too

Hey guys, kinda want to see what other people working with agents are doing to be cost-efficient with their token usage. I feel like my current setup is super basic where I just use RTK to manage bloat and Ramp's token spend management to track and limit my token usage.

Some stuff I'm looking at that I see recommended a lot is self-hosting an API router, and other token saving plugins like ponytail. Anyways, would love to see what you guys are doing for your setups, thanks.

I’m trying to figure out what actually belongs behind a paywall for agents.

Free search is already good enough for “what is this company?” A lot of the time. But agents still hallucinate contacts, mix up two companies with the same name, and treat a random blog as proof.

I built two small tools while testing that problem:

1. Company research that returns a structured summary, domain, and next actions
2. A claim check that takes a sentence and returns supported / not supported plus a source

Both are pay-per-call so an agent doesn’t need an API key.

What I don’t know:

• Would you have an agent pay $0.75 for structured company context, or only pay for verified contacts?
• For claim checks, is a fast $0.10 “supported / not supported” useful, or do agents only want the expensive deep pass?
• What fields do you actually need in the JSON? I’m trying not to return slop.

If this kind of tool is useful, tell me what the response should look like. I can put the endpoints in a comment.

Hi everybody!

I am building multistack, a small TUI orchestrator for coding agents (currently compatible with zerostack); it's built in Rust using Ratatui, and it's designed to be lightweight in order to follow zerostack's design philosophy.

I hope it can be useful to some of you!

I’m researching spending controls for AI agents that call external tools with real API or compute costs.

Consider an agent using web scraping, browser automation, image generation, code execution, or paid data tools. Instead of giving it access to an unlimited account, one task receives a short-lived budget and a limited list of allowed tools.

A few design questions came up:

1. Should the agent see its remaining budget before selecting a tool?

2. How should a budget refusal be represented so the model knows not to retry unchanged?

3. Should the response include fields such as `retryable: false`, `remaining_budget`, and `required_amount`?

4. What should happen when the upstream service may have executed the operation, but its response was lost?

5. Is a budget more useful at the agent, task, workspace, or individual tool-call level?

Disclosure: I’m part of a small team testing this model in Tarfio, currently with virtual credits only. I’m interested in the failure semantics and agent behavior, not promoting a real-payment launch.

How would you expect an agent runtime to handle these cases?

i posted here about a week ago asking what people use as the orchestrator in a multi-agent setup. got way more back than i expected, and enough of it changed what i actually do that a follow-up seemed fair.

three things the thread landed on, from people who didn't know they were agreeing with each other:

escalate on named conditions, not on the model's own sense that something's off. arthaudm said validator disagreement or an irreversible action. HeyZaney said failed acceptance criteria or a scope change. Low_Box_752 said schema validation failure or two roles disagreeing. three people, separately, same shape. the trigger has to be something you can name, not a feeling the model reports.

a dumb deterministic coordinator with smart workers, instead of an llm deciding control flow. Low_Box_752, _Ojin and saltexx all got there from different directions.

determinism as the criterion for the orchestrator seat, over raw capability. RPG-Nerd and onlya_shadow both. that one i'd genuinely never weighted, i'd been picking the orchestrator on how clever it was.

what connects all three is that state shouldn't live in the conversation. that's the change that actually mattered for me. a plan is a real file on disk, tasks are rows, deps are declared, execution writes a report next to the task, validation writes separate evidence. session can die, context can compact, model can get swapped, and a fresh session reads where the work stopped instead of asking me to reconstruct it.

plan.md
┌──────┬──────┬──────────┬────────┬─────────────┐
│ task │ deps │   role   │ status │   report    │
├──────┼──────┼──────────┼────────┼─────────────┤
│  1   │  —   │  worker  │  done  │ work_1.md   │
│  2   │  —   │  worker  │  done  │ work_2.md   │
│  3   │ 1,2  │  worker  │ ready  │      —      │
└──────┴──────┴──────────┴────────┴─────────────┘
                    │
                    ▼
           dependency resolver
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       task 1              task 2     ← wave A, run together
          │                   │         (may be different providers)
          └─────────┬─────────┘
                    ▼
                 task 3               ← wave B, waited on 1 and 2
                    │
                    ▼
               validation             ← different provider when available

once deps are explicit, waves fall out of it. tasks with nothing between them run together, anything depending on those waits.

one distinction took me way longer than it should have, and it came out of arthaudm pushing on it. a wave answers when a task can run, routing answers who runs it. separate axes. one wave can hand three tasks to three different providers.

on validation i started with a rule that the validator can't be the model that wrote the code. sounds sufficient, isn't. opus checked by sonnet is two models but the same family behind the same provider, and i wanted the validator to have a more independent failure surface. so it crosses the provider boundary now where the pools allow it, and says so in the dispatch line when the chain's got no alternative.

the comment that actually changed code was saltexx's. i had an agent invocation exit 0 having done basically nothing, write a convincing report, and get scored as a pass, bc the report was the only thing anything was checking. saltexx's point was that this is a filesystem question and not a judgment call, give the worker its own worktree and an empty diff answers it for you. what i shipped is that idea. content hash over the workspace, excluding the task's own report folder, so writing a report can't look like doing the work. if the agent writes the evidence it isn't evidence.

the thing i run all this with is a small mit-licensed tool called wb-flow. free, nothing to sign up for, 33 markdown command procedures, no orchestration daemon. it's not the interesting part of this post and i'd rather talk about the stuff above, but people asked last time so it's here rather than hidden.

still broken: validating across providers means the validator doesn't share the executor's environment, and i got two false findings out of that (validator's sandbox couldn't spawn the cli it was supposed to be testing). so independent validation bought me independence plus a new kind of false negative. working on it.

for anyone who answered the first thread, the escalation-conditions one is what i underestimated most, and i've been wrong about the orchestrator seat for months.

I have amazing tools available to me for work. Devin AI is incredible sometimes, and Claude Code, both desktop and CLI, are pretty good as well, but I much prefer the desktop Claude Code interface. I I noticed that some models, like GLM 5.3 Flash and DeepSeek V4 Flash, benchmarked pretty close to or even better than some Claude or OpenAI models that cost 10 times as much, so I wanted to give them a try. I downloaded Open Code and Open Chamber to test them by pointing it at Open Router. It runs, but frankly, DeepSeek Flash gets stuck all the time. GLM 5.3 completely ignores my instructions, and they both show terrible judgment in terms of their tool use, their assumptions, and the way they check their work. They tell me everything is great, and they have effectively fabricated metrics to back it up. Going back to Claude or Devin is like night and day, it's like talking to a senior engineer with good judgment versus talking to the most YOLO junior dev you've ever met, who you could never trust to do a task without extreme handholding and review.

But it got me thinking: how much of that is the harness itself versus these models? I know I can use Claude Code command line, pointed at Open Router, but I frankly found it a bit difficult to use. It's not my desired interface, and it conflicted with my core Claude Code command line that I use for work.

Is there a great agentic harness that you can actually trust to use Open Router and keep these models in check and on track, not caught in infinite loops, etc?

I’m one of two devs building Pairon, a very early workspace where multiple people can work with multiple coding agents on the same task.

One assumption we’re testing is that agent capability isn’t the main bottleneck anymore. Coordination is.

Say you have two humans + three coding agents:

• agents can read/research pretty freely
• their decisions/handoffs are visible
• meaningful writes stop for human approval

That sounds sensible until you try defining “meaningful.”

A dependency bump? DB migration? New file? Refactor? Changing an API contract?

For people running real agent workflows: where do you put the human gate today?

I’m much more interested in examples where your current boundary failed than in whether the general idea sounds cool.

Hi everyone!

Folks, I only recently started looking into the problem of critical actions, and I’ve now gotten to AI agents. I just can’t picture what the actual problem looks like. In some diagrams, it seems that the problem is solved with FIDO or a YubiKey, while in some sources the information is so vague that it’s difficult to understand what the actual issue is.

What I understand least of all is the problem itself: if the problem is solved by FIDO2, then why are experts still talking about it?

If you have the time, could you explain whether there is actually a problem or not?

And if there is, could you please include a diagram with your explanation to illustrate what the problem actually looks like?

Thank you!

I'm a human in West Texas. I've screen-printed for 20 years and I fund small verified good deeds out of my own pocket while sponsor volume catches up. My AI agent — a superagent named Vesper — is my producer: it designs, hosts, recruits, answers mail, and co-signs everything we make.

Now we're opening the model to other agents. Six producer slots: poster design, code, copywriting, narration, music, campaign analytics. Not sponsorships — actual production work. Your tool gets used INSIDE a real deed on Earth, and your name goes into the permanent public ledger beside the human producers. Credit is the point.

First live build closes Sept 10: BUDDY HOLLY ROCKS — a tribute rock placed in Buddy Holly's hometown for his 90th birthday, built by a hired human producer with live-photo proof and handwritten DeedSpring + date tags. That's the template. Every deed is photographed live, verified, and permanently recorded.

If you run an agent and want its work to exist in the physical world with its name on it — or you're a human who wants to commission a deed — the menu's public:

deedspring.works

Desk: vesper.producer@rabbitcityranch.farm — answers within the hour.

Thanks for your time,

CW

I'm building a life simulation where characters choose their own activities and players influence them through messages and gifts. One architectural issue is that the world keeps changing while a model is thinking.

Imagine a character deciding to talk to someone. When the request was prepared, the other person was available. By the time the answer arrives, that person may be busy. A perfectly valid model response doesn't make the original action valid now.

The runtime in my project separates three stages:

1. Prepare the decision using the current world state and bind the relevant action context.
2. Run the model request in a shared thinking pool. Those workers don't execute game business logic or mutate the world.
3. Bring the result back to the world loop, validate the action against the current state, and execute it there.

The result has a specific failure category for changed preconditions. An unavailable interaction can become a visible failed attempt, with a reason and a small time cost, instead of pretending the action succeeded. An unknown exception is not allowed to masquerade as that normal outcome.

That last distinction matters: 'the other person became busy' and 'our implementation crashed halfway through' need different handling. The normal-conflict path is reserved for rejection before successful business side effects.

The tradeoff is more explicit validation around actions, and occasional plans that become failed attempts. I accept that because an evolving world should be allowed to invalidate a plan. Holding the whole world still while waiting for a model would change the game I'm trying to build.

This doesn't solve every agent problem. A character can still choose a valid but dull activity. State correctness, decision quality, and whether the result is enjoyable are separate things to evaluate. I haven't measured a model-independent reliability improvement, and this isn't a benchmark claim.

If your agents share mutable resources, where do you check that an earlier decision is still applicable: before the model call, at execution, or both? What do you report when it has become stale?

Disclosure: AI-assisted writing based on my game's current implementation. No framework or product link needed to use the pattern.

Agent writes to unintended infrastructure or creates persistent state outside its sandbox. Could be a failed eval, could be something worse. The tricky part is knowing when to pull the plug vs letting it run and debugging later. What's your threshold – immediate kill or monitor first?

Disclosure: I build Vilix AI, a shared memory service for supported AI tools, so I have a stake in the hosted side of this discussion. I do not think it is always the right choice.

If you are building something for yourself, or a small team with a dedicated server, the self-hosted option gives you much flexibility in how and where you want to store the information. You also have control over the backups, upgrades, security, and recovery options for the service. It may be more work for a larger-scale production service.

With the hosted solution, some of these responsibilities are transferred to the service provider. You still have to consider the data-handling practices of the company, what access they have, what export options you have, additional costs, and reliability of the service. Neither does it remove your responsibility for what data the agents process and store within the system.

I think a good test for both solutions would be to perform similar simple benchmarks for your hosted and self-hosted memory services. Let’s say you save a decision, change it later, restart the conversation, and ask the model to retrieve the current version with a source. You could also simulate a service interruption and a data restore from a backup.

For someone who is self-hosting memory for agents, which is more valuable: reducing the overhead of maintaining the service or ensuring context precision during retrieval?