RS
  • Home
  • About
  • Projects
  • Blog
  • Contact
  • Home
  • About
  • Projects
  • Blog
  • Contact
Rikesh Shrestha

Senior Software Engineer building Shopify integrations and AI tooling.

Navigation

  • Home
  • About
  • Projects
  • Blog
  • Contact

Connect

© 2026 Rikesh Shrestha. All rights reserved.

Back to blog
November 8, 2026•10 min read

From Chat to Action: When Machines Stopped Answering and Started Doing

AIAI AgentsPhilosophyFuture of Work

For years, frontend was the part of software I avoided. I could design a database, build an API and reason about queues, but the moment a project needed a polished interface, I slowed to a crawl. CSS that refused to behave. Component libraries with their own dialects. A long list of syntax I always meant to learn properly and never did.

Then I tried Lovable. I described the portfolio I wanted, and it built one. Not a snippet to paste, not advice on which layout to pick, but a working, carefully put-together frontend, with spacing and typography I would have spent weeks getting wrong. What I remember most is the relief. The list of things I had to learn had just become a lot shorter.

I also remember what I did while it worked. I didn't walk away. I sat there and watched the code appear, file after file, as if I needed to see every line to believe it.

That afternoon holds the whole shift I want to think through here. I hadn't asked the machine a question. I had given it a job. And I was finding out, in real time, how much I trusted it to do that job.

For most of its history, we judged AI by what it said. Agents make us judge it by what it does. That moves the important question from "Is it true?" to "Is it right, and who answers for it?"

The oracle age

In 1950, Alan Turing set aside the question "Can machines think?" and proposed a game instead: could a machine hold up its side of a conversation well enough that a judge couldn't tell it from a person? It was a test, not a definition, but it became the yardstick for decades. Intelligence was something you would recognize in talk.

The first famous program to play along came out of MIT in the mid-1960s. Joseph Weizenbaum's ELIZA ran a script called DOCTOR that reflected your words back to you like a therapist. It understood nothing. People confided in it anyway. Our habit of reading a mind into fluent text still carries the program's name: the ELIZA effect. It troubled Weizenbaum enough that ten years later he wrote Computer Power and Human Reason, arguing that there are jobs we should not hand to computers even if they could do them.

After that, conversation stayed hard for a long time. Then came the transformer in 2017, and five years later, on 30 November 2022, ChatGPT. Suddenly the oracle worked. You could ask almost anything and get a fluent, often useful answer.

But an oracle has a fixed shape. It advises; you act. Every answer I got in those first months ended in the same place: me, copying text out of a chat window and into my editor, my terminal or my email. Chat made AI a much better encyclopedia. It did not make it a colleague.

Words that do things

In lectures at Harvard in 1955, later published as How to Do Things with Words, the Oxford philosopher J.L. Austin pointed out something we usually walk straight past. Most sentences describe the world. Some sentences do something. "I do" at a wedding doesn't report a marriage; it makes one. "I bet you a coffee it rains tomorrow" doesn't describe a bet; it places one. Austin called these performatives.

