Comments URL: https://news.ycombinator.com/item?id=47132375

Points: 3

# Comments: 1

if someone fresh wants to contribute, now they will have to network before they can write code

honestly i don't see my self networking just so that i can push my code

I think there are valid ways to increase the outcome, like open source projects codifying the focus areas during each month, or verifying the PRs, or making PRs show proof of working etc,... many ways to deter folks who don't want to meaningfully contribute and simply ai generate and push the effort down the real contributors

At Zenact AI, we are building AI agents that test apps like real users. I personally faced this problem at Zomato for over 6 years while handling many bugs and incidents.

We launched recently and already got 35+ signups from leading unicorns & soonicorns in India.

Backed by the Zomato mafia.

Team comes with deep expertise from Zomato’s scale journey.

## Roles:

* Founding Engineers.

* Interns (6 months). Must’ve built serious projects or freelanced early in college.

## Tech Stack:

Golang, Python, Java(5%), Appium, AWS, Docker

## You’ll work on:

* Building the platform from the active feedback from the customers, with heavy focus on improving the end to end latency of testing.

* Fine-tuned vision & reasoning models (currently 92% accuracy vs SOTA ~60%)

* AI agents for mobile testing, reasoning flows.

Apply: shoot a mail to sri@zenact.ai or fill form here: https://forms.gle/yWproMowhA4ZF4gv6

Tech: Golang • Python • AI Agents

At Zenact AI, we are building AI agents that test apps like real users. I personally faced this problem at Zomato for over 6 years while handling many bugs and incidents.

We launched recently and already got 35+ signups from leading unicorns & soonicorns in India.

Backed by the Zomato mafia.

Team comes with deep expertise from Zomato’s scale journey.

Roles:

Founding Engineers.

Interns (6 months). Must’ve built serious projects or freelanced early in college.

You’ll work on:

* Building the platform from the active feedback from the customers, with heavy focus on improving the end to end latency of testing.

* Fine-tuned vision & reasoning models (currently 92% accuracy vs SOTA ~60%)

* AI agents for mobile testing, reasoning flows.

Apply: shoot a mail to sri@zenact.ai or fill form here: https://forms.gle/yWproMowhA4ZF4gv6

thats why we are starting to see a programming of ai, almost like programming building blocks

if there is a pathway for models to get smart enough to know when to trigger these hooks by themselves from system prompt or by default itself, then it wouldn't make sense to have these hooks

so many of the eventually consistent stores reflect so late that its a pain to work with their SDKs

out of curiosity, what kind of metrics or observability do we get for events that got dropped due to some issue

always liked the v0 feature where they notify to top up when the balance runs low

when do apps invoke the credit balance api? before sending events or they poll asynchronously and keep a local cache about the credit balance?

i guess caching would be a bad pattern too as the app may not function immediately after the top up of credits

while I agree to some degree, but when performance comes into picture, what really matters more is normal path vs surprise path rather than happy path vs error path

it's hard to argue what is a happy path in the code, but it's not wrong to say that io.EOF check is a normal path of the code i.e. not a surprise in production. the bad performance of errors.Is is something to be improved upon but it's not a surprise in production when there are a large number of `errors.Is` checks during normal path of the code

now coming to the surprise path of the code, here's where performance gets really important, no one wants their code to suddenly hog 100% CPU because of some special error case - https://blog.cloudflare.com/cloudflare-outage . but such surprise paths often contain a large amount of business logic that weigh much more than how slow errors.Is function is compared to a boolean check

it would be interesting to see where this line of reasoning is valid but IMO performance isn't a good argument against why errors are not normal outcomes of operations in production

but thumbs up for the article, now I know what to reference for backing the below pattern that I often use, when I first saw the errors.Is it was pretty obvious that its going to be slow but just didn't have time to prove it and use below pattern

```

if err != nil && errors.Is(err, x) {

} else if err != nil && errors.Is(err, y) {

} else if err != nil {

    // handling unknown error

```

how are you thinking about capturing such dynamic decisions to choose focus area, happening outside the communication tool - like zoom or meetings etc,... algorithm can be real-time but even with data points from meetings etc,... can it be made in such a real-time?

instagram feed algo is pretty real-time but the number of unique behaviours or behaviours to people ratio is quite low. but I'm guessing in a work environment that ratio or the unique behaviours would be too high for the algo to react quickly, right?

problem is that the most common backpressure techniques like exponential back-off and sending a retry-after time in the response header have constraints on maximum backoff time they can do, in some scenarios that is much much less than the normal.

for example, imagine a scenario where a customer explores 10 items on Amazon, and then finally places an order, so 10rps for the product page and 1 rps for the order page. if order services goes down, slowly the customers get stuck on the order page and even with backpressure, your RPS keeps on growing on the order page. exponential backoff doesn't help as well

while dropping requests is a good idea, but that action is not designed by default every time, systems go into metastable state and you need the ability to control the throughput on producer side

you could solve it by keeping a different layer in between like load balancer or some gateway layer that is resilient against such throughput spikes and will let you control throughput on your service and slowly scale up the throughput as per your requirements (by user or by random)

for frontend devices, it gets exponentially harder to control the throughput. having an independent config API that can control the throughput is the best solution that I came across

for any open source project, the initial adoption during its initial stages would have been that project itself, later on it will be someone with financial incentive to drive adoption but that would still be a niche market and as soon as it starts to show potential aws simply copies and gives it as an offering

all 3 help with the adoption, whether we like it or not, aws has much larger distribution channel and people would rather just use one of the existing vendor than buy a new Nth vendor

exactly :(

I wish passkeys get rolled out quickly across all sites, most people use just 2 or 3 trusted devices 99% of the time.

for those edge cases where you are working on an untrusted device, the passkey on your trusted mobile can help with authentication via Bluetooth or some QR code etc,...

also I feel like, the number of people that hop on the incident call are almost always related to the category of the incident, sure you can always break out to a separate room, but often the person would have already realised the impact and the weight of the incident

it seems so obvious from an Incident Commander perspective but so much goes into this workflow during an incident

* what if the person is a fresher, you are asking him to share screen, debug and perform actions in front of 100 people in the incident call and the anxiety that comes with it

* While IC has much more practice with handling fires continuously, for instance, if there is a fire every week in a 50-team organisation, a specific team would only be seeing their first incident once a year

* Self-consciousness/awareness instantly triggers a flight or fight response from even the most experienced folks

I don't know how other industries handle such a thing, I'm pretty sure even in non-tech there would be a hierarchy for the anomaly response and sometimes leaf level teams might be called to answer questions at top level of the incident response (like a forest fire response, might have a state wide response team and they pulling local response team and making them answer questions) probably they get much more time to prepare than in tech where its a matter of minutes

devices switch off network or slow down etc,... for battery conservation, or when you don't explicitly do the I/O using a dedicated API for it.

new connection setup is a costly operation, the server has to store the state somewhere and when this stateful layer faces any issue, clients keep retrying and timing out. forever stuck on performing this costly operation. it's not like there is an easy way to control the throughput and slowly put the load on database

reliability wise long polling is the best one IME, if event based flow is really important, even then its better to have a 2 layer backend, where frontend does long polling on the 1st layer which then subscribes to websockets to the 2nd layer backend. much better control in terms of reliability

that really changed my life, it was like, how did I waste 28 years of my life without finding this trick :D