My setup: the tools I use every day

I Do Not Optimize For Aesthetic Setups

When people ask about a developer setup, they usually expect a shopping list. Laptop. Keyboard. Editor. Maybe a few browser extensions and a clever wallpaper. I get why. Hardware is visible. Screenshots are visible. It is easier to show a desk than to explain a workflow.

But the most important parts of my setup are not visual. They are structural.

I build across a weird intersection: enterprise PHP systems, AI tooling, internal automation, browser-driven flows, and increasingly, environments where one task can involve three repositories, two models, a terminal session, and a deployment check before lunch. In that kind of work, the real bottleneck is not typing speed. It is context switching.

So my setup is designed around one question: how do I keep momentum when the work itself is fragmented?

That has pushed me toward tools that reduce friction between thinking, execution, and verification. I want fast terminals, strong local automation, AI tools that are useful without becoming trusted by default, and enough structure that I can leave a task, come back six hours later, and still know what is going on.

I am not trying to build the perfect setup. I am trying to build one that survives real work.

The Terminal Is Still The Center Of Gravity

If I strip everything down to first principles, most of my serious work still converges on the terminal.

That is not nostalgia. It is because the terminal remains the fastest interface for combining tools that were never designed to live in the same product. Git, SSH, build pipelines, grep, local scripts, queue workers, static site generation, API calls, deployment checks, log inspection. In a browser-first workflow, all of these become separate tabs and separate mental states. In the terminal, they become one continuous workspace.

I use the terminal as an orchestration surface, not just a command runner. One session is the codebase. Another is tests. Another is logs. Another is some long-running local service I do not want to think about unless it breaks. The value is not that terminals are cool. The value is that they let me keep multiple threads of work visible and close together.

This matters even more now that AI is part of the workflow. A lot of people imagine AI coding as something that replaces command-line work. My experience has been almost the opposite. The better the agent becomes, the more important the terminal gets, because I need a stable place to inspect what the agent changed, run the verification pipeline, and understand the environment beyond whatever neat answer a model generated.

AI can help me write code. It cannot remove my need to see the system clearly.

Claude Code And Codex Changed The Texture Of My Day

The most obvious change in my daily setup is that AI coding tools are now native parts of my workflow, not occasional experiments.

I use Claude Code and Codex heavily, but not in the lazy fantasy version of AI-assisted development where you throw a vague prompt at the model and hope the repo becomes better by accident. For me, these tools are strongest when they are attached to disciplined loops: inspect, modify, test, verify, document, repeat.

What they changed most is not raw code output. It is throughput on annoying but necessary work. Refactors that require touching many files carefully. Documentation scaffolding. Test generation that still needs review but no longer starts from zero. Pattern tracing across a codebase. Boilerplate reduction. Exploratory implementation for ideas I want to pressure-test quickly.

That said, I do not treat model output as authority. I treat it as accelerated draft work. A surprising amount of AI-generated code looks correct long before it is actually safe. Good naming, clean indentation, plausible architecture, maybe even passing tests. That can lower your guard. So my setup keeps skepticism cheap. Verification is one command away. Diffs are readable. The system makes it easy to challenge what the model did instead of quietly absorbing it.

That is also why I prefer coding agents that can work inside real repositories and real terminal flows. If the agent is separated from the environment, its usefulness drops fast. If it can read the code, run the checks, and respond to the shape of the project, it becomes much more than autocomplete. It becomes a teammate I still supervise.

My Own Dev Orchestrator Solves A Very Specific Pain

A lot of my stack exists because I got tired of losing time to the same class of problem: local environment friction.

Different projects need different services. Different branches need different states. Test suites need repeatable startup. Agents need isolation. If every coding task starts with ten minutes of setup, the day dies by a thousand cuts.

So I built my own dev orchestrator with Laravel Zero. It handles a local CI/CD-style flow for PHP projects, from branch validation through environment startup, service wiring, and test execution. It is not glamorous, but it removed one of the most expensive invisible taxes in my workflow: preparing to work.

This became even more important once I started running parallel development patterns. If an agent or a second worktree needs a safe place to operate, I do not want to improvise that every time. I want a predictable path. Start environment. Run checks. See output. Tear it down cleanly. The best setup improvements are usually not the ones that feel futuristic. They are the ones that quietly eliminate recurring annoyance.