His sharpest point was about failure. A description can be false. A performative can't be false in that way. If the conditions aren't right (the person officiating isn't authorized, the ship has already been named), the act simply misfires. Austin called these failures infelicities.

Now look at 13 June 2023. OpenAI added function calling to its API. Developers could describe tools to the model, and the model would reply not with prose but with structured arguments for calling those tools. It looked like a small developer feature. Philosophically, it was the hinge. The output of a language model could now be wired straight into something that runs. "Book me a flight to Kathmandu on Friday" stopped being a request for information and became an instruction that executes.

The rest followed quickly. In October 2024, Anthropic released computer use, letting a model move a cursor, click and type, and openly described it as experimental. A month later came the Model Context Protocol, a common plug between models and the tools and data they work with. In January 2025, OpenAI's Operator started browsing and buying on people's behalf. By May 2025, with Claude Code generally available, coding agents had become an ordinary part of a developer's day, including mine.

Through Austin's eyes, the shift is clear. A chatbot's output is judged like a statement: true or false, helpful or not. An agent's output is judged like an act: did it go right, or did it misfire? We used to fact-check AI. Now we have to audit it. The prompt has become a performative.

Knowing is not the same as doing

In Book VI of the Nicomachean Ethics, Aristotle separates different kinds of intellectual excellence. Episteme is knowledge of what is general and necessary. Techne is craft: the know-how of making things. Phronesis is practical wisdom: the ability to judge what to do in this situation, for these people, right now. Aristotle insisted that phronesis is about particulars, and that it comes from experience rather than instruction. That, he said, is why the young can be brilliant at mathematics but are rarely wise.

Chat gave us something like episteme on tap. Code generation added techne; Lovable knew how to make a frontend far better than I did. Agents ask for the third thing. Choosing which action to take, knowing when to stop, noticing that the request itself doesn't quite make sense: that is phronesis.

This is where my own experience lands most often: edge cases. An edge case is a particular. The empty list. The customer with two accounts. The timezone that skips an hour. Agents handle the general case beautifully; the particular is where they slip.

To be fair, so did we. Developers have missed edge cases for as long as there has been software. What has changed is how we respond. Now that so much of the work runs through agents, I find myself adding patch after patch, and writing more and more rules into the harness around the agent (instructions, checks, hooks) so that it handles the next similar case. It mostly works. But it's worth noticing what we are doing: trying to install practical wisdom one particular at a time, which is exactly the way Aristotle said it can't be taught.

There is a counterpoint worth taking seriously. John Searle's Chinese Room argument (1980) says that producing the right symbols is not the same as understanding them. Maybe agents never truly understand anything. But a thermostat doesn't understand temperature, and it still runs your heating. The practical question isn't whether the agent understands. It's whether we can trust its judgment in the particulars we haven't thought of yet.

The tool that disappears

Heidegger's famous example is a hammer. While you're hammering, you don't notice the hammer at all. It disappears into the work; he called this being ready-to-hand. You only notice it as a thing, with a weight and a shape, when it breaks, goes missing or gets in the way.

Chat was always the second kind. Every answer sat in front of you, to be read, judged and copied. You couldn't stop looking at it, because looking was the only way to use it.

Agents are designed to be the first kind. The goal is for them to vanish into the work: you describe the outcome, and the steps happen out of sight. Think back to my first afternoon with Lovable. I watched every line because the tool was still new and strange; it hadn't disappeared yet. A few years of agents later, I don't watch every line. Nobody does. That's the point of them.

Here is the paradox. The better an agent works, the less we look at it, and the less we look, the more its failures cost. A broken hammer tells you immediately. An agent that mishandles an edge case often doesn't. The tests pass, the demo works, and the problem quietly waits for a real user.

That's why the best tooling around agents builds in deliberate breakdowns: a permission prompt before anything irreversible, a diff to review before a merge, a checkpoint where the tool becomes visible again. They feel like friction. In Heidegger's terms, they are the moments that make us look.

Who answers for it?

In 2004, long before large language models, the philosopher Andreas Matthias described a "responsibility gap". When learning machines act in ways neither their makers nor their operators can fully predict, our usual ways of assigning responsibility stop working. Read today, it sounds less like philosophy and more like a warning label.

Weizenbaum had drawn a related line in 1976, between deciding, which can be computed, and choosing, which takes judgment. Agents are getting very good at deciding. The real question is how much choosing we let them do.

Make it concrete. The agent sends the email to the wrong client. It merges a pull request that breaks checkout. It pays an invoice twice. Who did it?

My answer is simple: I did. Delegating hands off the work, not the accountability. If I set an agent loose on something, my responsibility starts before it runs, with judging whether that agent is mature enough to do that job without me in the loop. It's the same judgment a team lead makes about a new engineer. The question isn't "Can they write code?" but "Can I let them deploy on a Friday without checking?"

The responsibility gap is real at the level of law and society, and we'll be arguing about it for years. But at my own desk, I don't get to hide in it.

What stays human

If agents take over the execution, what's left for us? Intent, taste, judgment and accountability. You can delegate the doing of almost anything. You can't delegate the owning of it.

In my earlier piece on vibe-coding, I wrote that developers are becoming architects of logic. Agents push that further. We're becoming authors of intent: people whose main job is to say clearly what should happen, to recognize when it hasn't, and to stand behind the result either way.

That isn't a smaller role. Austin's performatives only work when the right person says the right words in the right circumstances. An agent can carry out the act. We are still the ones with the standing to make it.

Back to the screen

I think about that afternoon with Lovable, watching code I didn't write fill the screen. At the time, I thought the story was about relief: one less thing to learn. Now it reads differently. I was watching because some part of me already knew that once the machine could act, the important question was no longer whether its answers were right. It was whether I would still understand what I had asked it to do, and whether I'd notice when it did something else.

We spent seventy years asking whether machines could think. The more urgent question now is whether we're still paying attention to what they do.

A note on process: an AI agent helped me research the sources for this essay. The arguments, the experiences and the mistakes are my own.

Frequently Asked Questions

A chatbot answers: it produces text that you read and then act on yourself. An AI agent acts: it can call tools, run code, browse websites or change files to complete a task you've described. The practical difference is that a chatbot's output is judged as right or wrong, while an agent's output is judged by whether the action it took went well.

Partly. Today's agents can carry out multi-step tasks without a human approving every step, but they work inside limits that people set: which tools they can use, which actions need permission, and when they must stop and ask. How much autonomy to give an agent is a decision, not a fixed property of the technology.

Legally and socially, this is still being worked out; philosophers call it the "responsibility gap." In everyday practice, the person or team who delegated the task should treat themselves as accountable. Delegating to an agent hands off the work, not the responsibility for checking it was the right job to delegate.

Agents are taking over much of the typing, but not the judgment. Developers increasingly spend their time defining intent, reviewing what agents produce, catching edge cases and owning the result. The role is shifting from writing every line to deciding what should be built and making sure it was built right.