You wouldn’t run your SaaS off your laptop.
So why are we doing it with AI?
A lot of the AI automation I see right now still depends on a person sitting in the middle moving information around.
Production throws an error. Someone checks AWS logs, drops them into Claude, figures out what happened and creates a Jira ticket.
Another dev picks up the ticket and has an agent make the change.
Someone reviews it. QA tests it. Maybe DevOps has Codex check the deployment logs over MCP.
Information comes in. A decision gets made. Something happens.
Pretty simple.
Except we keep using humans to connect each step.
We are basically expensive middleware
Most of these systems already have APIs.
AWS knows an error happened.
GitHub knows what changed.
Jira knows what needs to be done.
CI knows whether the tests passed.
The agent can read the code.
So why does someone still need to copy the error out of CloudWatch, explain it to an agent, copy that answer into Jira, then have someone else feed Jira back into another agent?
We’ve automated the tasks without really automating the workflow.
That’s the part I think is going to change.
Where do you actually need a human?
This is probably the harder question.
And every team is going to have a different answer.
Some changes should absolutely require approval. Some companies have compliance requirements. Sometimes the agent is just wrong.
AI output is still pretty meh in plenty of cases.
But it’s getting harder to argue that a human needs to be involved in every step.
For a lot of work, I think you really need one or two human decisions. Did we understand what we are trying to do?
And later:
Did we actually do it?
Everything between those two questions is fair game.
Even the second one gets interesting when the intent is specific enough.
If the requirement says this endpoint needs to return X, these tests need to pass, latency can't increase past Y and this error should stop appearing in the logs... a machine can check most of that. Probably better than someone clicking around dev for ten minutes.
Take a boring production bug
Say a service starts throwing a new error.
That error could kick off a job automatically.
Pull the surrounding logs.
Check what deployed recently.
Look through the relevant code.
Figure out the likely cause.
Create a Jira ticket with the useful context already attached.
Then pick that work up, create the branch, make the change, add the test and open the PR.
Deploy it to dev.
Run the E2E tests.
Check the logs.
See if the original problem is still happening.
Nobody has needed to do anything yet.
Maybe that's where a developer gets involved.
They get the issue, the change, the test results and what happened after deployment.
Approve it or don't.
If you want to be more conservative, put a person at the beginning too. Let them approve the diagnosis before spending tokens and changing code.
If you want to hit the gas, make merge approval the checkpoint.
The exact line isn't really the point.
The interesting part is how much work happens before you need that line at all.
The part we're missing is memory
We already have good agents.
Claude Code can work through a codebase.
Codex can work through a codebase.
MCP gives them access to other systems.
The piece I keep coming back to is what happens when one agent is done.
Where does everything it learned go?
Right now the answer is often a chat window.
Or a terminal.
Or Jira after a developer manually summarizes it.
That's not great.
The error, logs, investigation, decisions, code changes, test results and deployment results should live somewhere the next step can use them.
A database would honestly solve a surprising amount of this.
Call it state, context, memory, whatever.
Just stop making a person carry it around.
This is a lot of what I've been thinking about while setting up my automations on SchemaBounce. I started out thinking about where agents do work. Increasingly I think the more interesting problem is the infrastructure that lets them keep doing work without needing somebody to babysit every transition.
Which gets me back to the laptop
You can build almost all of this locally today.
A couple MCP servers, Claude Code or Codex, some AWS access, GitHub, Jira and a little glue code.
I've done versions of it. A lot of developers have.
But eventually you end up with a pretty funny architecture:
Your laptop has become production infrastructure.
Close the lid and your automation is gone.
VPN drops? Gone.
Token expires? Gone.
Someone else wants to use it? Have fun recreating your setup.
Want to know exactly why an agent made a decision three weeks ago? Hopefully you kept the terminal open.
Once these things are actually doing parts of the SDLC, they probably need the same boring stuff we expect from everything else we run.
Hosted somewhere stable.
Scoped credentials.
Persistent state.
Logs.
Retries.
Timeouts.
Versioned workflows.
An audit trail.
Observability.
Not because any of that is exciting.
Because the goal shouldn't be to build the world's coolest prompt running on a MacBook.
The interesting version is when an error can happen at 2 AM, the system can investigate it, put together a fix, prove what it tested, and have something useful waiting for a developer in the morning.
No copy/paste required.