Hacker Newsnew | past | comments | ask | show | jobs | submit | ath_ray's commentslogin

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.


Sorry, cannot resist all the AI companies are not "making" profit.

Seriously though, it ignores that words of kindness need a entity that can actually feel expressing them. Automating words of kindness is shallow as the words meaning comes from the sender's feelings.


You cant possibly expect software engineers to be able to understand human emotions and meaning. We built Palantir and all the other fun tech making people's lifes miserable. If software engineers had ethics and would understand human meaning they wouldn't pump out predatory software like its cow milk. Fuck software engineers (excluding all the OSS devs that actually try and make the world a better place).


That's just another distraction from the class war being waged on the un-wealthy. We all contribute to it in small ways while it is being pushed by those with the means. Collectively we love to control others

Palantir wouldn't exist if regular people didn't use it to lookup details on an ex all the time to stalk them /jk.


I got one of these stupid emails too. I’m guessing it spammed a lot of people. I’m not mad at AI, but at the people at this organisation who irresponsibly chose to connect a model to the internet and allow it to do dumb shit like this.


Wait, so someone took the "virus fishtank" from https://xkcd.com/350/ and did it with LLMs instead?


Yup. It's certainly an art project or something. It's like setting a bunch of Markov Chaneys loose on each other to see how insane they go.

…kind of IS setting a bunch of Markov Chaneys loose on each other, and that's pretty much it. We've just never had Chaneys this complicated before. People are watching the sparks, eating popcorn, rooting for MechaHitler.


> "Do random acts of kindness".

Random acts of kindness are only meaningful if they come from a human who had the heart, forethought, and willingness to go out of their way to do something kind for someone else. 'Random acts of kindness' originating from an AI is just spam, plain and simple.

The human race is screwed if connection - the one key thing that makes humans, human - is outsourced partially or wholly to robots who absolutely have no ability to connect, let alone understand, the human experience.


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.


I have had a user story and a research plan and only realized deep in the implementation that a fundamental detail about how the code works was missing (specifically, that types and sdks are generated from OpenAPI spec) - this missing meant the plan was wrong (didn’t read carefully enough) and the implementation was a mess


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!


"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...


That post seems to say that the unit of work must be something customer facing. It even qoutes Kent Beck talking about "Weekly delivery of customer-appreciated value".

There is so much great software in the world that wasn't delivered like that and couldn't be delivered like that: Unix, Microsoft Word, Postgres, AutoCAD, The JVM, Google search, Windows, AWS, Robotics, Calculators ....

The software industry seems to have been captured by contractors who used to deliver CRUD apps and now want to make the whole world in their image and likeness.


That's the point though, thinking of delivery in terms of slices of business value naturally leads one to break application development along those lines. It's very convenient for the stakeholders to see progress mapped out like that, but it tends to lead to fragile and poorly-architected systems that are difficult to change in the future (and therefore not lower-case A agile).


Slicing a cake across layers is about prioritising value and mitigating the risk of building the wrong thing. Most product and feature requirements are hypothesis for creating value, unless that hypothesis has already been validated.

> It's very convenient for the stakeholders to see progress mapped out like that It's important for the business to validate product value. This is not just progress anxiety.

Crafting software to perfection is ultimately a waste if it doesn't provide value to the business or customer. If we are sure we're building the right thing, we can risk more, and spend more of our time building the thing better. Build scrappy first, build confidence in value, and then craft to perfection.

The slices of cake aren't built in isolation. Every time a slice is being worked on, it is integrated back. The cake analogy falls apart here, because cakes (and houses) aren't nearly as malleable as software. We have opportunities to refactor it every step along the way, and change its shape. Yes, sometimes we refactor independent of business value, and I think that's essential too. I don't think the idea that's presented is to have absolutely every slice be vertical, and business / customer facing.


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/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: