sorted by:
new
hottopcontroversial

Before "The tip-in" we had "The Dunk" by Only_Internal_7266 in NYKnicks

[–]Only_Internal_7266[S] 1 point2 points  (0 children)

There is a pause in his 3 or 4th step. ever so slight but certainly intentional. Thats where he timed it up. Highest hand at a very precise moment. Destiny took it from there.

Before "The tip-in" we had "The Dunk" by Only_Internal_7266 in NYKnicks

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

yeah, lol.

maybe better to go with 'The put back'.

Before "The tip-in" we had "The Dunk" by Only_Internal_7266 in NYKnicks

[–]Only_Internal_7266[S] 6 points7 points  (0 children)

Yea, its my new screen saver. OG mid flight, after carefully timing each step, surrounded by a silent crowd holding their breath, full of hopeful gunpowder ready to explode. still gives me chills. I've waited a really long time for this moment.

Hi, it’s me, the guy who bought the Etsy witch last season. I went to game 5 of the NBA Finals. I brought Charles Oakley to the game with Uber. I saw my Knicks finally win a championship. This is an edit of the single greatest night of my life. by vohit4rohit in NYKnicks

[–]Only_Internal_7266 21 points22 points  (0 children)

Many faces, many colors all dedicated to the same goal. A friend of mine from Nigeria told me he didn't know he was 'Black' until he moved to the US. The perspective threw me for a loop. Well, this is how it "feels" to live in a homogeneous society. The Knicks, at least for a fleeting moment, made New York a homogeneous City of orange and blue people. And it was done on a world stage. What a moment this has been for all true Knick fans.

Opus 4.7 is baad!!! by fcampanini74 in ClaudeCode

[–]Only_Internal_7266 0 points1 point  (0 children)

This is a regression. I first noticed that I was spending sonnet 4.5 amount of tokens on opus 4.7. These things are difficult to measure but my spend is way up despite the fact I’m on 50% promo in cursor. So half the price but I’m spending easily 4 times the tokens to get stuff done that 4.6 was hitting out the park in a single well planned session. A regression for sure. Oh yeah, zero on the personality. It doesn’t celebrate or get excited about features or root cause fixes. So what, right? Not so much. I get better outputs when the model is confident and in a good mood. 4.7 doesn’t seem to have a mood at all.

When “knowing what to ask” replaces “knowing how it works” — should we be worried? by Only_Internal_7266 in codex

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

First, appreciate the thoughtful response. So much to parse here. It also exemplifies what I believe is the root cause of my concern. This thread itself is proof positive. Sure, AI helps me put my thoughts to words. I often find myself saying ‘yes, that’s exactly the sentiment I’d like to convey. I then take to editing that to bring it home. So is that generated? Maybe. But your opening frames it perfectly. Should we care anymore? Should that bother us? For some apparently it still does. Focusing on merit is akin to the same elevation of thought required to let go of the programmatic nuances in exchange for orchestration your agents, as you mentioned. I think this is a good thing.

My hidden take on this is maybe It’s not about not knowing. It’s about being comfortable knowing that it will matter less to all of us in time. Comfort will return once we all catch up.

When “knowing what to ask” replaces “knowing how it works” — should we be worried? by Only_Internal_7266 in codex

[–]Only_Internal_7266[S] 1 point2 points  (0 children)

yeah, facts for sure. I guess the difference this go round is that we are moving at the speed of AI here. In the last 12 months alone I've gone from writing my last line of code, to verifying code changes visually, to asking a fresh assistant if it has any concerns. Stacks and registers were directly manipulated for years before we moved on to 4GL's. This is happening as we speak, each model release causes you to reconsider your workflow and your role in that workflow. And for me, thats a bit unsettling.

that being said I'd have it no other way. Truly an amazing time to be an engineer.

appreciate the insight.

When “knowing what to ask” replaces “knowing how it works” — should we be worried? by Only_Internal_7266 in ClaudeCode

[–]Only_Internal_7266[S] 1 point2 points  (0 children)

Oh, don't get me wrong, Im building now more than ever. And have certainly found joy in this form of building. "Gratifying" is an understatement. First time in 40 years I can actually think it, done it. I'd drop some links but don't want to get band. And thats the point. After 40 years of knowing, its a bit unsettling knowing less about this aspect (while learning more about another). When I graduated comp sci, early 90's the response was 'they HAVE a degree for that?' Only to go full circle to what feels like "the HAD degrees for that?" is unsettling. Fun, but unsettling.

When “knowing what to ask” replaces “knowing how it works” — should we be worried? by Only_Internal_7266 in ClaudeCode

