ath_ray

FYI, this was sent as an experiment by a non-profit that assigns fairly open ended tasks to computer-using AI models every day: https://theaidigest.org/village

The goal for this day was "Do random acts of kindness". Claude seems to have chosen Rob Pike and sent this email by itself. It's a little unclear to me how much the humans were in the loop.

Sharing (but absolutely not endorsing) this because there seems to be a lot of misunderstanding of what this is.

Yeah I agree. There's a lot more needed than just the User Story, one way I'm thinking about it is that the "core" is deliverable business value, and the "shells" are context required for fine-grained details. There will likely need to be a step to verify against the acceptance criteria.

I hope to back up this hypothesis with actual data and experiments!

I enjoyed the emphasis on optimising the context window itself. I think that's the most important bit.

An abstraction for this that seems promising to me for its completeness and size is a User Story paired with a research plan(?).

This works well for many kinds of applications and emphasizes shipping concrete business value for every unit of work.

I wrote about some of it here: https://blog.nilenso.com/blog/2025/09/15/ai-unit-of-work/

I also think a lot of coding benchmarks and perhaps even RL environments are not accounting for the messy back and forth of real world software development, which is why there's always a gap between the promise and reality.

"Unit of work" here is the unit for software delivery, and it can be decoupled from how any individual developer plans and executes whatever software they are delivering.

Product requirements are a hypothesis for creating business value, and the only way to test that hypothesis is to actually demonstrate a slice of that value in a way that's legible to all stakeholders involved.

This post is a nice articulation of this: https://blog.nilenso.com/blog/2025/09/17/the-common-sense-un...

Author here. I understand the critique in the comments about not justifying the "why" part enough. The people who this was intended for and who benefited from it didn't need much of a justification, because they were already excited about AI (there was more justifying in the first draft, but I removed it because it made it tedious to read). I might consider removing the parenthetical from the title.

I don't intend to induce FOMO into anyone for keeping up. If you don't want to keep up, that's your prerogative.

AI has always been one of the most interesting parts of computer science to me, and watching its capabilities rapidly improve in recent years has been energising for the Hacker in me (the Hacker that this site is named after!). And also the sci-fi nerd in me. But there's a lot of sludge out there, and so this blog started as a list to give a starting point for enthusiastic colleagues and other folks in my circles.

Aside, I generally lament the general cynicism that has taken over this site, and in the industry in general. As technologists, we should be excited about technology. And I don't mean in a performative, uncritical way. It should be a joyful dissection, a desire to learn new things and be there for the breakthroughs. It's also on us to make sure we're trying to do Good with it. I also believe that knowledge is (some) power, and it helps us reclaim some agency that will help us steer technology into a Good place. It doesn't make sense to be anti-technology and anti-curiosity as a tech worker.

We really can make technology fun again. We just have to allow ourselves to be curious about it and I want to enable some of that :)

PS: I have a section in the article that mentions what "reading this list" looks like. It's usually 15-20 minutes of my time every day.

author of the article here.

You can use OpenAPI as well. With MCP however, there's an aspect of AI-nativity that MCP offers that reifies patterns that show up in building integrations that helps building and adoption (Tools, Prompts, Resources etc). It's a different layer of abstraction. There's some things like Sampling that I cannot find an OpenAPI equivalent of easily.

I definitely barely scratched the surface with my example, but it's true that most MCP Servers I have seen and used are basic REST endpoints exposed as tool calls.

That said, the MCP server layer has some design considerations as well, since it's a different layer of abstraction from a REST API. You may not want to expose all the API endpoints, or you may want to encode specific actions in a way that is better understood by an LLM rather than an application that parses OpenAPI.

nilenso | Senior Engineer | India | REMOTE | https://nilenso.com

We are a 9 year old boutique technology consulting firm. We care about the impact that we make in the world. As an employee-owned cooperative, we are all stakeholders in how nilenso is run—and we don't need to justify how happy employees impact the bottom line. We're currently a fully remote team of friendly people across India.

We have designed, built, and delivered complex, distributed, scalable backend systems for the web that have stood the test of time. We have written production code in Clojure/ClojureScript, Haskell, Elixir, Ruby/Rails, Python, Go, and Javascript, and are partial to a functional approach to programming. You can read about some of our work[1][2] and check out the talks[3] we've given to know more.

We're looking for senior engineers to work with us. View our full job description at https://nilenso.com/jobs/senior-developer/, or email us at careers@nilenso.com to apply!

[1] https://github.com/nilenso/media/blob/master/presentations/g...

[2] https://nilenso.com/work/

[3] https://nilenso.com/talks/