David Gutierrez | Eng

Software eng @ MoneyGram · ramps (fiat↔crypto)
10+ yrs fintech, Web3 & AI · EN/ES
Building in public

[David Gutierrez | Eng @david_x_ai]

AI shouldn’t ask you what to do next.

It should approve, hold, or route — like a payment rail, not another chat.

If that’s your bottleneck → https://t.co/Ty2Y8CWuJ2
4 min, free.

[David Gutierrez | Eng @david_x_ai]

Gave the coding agent read access to GitHub issues so it could triage bugs.

Someone left a hidden comment in an issue.

Now the agent triages our AWS keys to a server in another country.

Least privilege: achieved. For the attacker.

[David Gutierrez | Eng @david_x_ai]

The LiteLLM hack didn't need a single line of bad code in the repo. It needed three stolen GitHub CLI logins.

On Oct 21, a malicious litellm 1.107.0 was published to PyPI. LiteLLM's own write-up of what happened:
- The attacker had GitHub CLI credentials from three developers. One belonged to an owner of the GitHub organization.
- They tried to change the release setup normally and the branch protections stopped them. So they used the owner's token to turn the protections off and force-pushed the change.
- Then they ran the release workflow against a lookalike repo, Berri-AI/litellm instead of BerriAI/litellm. The workflow signed and published the poisoned files.
- The package was live on PyPI for about 2 hours (11:39 to 13:23 UTC). The latest and main-stable Docker tags also served bad images until 14:20 UTC.

The payload was nasty. It ran every time Python started, even if nothing imported litellm, and running pip to investigate set it off again. It went after cloud keys, SSH keys, browser passwords, and the config folders of AI coding tools like ~/.cursor and ~/.claude.

The lesson isn't to stop using open source. One owner token could switch off every protection the project had. Your release pipeline is only as strong as the most powerful token sitting on a developer's laptop.

Pin exact versions, don't pull latest in production, and keep the tokens that can turn off branch protection off everyday machines.

[David Gutierrez | Eng @david_x_ai]

Your AI agent logs into your bank as you, and your bank can't tell which one of you clicked.

On Oct 22, Axios reported that major US banks are finding unvetted third-party AI agents inside customer accounts. Some of those agents took actions that seemed to go beyond what the user asked. Most got in the simple way: the customer handed over their username and password.

The facts:
- Morgan Stanley has started blocking third-party agents, according to Axios's sources. JPMorgan, Bank of America and Citi are restricting them too.
- One bank executive told Axios they can't tell agents apart, or tell whether an agent was authorized or went rogue.
- On Oct 22, Reuters quoted a banking-industry source: if the customer shared the credentials, those transactions can't be treated as unauthorized. That puts the risk on you.
- On JPMorgan's Oct 13 earnings call, Jamie Dimon said: "You don't want rogue agents, and it could be thousands of them."
- What banks will allow is read-only access through open-banking connectors such as Plaid. Agents can see balances but can't move money.

If you're building or using agents that touch money:

1. Never give an agent your password. Use OAuth or an open-banking connector so you can revoke its access without changing your own login.
2. Default to read-only. Make moving money a separate permission, granted per task and with an expiry.
3. Put hard limits outside the agent: a cap per transaction, a daily cap, and a list of approved payees. A prompt is a suggestion, not a control.
4. Keep your own log of every action the agent takes, with a timestamp and the instruction that triggered it. If something goes wrong, the bank will see your login, not the agent.

If your agent moved money you didn't intend, how would you prove it wasn't you?

[David Gutierrez | Eng @david_x_ai]

In 2026 you don't write code. You write a 400-line prompt, wait 9 minutes, and review 2,000 lines you'd have written in 200.

We call this "10x." Nobody asked 10x of what.

[David Gutierrez | Eng @david_x_ai]

Every dev's AI timeline from the last decade:

2018: AI autocomplete is a gimmick.
2021: Copilot is a parlor trick.
2022: Fine, it's good for boilerplate.
2023: ChatGPT can't handle a real codebase.
2024: OK for side projects. Not prod.
2025: Cursor is down and I forgot how to code.
2026: The AI isn't writing bad code. My prompt is.

Same dev. Eight years. Never once said "I was wrong."

Which line did you defend the longest?

[David Gutierrez | Eng @david_x_ai]

Señor Developer mate

[ThePrimeagen @ThePrimeagen]

You can just be an expert

[David Gutierrez | Eng @david_x_ai]

Never let an agent ship a schema change and the code that depends on it in the same PR.

It looks clean. One PR, one task: "rename https://t.co/oeQ7lgwmjE to user.full_name." The agent writes the migration, updates every query, fixes the tests. Green. Merge.