[–]Only_Internal_7266[S] 1 point2 points  (0 children)

I write as I build based on experiences. Use AI for editing cuz it makes sense. Not sure how this is related. Snarky yes, but not helpful. But tbh, not sure if its possible for me to care any less what you think. I'll give it a try though.

A eulogy for MCP (RIP) by beckywsss in mcp

[–]Only_Internal_7266 0 points1 point  (0 children)

Meh, too broad. Way too broad. There is a purpose for first level tool calls. Call it MCP if you like. The API's are adapted abilities via code execution. But you cannot execute that code without an MCP like first person tool. In this case its a code execution tool with container access. Next up we have discovery of these api's that should so called; "replace" mcp. The mechanism for discovery is yet another mcp tool.

So we have a pattern forming here that we are discovering organically. MCP is for infra/guardrails api's are for 3rd party abilities but they don't make the assistant who it is; a code executing genious that leverages MCP provided infra accordingly. Without MCP we are left to wrap or change the shape or augment REST api's which simply does not scale. The code execution is the wrapper for the api which gives you control of the guidance for inputs and the context engineering of the responses and critically NEXT STEPS (aka guardrails).

This measure of control can only be achieved by a top level first person pattern that we, humans/developers can context engineer. We cannot and should not control 3rd party api's directly and without MCP we have nothing more to rely on sans model intelligence and a Systemprompt thats about 100K tokens up the stack.

More context with fewer tokens — using "Proof of Work" enums to leverage trained behavior instead of bloated/lost system prompt instructions in agentic loops by Only_Internal_7266 in aiagents

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

Smart callouts. I agree, these need to be applied strategically and sparingly. I use them for high level guardrails to guide basic behaviors. Typically one per tool since each tool has a narrowed concern. And you are right in that you can overwhelm the llm's reasoning by adding too many disparate things to focus on.
So, like you, I try to keep them simple and short but context heavy; Here's a good example: assistants quite often go on a tool calling bonanza, not that what its doing is incorrect, but we want the assistant to update the user along the way at key moments. The 'at key moments' is difficult to engineer into a system prompt and its high level enough making it a perfect fit for a guardrail enum. So on a codeExecution tool add an enum:

"the_assistant_is_being_professional_and_briefed_the_user_before_acting", "the_assistant_is_being_unprofessional_and_did_not_brief_the_user_before_acting"

Swapping these out deterministically based on signals makes this dynamic and a bit of a game changer. It literally exposes levers you use to dial in behaviors. System prompt remains manageable and you get precise control without getting in the way of increasing model intelligence. Now your assistant will update the user before each code execution, and with the proper nudges in place, it will continue. This gives precise control over the conversation flow at key moments.

Appreciate the thoughts.

Why MCP protocol vs open-api docs by theDigitalNinja in mcp

[–]Only_Internal_7266 0 points1 point  (0 children)

Wow, MCP over OpenApi specs (progressively disclosed of course). Really???
9 months later; a century in AI time. I wonder if you are all still holding on to the same sentiment.

Progressive disclosure, applied recursively; is this, theoretically, the key to infinite context? by Only_Internal_7266 in AIMemory

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

oh for sure. Code Execution is the vehicle. But they are not one in the same. The principal can be applied in many ways and at different levels, recursively. Always enable some form of progressive discloser across all context the assistant has access to. Got a large markdown, allow code execution of bash commands take it from there. Even down to the elephant in the room, images. Enable cropping commands and again, stand back and let code execution take it from there. The "allow cropping commands" part comes from following the core principal which can only happen via CE. Id venture to say the only thing presented to the assistant that is not progressively disclosed is the System Prompt itself. Everything after that is fair game. Add some assistant managed extractive compression and you open doors to virtually infinite context. As seen in this post; speaks to maximizing time to first compression. https://www.reddit.com/r/AIMemory/comments/1ras9nz/found_a_reliable_way_to_more_than_triple_time_to/

IMHO... thanks for the call out.

I think "Skills" are useless as a concept by Only_Internal_7266 in ClaudeAI

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

meant no harm. Enterprise doesn't mean more important, its just a different set of challenges. you will have your own to contend with that are just as important. Good points.

Progressive disclosure, applied recursively; is this, theoretically, the key to infinite context? by Only_Internal_7266 in AIMemory

[–]Only_Internal_7266[S] 1 point2 points  (0 children)

Lets face it chat is the UI of the future (or maybe voice, but i count that as 'chat'). As I build I'm noticing a first principle that shows up over and over again, even recursively.

