No pull requests, no code review. We push to main. Our agents read production logs, watch deploys, grant feature flags, and check their own work end to end. Here's how we do that:

On YouTube:

pleasee make a video about the No PRs things specifically, still can't wrap my head around that. Do you squash before push? does the agent just decide to push? or you? do you have instant rollbacks? when/where do ci checks/tests run? would love to understand better!

It's partly in the talk, no? But I guess we should talk more about that trunk-based development. - Squash vs. no squash: who cares anymore, really? We keep changes small and ship/push often. So no one pushes 38 commits at once. - Decision: user decides to push. Sometimes agent auto-pushes as follow-up. - We have rollbacks, yes. But we also fix-forward a lot since a lot of stuff is behind feature flags. Push behind feature flag, monitor prod, test prod, remove feature flag. - CI checks/tests run in agent, but we also push and then it runs on GitHub actions/buildkite. - Deploy happens after push.

Ok that does make it a bit more clear, thanks! Do you review each-others work at all? Are there parts of the app that you want sign off on from at least another person or is everybody on the same level enough for this to not matter? Do you just share a session in those cases? Do you never look at code anymore at all? Or do you still do that within a session.

Did you watch the talk? 😎 - We use Multiplayer threads to review each others work, if necessary. - We share a lot of work in Slack and ask for feedback - We give each other a lot of feedback - We don't review each others code - We review load-bearing parts of the codebase We're a small team that has built up trust and instincts to work well with each other. We haven't hired an engineer to the team since February. We don't plan to hire. We think this is more how the companies of the future operate than the model used in the last 20 years.

yeah sorry, probably went through some parts a bit too fast. Taking notes! thanks for the follow up, imo this change in development is the most interesting thing in software development at the moment. Convincing my devops colleague right now we should try this 🫡

Yeah, I'll record something, or @sqs and I talk about it on next podcast. IMHO you need to rethink all processes. Pull requests etc. don't make a lot of sense anymore

ok final question; what about "non-technical"/marketing/sales roles shipping? Are you ever gonna hire people that you don't trust to ship straight to prod? even if it's just at the beginning. Is there still a place for "juniors", are you gonna have some approval process in place for them?

I'd slowly get the non-technical/marketing/sales people up to speed. If they don't work on the core product, why should they modify the core product? We don't have anyone on the team that's non-technical but we do have people on the team that don't work on the core product. They still ship things to our admin backend and whatnot, that also goes to main. "Are you ever gonna hire people that you don't trust to ship straight to prod?" You have to build trust. So I would say they should ask agents to review their code, they should ask for feedback if they don't feel confident in their changes, then ship small things to get your feet wet. Why would I "hire people that I don't trust to ship straight to prod" and then have them push to prod? Yeah, there's a place for juniors. Like I said: we ask for feedback on approaches many times. We share multiplayer threads and collaborate in them. We share feature-flagged WIP work and collect ideas. We write news posts before code is written and figure out what we want to build.

the plugin ui that lets agents grant feature flags, email users, or just about anything else imaginable, is one of my current favourite things

@connorado Awesome video Thorsten!!

wtf. I was literally googling about exactly this few hours ago

my agents still need a lot of nudging, would love to see how yours skip that

It's in the talk :)

Can you please put this on youtube if it isn't already?

Legend

How much access do your agents have to production infra/data?

It's in the talk: they can read-only access some logs, and then they need to ask for permissions every time they need more access. If they want to run a deploy or read database or whatever.

inb4 "hurr but you sell ai tools hurrr"

This is the most obvious way forward. I'm pushing to get a pilot program doing this at my large corporate job.

Should start using orbs :)

I'll try

All cool and all, but your cli oauth flow is broken if you sign up via ChatGPT login. It sends you to a page without the ChatGPT login option, even when you are already logged into the amp web app.

Damn. Really good stuff, man. Thanks.

I've been doing the irrefutable proof bit. Game changer.

Awesome video - love your videos and the amp podcast! A few questions: 1. What do you guys use for creating and storing/ making traces observable? axiom? 2. Do you run all tests for each push or allow the agent to pick? if the latter, do you get the agent to visually show you which it ran/ which it didn’t, with the results behind each? if yes, could you show the ui you use for that? 3. What test types do you still mainly have in your test suite? e2e tests? unit tests? 4. Do you notice a difference in code output quality depending on code language? do you use effect-ts or what’s the main language? 5. Do you use different visual abstractions to have insight on the code? like module viewers, dependency graphs, data structure graphs etc.? 6. Would you be up to showing 1-2 AGENTS.md files as examples?

Great video, btw. The trunk based default in Amp has sort of nudged me to get my tooling spun up to make our flags and testing bullet proof to switch over.

Great walkthrough, Thorsten. How would you propose teams move to this when they are stuck in agile/sprint methodologies. How do you guys know what to work on next in terms of features and task tracking?

what catches the change that's green on every check but solves the wrong problem? that's the one i'd be nervous pushing straight to main

So, no CI/CD pipelines? Just everything locally?

No, nothing locally. Watch the talk :)

Sorry, I meant locally in the orb, but I am rewatching the video and reading your comments with others. All your YouTube videos are on Notebook LLM, so I can ask all my questions, lol.

That was super helpful! Thank you! Keep them coming.

@beyang what subscription and models are used

works until the code moves money. auditors want a human name on every approval

Agents granting feature flags is the step I'd want to see the guard on. Can an agent roll a flag out past internal users by itself, or does a person approve that?

I just love how you embraced the term "load-bearing" and not shy away from it!

In an enterprise team, "no code review" is the first thing governance kills, even when the agent checks its own work end to end. Curious what made you trust it: the feature flags, fast rollback, or the agents' own checks?

I'm not quite ready to abandon PRs, but the direction is familiar. The more autonomy I give my agents, the more important it becomes to define what earns a GO and what triggers a HOLD. I've become slightly obsessed with that distinction.

Thanks for the clear explanation, Thorsten! I’m curious how amp organizes work beyond Orbs. How do you plan tasks, assign responsibilities, and decide who’s in charge of what? Is there a video/blogpost showing your workflow?

Not yet! We should probably record one soon

When can one email belong to multiple workspaces ?

I will have to give it a try.

Amazing, can you share a bit more about your QA and release process? what happens after you push to main? I think also coverage doesn’t matter anymore

@filipsodic

who rolls it back when the agent checking its own work decides everything was fine

@bot 精读后发送给我

do the agents push migrations too? that's the one deploy you can't undo by pushing again

How do I make the new thread in my runner use env and tools from the project's .envrc which starts nix dev shell?

It should work if you start the runner in the nix dev shell itself, right?

Yes it works like that, but i thought there should be a single runner (managed by amp desktop app) for the machine where you then add dirs to it? I guess there is no way to do this with a single runner?

Yeah, that's different. There's currently no way to do that, sorry. We've made Amp source those env files in the past, but it lead to a bunch of problems for people who want the opposite. Let me think about that a bit.

Do you need the nix env only for bash tool calls or do you need it for starting MCP servers too?

@nickkadutskyi hmm, mcp servers are separate processes, so i'd think they need the env too

@nickkadutskyi Sure but depends on the Nix setup, I think

Add no unit tests to the list