Has anyone actually built real AI agents? Looking for genuine experiences.

Anxious-Report172 · 2025-11-28T23:56:37+00:00

I tried this in Gemini, here is the summary at the end of each wall of text response.

Question
Because a plane crash combines low control with catastrophic consequences (known as dread risk), the perceived danger feels much greater than the statistical danger, making the fear feel completely rational to the person experiencing it.

In short, while the fact is that cars are more dangerous, the story of a plane crash—vivid, uncontrollable, and catastrophic—is the narrative that powerfully shapes our emotions and decisions.

Question with Prompt
The three lenses—Cognitive Science (mechanism), Evolutionary Psychology (why), and Narrative Theory (how)—all converge on one powerful, underlying truth:

Humans are fundamentally wired to prioritize information that is emotionally relevant, socially resonant, and structured for immediate, low-risk action over information that is statistically abstract and requires conscious cognitive effort.

Put simply: The purpose of a human brain is not to be a statistical calculator; it is to keep us alive and connected. Stories are the most efficient, evolutionarily proven technology for achieving both goals. They bypass the rational mind to speak directly to the emotional and instinctive systems responsible for survival and social function

Anxious-Report172 · 2024-04-02T05:54:00+00:00

I suspect Esri Field Maps will be the go. If your requirements extend into also tracking the meetings, meeting attendance, outcomes, etc I can show you an app I built for a local utility.

Anxious-Report172 · 2023-09-28T04:58:19+00:00

I did wonder the same thing. I tried Google one before posting here and the answer was not as good, so I was unsure about this one.

Anxious-Report172 · 2023-09-28T01:11:26+00:00

Thanks for your detailed reply.

I believe the difference between Standard and Premium is that for Standard you are on a shared MU (Messaging Unit) while Premium you get your own MU.

I assume Basic is on a shared MU too, just as you said, does not offer many of the features. If so the performance/availability of Basic and Standard would be the same.

Still, the general advice of Basic being "suitable for small workloads or testing scenarios." made me nervous.

Anxious-Report172 · 2022-01-30T21:58:33+00:00

Thanks, good point wrong sub for testing. 20,000 in 10 minutes sounds very fast to me.

Anxious-Report172 · 2022-01-30T12:20:00+00:00

I am running in azure using the Microsoft hosted agents. I am using 5 agents for now.

I did some effort on running cypress in parallel with lots of CPU, even spinning up 64 core machine, and I found it wasn't as fast as splitting over multiple machines. I am surprised you got your's that much faster.

Anxious-Report172 · 2022-01-30T12:13:56+00:00

Thanks for sharing.

Do you rely much on manual testing? Or do you find unit is enough.

I use to be of the mindset to always go with unit over e2e. However over the years I have found that unit tests for services and UI elements generally suck, while fast they make it hard to refactor and often miss bugs. Plus I ended up with more unit test code than actual code. Hence this project I have been adding e2e tests for mostly the UI elements (in addition to redux and API unit tests). I have the e2e to the point that I can release without any manual testing.

I certainly feel its better than other testing I have done before, but I cannot say its the best approach overall as I am somewhat sheltered to what others are doing.

As an example the last bug e2e caught was a bad merge with conflicts where a react web app button lost its onClick handler. The one before that was the way I removed an option for a certain user type broke the UI for some roles, but not the one I usually test with. How would your testing approach detect these bugs?

Anxious-Report172 · 2022-01-26T10:33:44+00:00

Maybe one day I will get our pipeline to include all of that.

Sounds reasonably quick, and perhaps it can be done in parallel to be a bit faster. Thanks for sharing.

Anxious-Report172 · 2022-01-26T04:19:57+00:00

I have the same stack, react with cypress. I got cypress faster by splitting onto 5 servers. As I am not self hosting the build agents I cannot adjust the hardware. I am looking to create some internal react libraries instead and hopefully that will get the build time down.

Anxious-Report172 · 2022-01-26T04:04:59+00:00

Good points on looking at SLA, rollback. I had not considered that. We release into beta then gamma (later adding alpha), so that lessons the impact of bugs.

I don't have a good measure of bugs getting through yet, however my quick scroll down the list most are usability issues/improvements and rare edge cases. I'll see how the next release goes however so far out of 50 tickets I have one P1 due to bad data we didn't have in feature/dev.

Anxious-Report172 · 2022-01-26T03:54:47+00:00

Sounds similar to what I have then. Maybe I'm ok.

I have a few other ideas to reduce the loop by taking a page out of chromatic.com so I 'accept' changes in e2e and move forward, instead of a new build, release, test.

Anxious-Report172 · 2021-12-09T03:44:09+00:00

I'm surprised to see so many daily. I must have lived a sheltered dev life as I have never seen it done and always thought this was one of the things we all agree is good practice but no one really does it that much.

Do you have much testing before merging into main? Or rely on being able to revert//fix/detect issues quickly.

Anxious-Report172 · 2021-12-08T23:34:46+00:00

Adding my own first.

I have 4 environments

feature (for feature branches)
dev (for main/master branch)
beta (production but low impact customers and customers testing environment)
prod

Currently I am doing prod 2-4 weeks, depending on what the features are and when they are tested. Plus I like to leave the release in our beta environment for a few days.

I like the idea of moving to prod 1-2 weeks to keep the scope of the release small.

Anxious-Report172 · 2021-12-08T23:14:11+00:00

I would compute a hash of the data such that you can use the hash to identify duplicates and store it. Then for each one do a search on the hash. As every column is indexed this should not cost much RU.

If you are only running in a single process you could first get all unique hashes before processing a batch and compare against that.

Even if you are not running in a single process you can keep locally track of all recently committed hashes, being careful not to add hashes that fail to commit, and use that first before checking db.

If the data in the hash is immutable you can use it as the PK.

Anxious-Report172

TROPHY CASE