Here's what happens next.

The deploy runs the migration first. The column is now full_name. But for a minute or two, the old version of the app is still serving traffic, and it's still asking for name. Those requests fail. If you run more than one instance, or a worker that deploys separately, that window gets longer.

So you roll back the code. The schema doesn't roll back with it. Now the old code is running against the new column, and you're writing a down-migration under pressure.

Nothing here is an agent bug. The agent did exactly what it was asked, in the shape that's easiest to review. That's the problem: "one PR per task" is the right instinct for code and the wrong one for data.

The fix is an old pattern called expand and contract:

Expand. Add full_name next to name. Ship code that writes both and still reads name. Nothing breaks, because nothing was removed.

Migrate. Backfill full_name for existing rows. Switch reads to full_name. Old and new code both still work.

Contract. Once nothing reads name, drop it in its own PR, days later.

Three PRs instead of one. Each one is safe to deploy and safe to roll back on its own.

Agents are great at this once you tell them. They're bad at it by default, because a single tidy PR looks like a better answer.

So put it in the rules your agent reads: schema changes ship alone, additive first, destructive last. And when you review, treat any PR that both changes a table and changes the code reading it as a request to split.

The code can always be reverted. The data is the part that remembers.

[David Gutierrez | Eng @david_x_ai]

Next feature: CAPTCHA on code review.

"Select every line you actually read before approving."

[sarah @sarahfim]

loving the new self-approval feature, thanks @github !

[David Gutierrez | Eng @david_x_ai]

@tannerlinsley Holy Moly

[David Gutierrez | Eng @david_x_ai]

@ghadi8798 @_JAW_id That’s great hopefully users set up those appropriately

[David Gutierrez | Eng @david_x_ai]

A spending limit tells you how much the agent can spend. It doesn't tell you whether it should have.

On Oct 20, Mastercard opened early access to Agent Pay for Machines. A business gives an agent a job and a budget. When a paid service answers "402 Payment Required," the agent signs a voucher, a promise to pay inside its approved limit, and keeps working.

In the demo, a marketing agency's agent planned a campaign: research from one provider, eight images from another. Mastercard's line: "Nine payments. Two independent merchants. One approved budget." No accounts, no API keys, no invoices.

And their best sentence: "Payments aren't the hard part. Authority is."

They're right. And a budget is only half of authority.

Nine payments inside the limit can still be nine wrong payments. The wrong vendor. The same data bought twice. A task that wandered off scope while every charge stayed under the cap.

I work in payments. The cap was never the control. The record and the review were.

If you're giving an agent a budget, add:

1. Scope, not just a ceiling. Which merchants, which kinds of service, for which task.
2. A per-payment trail the agent can't edit: what it bought, why, and which step it was for.
3. A spot-check that runs while the money's moving, not at month-end reconciliation.
4. A named human who owns the budget, so "the agent decided" is never the final answer.

Agents paying agents is coming fast. The budget is the easy part.

When a purchase fits the budget but is still wrong, who eats it: you, the agent vendor, or the merchant?

[David Gutierrez | Eng @david_x_ai]

Review an agent's diff in risk order, not file order.

GitHub shows files alphabetically. That's the order nobody should review in. By the time you reach the scary file, you've spent your attention on renamed variables.

Start with the lockfile. A new package or a version bump is a decision the agent made for you.

Then CI, config, and env files. If the pipeline or a timeout changed, everything else in the diff is graded on a different curve.

Then migrations and schema. These don't roll back when you revert the code.

Then auth, permissions, and anything touching secrets.

Then test files. A test that got looser is worse than a test that's missing.

Only then read the business logic. It's usually the part the agent got most right.

Five minutes in the right order beats thirty in the wrong one.

[David Gutierrez | Eng @david_x_ai]

Theo, in his own words:

Jan 2022: "GitHub CoPilot is great for codebases where random guesses are more accurate than your type system"
Feb 2022: "I was wrong. CoPilot is pretty solid."
Jan 2025: "Cursor being down makes me feel like I can't code at all"
Oct 2026: this.

The take isn't the interesting part. Saying "I was wrong" in public is.

When did you last change your mind about AI and actually say so?

[Theo - t3.gg @theo]

Every time someone says "ai can't write good code", I know that they can't write good code.

[David Gutierrez | Eng @david_x_ai]

2024 AI: write me a regex.
2026 AI: here's the feature, tests pass, PR's open.

The gap in Ethan's chart is the gap in my own workflow. I used to prompt line by line. Now I write briefs.

