{"slug": "give-up-a-little-speed-get-your-team-back", "title": "Give up a little speed, get your team back", "summary": "Evil Martians argues that agentic AI development has eroded team collaboration by enabling individuals to work at unprecedented speed, and proposes distinguishing between 'learning work' (experiments) and 'lasting work' (production-quality code) to restore effective teamwork. The post suggests that teams must explicitly label which type of work is being requested to avoid confusion and misaligned expectations.", "body_md": "Agentic development has brought new capabilities and unprecedented speed. But this speed has all but disintegrated our ability to collaborate. We pretend it’s fine, but look around. We toss 50-100 PRs per day at each other and call this teamwork? Part of what broke is that, because two very different kinds of work produce results in the same form, code, we keep mistaking one for the other. If you’re starting to feel lonely amid a swarm of agreeable robots, this conversation is for you. Let’s search for ways to work with people again. This post offers a perspective and practical ideas that we’ve tried at Evil Martians.\n\n**In this post:**\n\nHow much of a team’s productivity runs through collaboration varies. For some teams, it’s most of the job. On others the real work is individual and collaboration is mechanics: handoffs, reviews, keeping each other unblocked. Wherever your team’s situation, the same tradeoff holds. More effort on collaboration means less left for your own work, and vice versa.\n\nNow, suddenly, AI has turned us into super-ICs (individual contributors). Oh, the things we can do, as long as we can carve out the time! True builders, especially non-engineers or “long-ago-engineers”, are hooked. You used to feel hopeless without engineers, and could never afford enough of their help. Now you’re empowered, fearless, and building at the speed of thought (well, almost).\n\nBut you begin to feel what’s missing: our ability to collaborate. How can we work together while moving at these wild new speeds? Who would even bother pulling in a teammate who’s out of context, when getting them there takes 10x longer than working the problem through with an agent that already has the whole thread?\n\nAnd there’s more. From inside all that speed, the engineers start to look slow. You shipped five experiments this week; they’re still on the thing they picked up on Monday. Why can’t they keep up?\n\nThey can. They’re doing a different kind of work.\n\n## The types of work\n\nLet’s look at two types of work that produce a similar artifact: *code*. (They are otherwise unrelated activities.)\n\n**Learning work** helps us test hypotheses and find answers.\n\n- Will people react to this message?\n- Will customers use this feature?\n- Is this approach even feasible?\n\nA lot of this work was previously done with different artifacts like no-code automations, wireframes, prototypes. Code was too expensive for this. Agents made experimenting, and doing all kinds of learning work in code, almost free. But the nature of this work is the same: to test, learn, and explore.\n\n**Lasting work** is a different kind of work. It helps us serve our customers today with quality and confidence, while also helping *the organization we’ll become in the future* serve its future customers. (If at some point in the future we say “we can no longer build on top of what we’ve built so far,” it means we failed.)\n\nIn other words, the outcome of this work is quality and confidence today, plus future productivity. Code is just the medium. The nature of this work is architecture and craftsmanship, the outcome is really business.\n\nBecause both types of work produce code, we constantly confuse them. This confusion costs us in both directions.\n\nLasting work will clearly always be slower than learning work. But when nobody says which one is on the table, this slowness reads as a personality flaw.\n\nFor instance, say you ask for lasting work, but get learning work: you inherit a prototype that’s already serving customers, and nobody can tell you which parts were decisions and which were guesses.\n\nAsk for learning work, and get lasting work: you’re waiting three weeks for an answer you needed on Tuesday.\n\nSo say which one it is! Engineers can nail both types of work, but the approach to each is different.\n\nAn expert used to doing lasting work for decades would be wary of taking a task in an uncharted area. But we’re living through a big technological shift, so it’s natural that there’s more demand for learning work in deeply technical areas. Searching for the new boundaries of what’s possible, engineers can try on a “newbie” hat again, which is exciting for many.\n\nAs long as this work is marked as learning, not lasting, engineers can explore those new horizons confidently.\n\nNon-engineers are better suited for learning work, of course, and if that work can be contained in a secure perimeter, everyone should be happy, right? Well, the problem is, we (of course) want to have it all. We want our successful experiments (vibe code from non-engineers) to graduate into lasting product features, and we also want our experiments running inside our product, not separate from it. (And this is not about “let’s clean up the vibe code.“)\n\nWe want to continuously work together: non-engineers running experiments, engineers building confidence and quality in the product and future productivity for the whole team.\n\nAs mentioned, collaboration costs something: you give up some of your freedom and speed. Nothing in the world beats the freedom and speed of pushing code straight into main. But you’re on your own.\n\nSo, if you want to have a team, let’s look at what works.\n\n## Collaboration recipe #1: separation and boundaries\n\nIf we can define a “safe perimeter” for learning and experimental work, then build the tooling to ensure minimal safety and quality gates, it’s great. The role of engineers is to build tooling. The role of non-engineers is to use it as prescribed, which means giving up a little bit of freedom and a little bit of speed.\n\nExample: marketing experiments with static websites and, perhaps, read-only use of data. The role of engineers and designers is to build a design and component system, well-documented and maintained. Build an agentic harness to enforce the use of this system, with deterministic linters that give actionable feedback to agents. Plus observability and alerting for violations, to humans. A process for submitting missing components to the DX (developer experience) team. A foolproof API.\n\nEach piece of that perimeter deserves its own post, we’re writing them, and two are out already:\n\nInside this perimeter, non-engineers and engineers alike can do learning work at the same super-high speed. Nobody gives guarantees, and everybody’s sprinting forward to accelerate learning. Harmony is possible.\n\nIt’s hardly ever enough.\n\nThe experiments that fail die inside the perimeter and cost nobody anything. The experiments that work, we’ll want out. That’s the whole point of running them: eventually, we want successful experiments to become real product features. And that’s exactly where the safe perimeter stops helping.\n\n## Collaboration recipe #2: shared rules\n\nWhat gets a successful experiment across that line is boring, and it costs you something: everyone works under the same rules.\n\nI’m just kidding. *Everyone’s AI works under the same rules*. Every AI agent should load the same skills, pass the same checks before merge, and go through the same review process, whether the PR comes from the CTO or from the engineer who will maintain the code for years. When experimental work is created under the same product rules, it’s much easier to promote into lasting work. This avoids any rewrite, and handoff becomes a review and discussion instead.\n\nYes, this makes your agents slower. You’ll feel it and want to route around it since pushing straight to main is always faster.\n\nFor everything that human team work will cost, this one is still worth it. In return, you get work that someone else can understand, continue, and maintain.\n\n## Collaboration recipe #3: log and share intent\n\nShared rules are great, but something is still missing.\n\n**Example**: a “long-ago-engineer” C-level is building an experiment. An engineer is needed to promote the successful experiments into moderately lasting work. They operate at different wavelengths. Collaboration is tricky. Even staying on top of what’s happening is a challenge, when the C-level ships 50 PRs per day.\n\nThat C-level, doing learning work non-stop since last Christmas in a historic rush for dopamine? It’s me. And it’s our customers too. And the engineer in this picture? It’s practically every Martian.\n\nI don’t have a silver bullet, but here is what helps and what costs almost nothing: **a log of intent**.\n\nSo, I have my agents keep a diary. This means one short list per day of work, chronological, each line tagged with the PR it turned into. The lines with no tag are the interesting part.\n\nHere’s a real one, from a conference app I’ve been building:\n\n```\n## Tue Aug 18\n\n- a coin leaderboard, tucked into the pier footer links `#58`\n- every heart and coin emoji replaced by our 8-bit sprites `#60`\n- chats encrypted and never in Avo; not anonymous, we trust attendees\n- a rare foghorn instead of ambient sound, once a minute or so `#57`\n- the sound button says what is true, it takes two presses `#59`\n- whispered positions drift on production, find out why `#61`\n- dragging my character on a phone scrolls the map `#63`\n- the camera keeps the character centred while walking `#66`\n- quests on the pier only, newest and open on top; pier at root `#68`\n- a quest for talking to five people: send and get a reply `#69`\n- an intent log: 30 PRs in a few days, palkan can't follow that `#62`\n- what was said lands in the chatbox `#64`, the pier's JS tidied `#65`\n- the browser's own state kept through a render `#67`\n\n**Could use a hand:** an ambient background sound for the pier. I've tried twice\nand nothing feels right.\n```\n\nA teammate glances at that for 15 seconds and sees how I spent my day. Notice the line at the bottom. I’ve tried twice to get an ambient sound right for the pier, nothing works, so I said so. Anyone reading can take it off my hands.\n\nA few properties that make it work:\n\n- **One list a day, in my words. The PR tag says where it got to.**`#58` merged,`#61 open` still going,`#7 dropped` closed. No tag means nothing shipped for it.\n- **The tag is a bare number, not a link.** A URL would eat half a line budgeted at 20 words, and`gh pr view 58` gets you there anyway.\n- **A line with no tag is the point of the whole file.** It’s the only place a teammate can see what I’m still missing without me having to ask.\n- **Days end with what’s stuck.** The**Could use a hand:** line turns a diary into a list a colleague can act on. So do**Dropped:** ,**Postponed:** , and**From review:** for the PRs the agent opened that I never asked for.\n- **One ask, one line, under 20 words.** No before-state, no reasoning, no flourish. The diff already explains how it changed.\n- **A day stays under 180 words** , even when it produced eighteen PRs. A log that grows with output is just another unreadable surface.\n\nAnd the part that makes it actually happen: **my agents write it themselves** as they wrap up a session. I’m not maintaining a changelog by hand, because I wouldn’t, and neither would you. The agent has the full session transcript. Reconstructing intent from it is exactly the kind of summarization work agents are good at, and it’s work I’d otherwise skip.\n\nIt’s a skill, so you can try it on your own repo:\n\nMost importantly, when we later decide to promote a piece of experimental work into something maintainable, there’s a record of the decisions. The prototype arrives at the engineer’s desk with its reasoning attached, instead of 100K LOC and a shy smile.\n\nWe’re trying this internally, and it’s helping us, but we haven’t used it in a handoff yet. What I can tell you is that on client projects, this is precisely what was missing. The reasons, intentions and decisions behind the code.\n\n## One team\n\nWe’ve reached a time when, as ICs, we can do more than ever. But as teams, we struggle. And yet, I believe we’re beginning to long for each other in these new races.\n\nTwo kinds of work now come out looking identical, and a team that can’t tell them apart will keep grinding no matter how fast its agents get. So say which one is on the table, agree on the rules, and leave a record of what you meant.\n\nLet’s admit what we’ve lost, and work to find it again. Perhaps we’ll give up a bit of freedom and a bit of speed, but we’ll get our human teams back.", "url": "https://wpnews.pro/news/give-up-a-little-speed-get-your-team-back", "canonical_source": "https://evilmartians.com/chronicles/give-up-a-little-speed-get-your-team-back", "published_at": "2026-09-09 00:00:00+00:00", "updated_at": "2026-09-09 17:21:44.210189+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products"], "entities": ["Evil Martians"], "alternates": {"html": "https://wpnews.pro/news/give-up-a-little-speed-get-your-team-back", "markdown": "https://wpnews.pro/news/give-up-a-little-speed-get-your-team-back.md", "text": "https://wpnews.pro/news/give-up-a-little-speed-get-your-team-back.txt", "jsonld": "https://wpnews.pro/news/give-up-a-little-speed-get-your-team-back.jsonld"}}