HN user

jlcummings

25 karma
Posts0
Comments26
View on HN
No posts found.

Being effective with llm agents requires not just the ability to code or to appreciate nuance with libraries or business rules but to have the ability and proclivity of pedantry. Dad-splain everything always.

And to have boundless contextual awareness… dig a rabbit hole, but beware that you are in your own hole. At this point you can escape the hole but you have to be purposefully aware of what guardrails and ladders you give the agent to evoke action.

The better, more explicit guardrails you provide the more likely the agent is able to do what is expected and honor the scope and context you establish. If you tell it to use silverware to eat, be assured it doesn’t mean to use it appropriately or idiomatically and it will try eating soup with a fork.

Lastly don’t be afraid of commits and checkpoints, or to reject/rollback proposed changes and restate or reset the context. The agent might be the leading actor, but you are the director. When a scene doesn’t play out, try it again after clarification or changing camera perspective or lighting or lines, or cut/replace the scene entirely.

Exactly. Why the fixation on one strategy for handling this not so uncommon scenario. It is so common that handling it should be defacto.

This isn’t a pre-paid gas pump use, but that could be one way to present it. We all want to fill as fast as possible. And if your fill spout can handle top rates, you get top fill rates, until you close in on the hard limit. Then it trickles down to the metered drop. Then stops precisely where it needs to.

By accepting/requesting a hard cap, the provider can make clear that in order to be precise, soft caps will go into affect earlier and induce progressive throttling where applicable. If the throttle doesn’t catch the final milliliter or two of gasoline, before the pump shuts off, the provider can and should just let it go. It’s a loss, but comparatively a figurative drop in the bucket.

The other obvious route is predictive where prior usage guide the guardrails. Ordering two eggs is typical for a single meal. Ordering twelve is not. Ordering three or four is unusual for most but if you are a regular diner your habits will be observable.

Any of this predicated on the provider to want to do something. They seem to lack incentives at this point for making it easy. It is stories like op that I avoid well known problematic providers like Firebase who don’t respect and foster long term relationships.

Likewise, the trivial or novel that you borrow for free isn’t really free when you need to use it suddenly in ways that the license doesn’t permit or it is just technically inconvenient. It is sort of like leasing vs buying, but not really a good analogy.

So far I haven’t seen a comment point this out or suggest similar, so let’s say that instead of trying to maintain an application level list of email addresses that is used in a breach (or for other reasons), rely on the exercising service (email) which by formerly sending a verification email, has a record of the destination at least in a log, and maybe during registration placed in a “verified member” list, all more or less managed within the mail service.

The B52 first was first rolled out for production use on 18 March 1954. The "...long-rifle of the air age..." -- Nathan Twining. It has not been manufactured since 1962. They are still in active military service, the ones that remain, and continue to see upgrades and evolving mission scope. 100 years of service is feasible.

Cost per flying hour of a modern B52: $70,000 [1]

1. https://www.airforcemag.com/article/re-engining-the-b-52/

[dead] 6 years ago

If all you have is a hammer, hit something.

Use the tools you have to identify problems and turn them into opportunities that present high value returns. Be specific and address problems that can be observed to be clearly within measurable bounds of satisfaction. Employ YAGNI.

Today’s biggest concern is specifically about police treatment of the public it serves. The part that is maddening is the poor treatment and poor handling of people they interact with. Equally concerning but less articulated is the polar opposite, where the shining standouts are part of the training set for tuning the model of law enforcement appropriateness and effectiveness.

Maybe, the suggested demise of Equifax, the extreme perpetrator of neglect in this particular case, should lose the ability to print money, much like Symantec and other ssl cert issuers (identity certifies) for their recklessness; perhaps that doesn't go far enough.

Maybe the whole commercial enterprise of credit reporting (and identity verification) needs to be dramatically reworked in a more modern, sane design, with different governance and oversight.

Nitpicking, but removing "business" from the title would fit the article body a bit better. Questioning the viability of potential products and services is far different than evaluation of "business" modes or models. Good products will not save or propel a bad business, but good businesses can thrive on marginal and even terrible products.

This.

The ux [especially] places priority of identity ahead of protected, private conversation and then too broadly encapsulates that information. Secondly, verification is too static, too binary (all or nothing), and too optimistic.

1. To what degree is the line leaky and observable? 2. To what degree are we confirming the conversation participants' identity claims? 3. To what degree is the conversion following normal conversation protocol?

I suspect in some dark, obscure corners, ghastly scenarios far worse have been conceived and considered for contingency purposes. But given supposed reasonable assumptions, many such scenarios are filed somewhere between the circular bin, and long term storage in an nondescript, largely forgotten warehouse, much to the same affect.

The most unfortunate thing about this whole mess is that doubt about otherwise reasonable assumptions has been magnified. It is akin to running continuous integration tests for things such as disk space and basic standard output ... things that normally should be allowed to be taken for granted and should not require such extensive devotion of resources to largely unproductive activities.

The missing link is insurance or a hedge with buyers/students opting for protection from the schools product or service if not delivered in spirit or letter of its premised promise (aka marriage of warranty/collision-comprehensive). Secondly insurance or hedge against themselves as students/buyers for when life happens or they otherwise screw up delaying, discontinuing, rerouting their pursuit (liability).

The fix for one sided finance is to add a second dimension in an equal and opposite direction.

There probably is something to this.

Perhaps if a different, more specific, standard of measure is applied during query, results will be more applicible for the intended purpose.

For instance substituting accomplished for amazing seems to provide more pointed results.

I am pleased to see this as I had been tossing around a similar idea as a first-line alternative method of moderation, where commentary/open collaboration would be restricted to those with skin in the game, so to speak, and more or less without concern for the degree of skin in play.

As far as distribution, is it correct that enrolled partners who host/integrate see a flat 5 percent, the flattr service gets 5, and "creators" see the remainder of 90 percent from a things share of committed flattrs?

Taking that further, I would much rather be used as a fractional miner than provide unhindered, across the board access to personal transportable data and per device usage from the device.

Providing a user with means to throttle or govern the mining seems appropriate even if not explicit. If I am trying to use my device put the virtual mining crew on break and dont check back for at least 20 minutes.

Secondly, exclusive mining rights. Only one app per device, but each developer can ask for a share of the haul. Having more mining apps competing for time will work in no ones favor. As the device owner I should inherently be entitled to a significant share.

An auditible mining client would be valuable. I could certainly see this as something that could eventually fit neatly somewhere between an optional and encouraged part of an AOSP deployment.

Audience matters to the equation.

Is it product motivated? Who is the product for, a consumer or a contributor?

Is it interpretive, art, or otherwise? In other words, as a producer, do you simply have a statement or rhetorical to present?

When conversion rate is no longer relevant, the formula is staggeringly more permissive.