Software engineers are getting hit from every direction right now. New harnesses, new models, new plugins, new workflows, all shifting every few weeks. Agentic development is just how we build software now. That’s not really up for debate anymore, the train left that station a while ago. What’s still very much up for debate is how any of us should actually work inside of it.
I’ve been going back and forth on this for months, oscillating between tools and setups just like everyone else. But a few recent conversations have pushed me toward something that feels a little more solid, at least for now. So take this as current thinking, not a conclusion.
What the team should agree on
Most of us aren’t working solo. We’re part of a team, contributing to something bigger, and that means there’s a layer of this that has to be shared. Agent instruction files. How you structure your docs. Your testing strategy and the actual test suite. Pre-commit hooks. A small set of core skills the team has explicitly agreed on, something like a “review this PR” skill, codified once instead of everyone reinventing it.
None of that is new advice exactly, it’s just good project hygiene. It’s the stuff that’s always mattered for a healthy codebase. It just turns out to matter even more once agents are the ones reading it.
The nuance is that this stuff needs to stay generalized enough to survive whatever harness any individual on the team happens to be using. We haven’t landed on real standards yet, different tools look for instructions and skills in different places, so keeping things portable is more art than science right now. But the intent is clear: if it lives in the repo, it should work no matter which model or tool touches it. If something only works inside one specific harness, that’s a signal it doesn’t belong in the shared layer. That decision is bigger than any one workflow, and a whole team can’t reasonably agree to it.
I used to think we should all just pick one
Not that long ago, I thought the easier path was for a team to just rally around one agent harness. Pick a tool, lean all the way into its specific capabilities, whatever cloud features it has, however it handles scheduling or sub-agents, and build your whole team’s process around that one thing.
I don’t think that anymore.
The more I’ve experimented on my own, watched other engineers work, and just thought about how we actually build software, the more I think our brains are wired too differently for that to hold. We process problems differently. We move through work differently. And that’s just as true with these tools as it’s ever been with anything else.
This isn’t actually new
Watching engineers show off their setups lately reminds me a lot of watching people argue about dotfiles. Vim people. Full IDE people. People with their own diffing tools, their own key bindings, their own very specific opinions about the terminal. We’ve argued about which is objectively best for years and never really settled it, because the honest answer is that different things work better for different people. Our brains just aren’t the same.
I think we’re at the exact same point with agent harnesses. Codex, Cursor, Claude Code, whatever’s next, people swear by one and can’t get anything done in another. A skill that unlocks something huge for one person leaves someone else completely stuck. That’s not a sign anyone’s doing it wrong. It’s just the same old pattern showing up in a new place.
Building your own little team
What I think we’re actually doing, each of us, is building our own bespoke pairing partner. Maybe even our own little agentic team. And we’re spending real time and energy constructing it to match how we individually like to work.
Do you like to go big first and scale back, or work in small steps and feel your way through a problem? That’s a pretty fundamental difference in how people operate, and different setups are tuned for one direction or the other. I’ve noticed this in my own experimenting too, I’ll grab one piece from someone else’s workflow, a tool, an idea, a habit, and fold it into mine. My setup keeps drifting because of it. I assume that’s going to keep happening for a long time, because models and tools aren’t slowing down anytime soon.
What hasn’t changed
Here’s the thing that actually hasn’t moved: we’re still trying to get code written, reviewed, committed, and deployed. That’s it. How you get there was never really the point, as long as it meets the codebase’s standards and it’s well written, safe, and done right. Getting from A to Z is the job. How you get from A to Z has never mattered nearly as much as we sometimes act like it does.
So maybe the real shape of this is a team with a small, stable, shared layer sitting in the repo, with git history and everything, and then a bunch of individuals constantly tuning their own environments around it. Not a one-time setup either. A constant, ongoing thing, because the tools keep changing under us.
The messy part
There’s a lot I don’t have good answers for here. Cost is a real one. Which model is best for which kind of work, and why. Whether your company’s already locked into an enterprise deal with one provider and that decision gets made for you before you even get a vote. Do you get to pick whatever tools you want? Does the company hand out some kind of monthly budget and let you sort it out yourself? I have no idea how any of that shakes out, and I suspect nobody does yet.
Even inside a real constraint, say your org is a Cursor shop and that’s just the deal, there’s still a surprising amount of room to mess around. Skills, configs, sub-agent setups, all of it. The restriction is real, but it’s rarely as narrow as it first feels.
I used to nudge engineers toward specific tools. I don’t really do that anymore. Now I just push people to figure out what actually works for them, knowing full well that whatever works today might not be what works in a year. That’s honestly always been true of developer tools. We’re just working with a new set of them now, one that happens to be changing faster than anything I can remember.
I’ll say this too: I kind of love it. Tripping over something, getting annoyed by it, figuring your way around it, and ending up with a setup that’s a little more yours than it was yesterday. That’s always been one of the fun parts of this job. I don’t think that’s going away anytime soon.