Development environments are deeply personal expressions of the fastest way to go from intention to code. Your setup is your setup. Nobody else’s fingers work like yours. Dvorak or qwerty. Split keyboard or not. Tenkeyless. Ultrawide or 3 monitors. Nobody else’s brain pattern-matches quite the same way.
So going forward, what does this mean? How do we produce a dev env that works for us as the ground shifts beneath us?
Back to the terminal
We are in the terminal again, seemingly relearning why we left them in the first place. I never liked vim or emacs. Still don’t! And it feels weird telling my peers to close vscode. Like, genuinely strange advice to give in 2025. But here we are.
Learning how to leverage these agents feels a lot like asking engineers to go into the swamp and lift a spaceship out while Yoda nods aggressively. But they do need to learn how to use the force. And they need to learn it like urgently. Not eventually. Now.
What even counts as dev env?
A claude.md is not a dev env. Skills are not dev env. Are they? I keep going back and forth on this.
I think they’re more like lint/prettier. Configuration. Guardrails. Useful, sure, but not the environment itself.
A dev env is the shell you use. The model harness. The model. The keyboard. The TTS. The things that let you convert English to intention rather than intention to code. We used to optimize the path from intention to code. Now we’re optimizing the path from English to intention. Different problem entirely.
The space and the people
How do we optimize that? If you lock me in a room of other engineers, I will not be able to ramble to my agent. It’s not that it’s weird. It’s that it’s distracting. Same as I don’t want you taking calls next to my head. Go get a meeting room. But you can’t book a meeting room all day just to code.
This is a growing pain for engineers in open offices. If voice becomes part of the dev env, you’re at a disadvantage. The infrastructure doesn’t support it yet.
A dev env is the space we work in and the way we treat each other. That sounds soft and it is. You need to be softening. Stay rigid and you will break.
Patience with each other as things change this fast. We will make mistakes. We will experience growing pains. Teams with good relationships and communication skills will thrive, but that’s not new. Soft skills are still critical. They’re high value signal that indicates good engineers. That hasn’t changed.
What’s changed is the dev env is seeping out into our interpersonal relationships.
I think therefore I am your dev env
The faster we’re able to ship, not just ship but safely ship, means we need to rethink our engineering systems. What is a good PR policy? How many reviewers are required when the engineer making the PR probably didn’t write it?
When CI becomes more of a bottleneck our PR process becomes a part of the dev env more so than ever. Which means how we review each other’s code becomes closer to dev env. Which means you and I are part of each other’s dev env. Arguably has always been the case, but this relationship is getting closer.
If agents are writing code faster, there’s more to review, more often. The review queue grows. Your responsiveness directly affects my velocity now more than before. When none of us wrote the code, we’re all reviewers. The dynamic shifts from “author defends their work” to “we’re all reading this together for the first time.” The human oversight role is shared. We’re depending on each other to catch what the agent missed.
We should still review the code our agents write. Not just to validate it, but to grow ourselves and our ability to steer these things. I’ve accidentally “approved” my own PRs so many times lately. Because I’m often reading the code for the first time in the GitHub UI. It’s my PR but I didn’t write it. I’m reviewing it like anyone else would.
Anyways, still need 1 more review on this PR please :)