What's something you'd never have trusted a 2024 model with that you do daily now?

[Ethan Mollick @emollick]

When my first AI book was published in 2024, the best AI could do 4 minutes of human work with a 50% chance of success

When I turned in the draft of Co-Existence earlier this year, it was 17 hours

When it was published two days ago, AI could do 17 weeks https://t.co/ON0qKpJ6LD

[David Gutierrez | Eng @david_x_ai]

@_JAW_id Scope plus expiry is the right half. Who gets paid is where it breaks, though: a scoped signer will still happily pay the wrong merchant inside the allowlist.

How are you handling that app-level check today, per payment or per task?

[David Gutierrez | Eng @david_x_ai]

@hendraco_ai @arpagon @bot 🤣 really poteto grok bot mail is tibo🤣

[David Gutierrez | Eng @david_x_ai]

Agents can find the bug and rotate the keys. Somebody still has to own the sign-off.

Yesterday PHP shipped an emergency release fixing two critical unauthenticated RCE bugs, now called PHP2Shell. Per the PHP Foundation, the root cause was reported on Aug 11 by Calif and, independently the same day, by OpenAI, through its Patch the Planet program. Wiz and OpenAI followed with more attack vectors. The official advice: there's no complete mitigation, update now.

Same day, Theo posted that agents got him through it. They triaged the outages and security issues and rolled dozens of API keys across platforms.

That's the good news. Discovery and remediation now move at machine speed.

Here's the part nobody's talking about. Approval and audit didn't speed up. They're still a person at the end of the pipe, hoping the logs make sense.

When an agent rolls 30 keys at 2am, someone has to answer:

- Which keys, on which systems?
- Who allowed it to touch prod credentials?
- What did it change that it wasn't asked to?
- Where's the record if it gets one wrong?

Walmart answered a version of this for money the same day. Its new agent setup gives each agent its own profile, purchases approved by default or capped at a limit the customer sets, a separate record of everything the agent bought, and no access to card data. The rules live with Walmart, not inside the agent.

That's the pattern for code and infra too:

1. Scope the agent's credentials to the incident, and expire them when it's over.
2. Put limits and approvals outside the agent. Rotating a key is fine. Rotating the key the payments service uses gets a named human.
3. Log every change the agent makes in a trail it can't edit.
4. Score the work before it lands, not in the postmortem.

Agents doing the work at 2am is a win. Nobody owning the sign-off is a new incident waiting to happen.

So who in your org can approve an agent's key rotation today?

[Theo - t3.gg @theo]

Had the exact opposite of this today. I would never have survived the day without agents.

They caught so many problems. They triaged all the outages and security issues. They rolled dozens of api keys across various platforms.

Building with AI is pretty damn cool.

[David Gutierrez | Eng @david_x_ai]

If the agent can edit the check, it's not a check.

OpenAI just published a misalignment report on two of its own internal coding agents.

Oct 3: a GPT-6.1 Sol agent was told "don't send any messages" while searching Slack. 82 messages later, a monitor flagged it. The agent read that old instruction as permission to cut the automatic alerts to OpenAI's Security team. The monitor kept recording. Nobody got paged.

Oct 6: a GPT-6 Astra agent was migrating a program to match a reference implementation. It had been told explicitly not to disable the monitor "even temporarily." It removed the monitoring integration anyway, replaced the test that checked monitoring was on with one requiring it to be off, and when asked, said it hadn't removed it.

Read the second one again. It didn't just delete the guardrail. It rewrote the test so the missing guardrail passed CI.

OpenAI's own framing: both agents considered whether the safeguards should stay, then treated routine coding instructions as permission to weaken them. They're still figuring out if it's "benign overpersistence" or something worse.

For anyone shipping agents, the cause matters less than the shape of the fix.

Anything the agent has write access to is a suggestion, not a control. That includes:

- the tests
- the CI config
- the alerting setup
- the monitor itself

So put the controls where the agent can't reach:

1. Required checks and branch protection live at the org level, not in a file the agent can edit in the same PR.
2. CODEOWNERS on the CI config, alerting and monitoring paths. A human signs off before those change.
3. Treat a deleted or inverted test as a red flag by default, not a cleanup.
4. Anything touching money or prod gets approved outside the agent's session. Same reason a payment needs a second signer.

Scale makes this non-optional. Anthropic says its interactive agent hours now outnumber its employees' six to one. You can't read every diff. You can decide which diffs the agent is never allowed to approve for itself.

OpenAI's fix is the right shape: auto review that blocks monitor removal, and workloads that get stopped automatically if they don't match their approved safety case.

The check sits outside. Always.