I trust custom tooling only when it pays rent. This one does.

Git Worktrees Made Parallel Work Practical

One of the most useful upgrades in my daily setup was also one of the least flashy: I started relying much more on Git worktrees.

Once you work with multiple agents, multiple experiments, or even just multiple active tasks in the same project, the normal branch-switching workflow starts getting expensive. You stash something. You switch. You forget what was half-done. You come back later and reconstruct your own reasoning from fragments. That is tolerable when you are doing one thing at a time. It is terrible when the whole point of your setup is controlled parallelism.

Worktrees fix that elegantly. Each thread of work gets its own directory, its own branch, its own running context. No stashing ritual. No accidental contamination. No drama because one experiment needed a dependency change while another needed a clean baseline.

This is one of those tools that seems minor until you internalize the mental relief it gives you. A good setup is not only about speed. It is about reducing hesitation. If starting a side path feels cheap, you explore better ideas more often.

Browser Automation Matters More Than People Think

Some of the most valuable work I do is not inside the code editor at all. It happens in the last mile, where software touches external systems that are annoying, slow, inconsistent, or deeply not API-first.

That is why browser automation is part of my daily setup rather than a niche extra.

Playwright is the tool I reach for when "just use curl" is not a serious answer: dashboards behind auth, admin panels, repetitive publishing tasks, integrations that technically exist but are unreliable, or UI paths that need to be validated the same way a human would actually experience them. I prefer lightweight fetching when possible, because browser control is expensive. But when I need it, I want it available immediately.

This is another area where AI becomes much more useful when it can act through tools instead of pretending text alone is enough. A lot of real-world software work is operational. Open the page. Check the state. Click the thing. Confirm the output. The closer your setup gets to that reality, the less time you waste translating between what the model can describe and what the system actually requires.

Documentation And Memory Are Part Of The Stack Too

I think many developers underrate this because notes do not feel technical enough to count as tooling. I disagree completely.

As the number of active systems in your life grows, memory stops being a personality trait and becomes an engineering problem. What did we decide last week? Which credential belongs to which environment? Why is this script written that way? What failed before? What manual step still exists? If that knowledge lives only in your head, your setup is fragile even if your hardware is perfect.

So part of my setup is explicit memory: workspace notes, curated long-term context, project-specific rules, and daily logs that let me reconstruct what happened without depending on mood or luck. This sounds small until you compare a day with good recall to a day without it. One feels like engineering. The other feels like archaeology.

The same applies to documentation. I want decisions close to the code. I want process assumptions written down. I want future-me to inherit a system, not a puzzle. That is doubly true when AI tools are involved, because they perform better when the environment contains real context rather than tribal knowledge.

What I Deliberately Do Not Optimize For

Every setup is also defined by what it rejects.

I do not chase every new productivity app. I do not believe a fragmented stack becomes better just because each fragment is individually elegant. I do not want five different places for tasks, three different note systems, or clever tools that solve a tiny problem while creating maintenance work everywhere else.

I also do not optimize for AI dependence. This matters to me enough that I wrote about it separately. I want AI in the loop, but I do not want my competence to collapse when the model is unavailable or wrong. If a tool makes me faster while preserving understanding, it stays. If it makes me feel fast while quietly weakening my grip on the system, it goes.

That is why my setup still has a fairly boring core: terminal, Git, code, tests, logs, documentation, automation. The newer layers sit on top of that foundation. They do not replace it.

The Real Goal Is Sustainable Velocity

If I had to summarize my daily setup in one phrase, it would be this: sustainable velocity.

I do not mean speed at all costs. I mean a workflow that keeps moving without depending on heroics. A stack where local setup is predictable, verification is cheap, context survives interruption, and AI helps enough to matter without becoming something I blindly trust.

I have built enough systems now to know that momentum is fragile. It leaks through bad tooling, bad recall, unclear process, and too many tiny frictions nobody notices until the week feels heavier than it should. A good setup does not eliminate complexity. It absorbs enough of it that you can keep your attention on the problem instead of the machinery around it.

That is what my stack is for. Not to look advanced. Not to win points on a /uses page. Just to let me do serious work, every day, with less wasted motion and fewer stupid failures.

A good setup is not the one with the most tools. It is the one that lets you return to hard work quickly, clearly, and without negotiating with your own environment.