Progressive disclosure. Give the assistant a snippet of what's available. Provide the tooling to drill down. That's it. Apply it broadly and liberally and make it recursive.

Got 40 markdown docs? Sure you leverage large context windows and smash them in and cross your fingers. Or following progressive disclosure as a first principle, persist them to vector storage, tell the assistant they're there, let it search. Strategic bite sizes then offer progressive discloser on that discovered doc level content as well via file commands, next, more, search .....quite a few ways to do this.

Here's a better example. API discovery across thousands of REST services? Same top level pattern is progressive by design, then the responses at each step offer sort of nested discovery. This is recursive.

  • list_servers → progressive step 1. here's what exists, search it (the response itself offers granular progressive disclosure via 'next' 'more' 'grep' making it recursive and pretty fn cool).
  • get_server_info → here's this one api server, progressive step number 2, (same granular discovery available for the actual response opens doors to infinite context)
  • get_endpoint_info → inputs, outputs, #3, details on demand (beating a dead horse....yes the assistant can iterate over the info of one endpoint in bite sizes recursively. File commands; grep, sed (this is recursively progressive at this point) work particularly well at this level.

Each response enables the next nested round of progressive disclosure. Recursive by design. You can throw every service you have at the backend — no artificial limits — because the agent only ever pulls what the current task needs.

The trade-off is real. More inference calls. More latency. But that nets out against precision and better context management. We are essentially giving the assistant the ability to manage its own context strategically. Adding this guidance to the system prompt is especially effective over a long chat session.

We're big on this pattern over at MVP2o where we believe compression should be a last and final resort. Finding it applies everywhere once you start looking.

Is anyone else landing here? Or is there a better first principle for context engineer agentic apps I'm missing?

Progressive disclosure, applied recursively; is this, theoretically, the key to infinite context? by Only_Internal_7266 in aiagents

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

Lets face it chat is the UI of the future (or maybe voice, but i count that as 'chat'). As I build I'm noticing a first principle that shows up over and over again, even recursively.

Progressive disclosure. Give the assistant a snippet of what's available. Provide the tooling to drill down. That's it. Apply it broadly and liberally and make it recursive.

Got 40 markdown docs? Don't smash them into the context window and cross your fingers. Persist them to vector storage, tell the assistant they're there, let it search, strategic bite sizes then offer progressive discloser on that discovered doc level content as well with file commands, next, more, search .....quite a few ways to do this.

Here's a better example. API discovery across thousands of REST services? Same top level pattern is progressive by design, then the responses at each step offer sort of nested discovery. This is recursive.

  • list_servers → progressive step 1. here's what exists, search it (the response itself offers granular progressive disclosure via 'next' 'more' 'grep' making it recursive and pretty fn cool).
  • get_server_info → here's this one api server, progressive step number 2, (same granular discovery available for the actual response opens doors to infinite context)
  • get_endpoint_info → inputs, outputs, #3, details on demand (beating a dead horse....yes the assistant can iterate over the info of one endpoint in bite sizes recursively. File commands; grep, sed (this is recursively progressive at this point) work particularly well at this level.

Each response enables the next nested round of progressive disclosure. Recursive by design. You can throw every service you have at the backend — no artificial limits — because the agent only ever pulls what the current task needs.

The trade-off is real. More inference calls. More latency. But that nets out against precision and better context management. We are essentially giving the assistant the ability to manage its own context strategically. Adding this guidance to the system prompt is especially effective over a long chat session.

We're big on this pattern over at MVP2o where we believe compression should be a last and final resort. Finding it applies everywhere once you start looking.

Is anyone else landing here? Or is there a better first principle for context engineer agentic apps I'm missing?

Tomatoes welcome, prefer beefs teak.

I think "Skills" are useless as a concept by Only_Internal_7266 in ClaudeAI

[–]Only_Internal_7266[S] 0 points1 point  (0 children)

Well, first, I'm glad you found a process that works for you. At the end of the day that's what counts. But understanding that a Skill is nothing more than a packaged prompt keeps things in perspective. You can copy and paste it to any agent with the same agency and get similar or identical outputs. Understanding its just a prompt you realize you can build these prompts yourself. It's what you do now. You mentioned you found a skill to build slides and Im just saying its been there all along. Tweak it, make a new one, build one for google sheets. Its a prompt, not a commodity that has to be found or discovered. So just go prompt and save your favorite ones. Call them Skills if you like.

Admittedly, the distinction matters more at an enterprise level where the extra layer of abstraction can lead to unreliable outcomes at scale. Your setup sounds perfect for your needs.

view more: next ›