I’ve been writing code professionally for a while now, and if there’s one thing I’ve learned, it’s that the gap between a good developer and a great one often comes down to workflow. Not talent. Not caffeine intake. Workflow.
Over the past year, I’ve overhauled how I work — from my IDE setup to how I handle repetitive tasks — and the difference has been noticeable. Here’s what actually moved the needle.
Your IDE Is Only as Good as Your Config
Most developers install VS Code or JetBrains, add a theme, maybe a linter, and call it a day. That’s leaving a lot on the table.
The single biggest productivity gain I made was treating my IDE like infrastructure. I version-control my settings, share plugin lists across machines, and periodically audit what I actually use versus what’s just sitting there consuming memory.
A few plugins that earn their keep daily:
- Error Lens — surfaces diagnostics inline so you catch issues without hovering or opening the problems panel.
- GitLens — makes git blame useful instead of annoying. Seeing who changed a line and why, right in context, saves a surprising amount of detective work.
- Todo Tree — aggregates every TODO, FIXME, and HACK comment across your codebase into a single view. Great for staying honest about tech debt.
- REST Client — lets you send HTTP requests directly from a
.httpfile in your editor. No more context-switching to Postman for quick API checks.
The key isn’t collecting plugins. It’s being intentional about which ones solve a real friction point in your day.
Automate the Stuff You Do More Than Twice
This sounds obvious, but most of us still manually run the same sequence of commands dozens of times a week. A simple shell alias or script can reclaim minutes that compound into hours.
Here’s an example. I used to type this every time I started work on a new feature branch:
git checkout main && git pull origin main && git checkout -b feature/TICKET-123 && npm install
Now I have a small function in my .bashrc:
newbranch() {
git checkout main && git pull origin main
git checkout -b "feature/$1"
npm install
echo "Ready to work on $1"
}
Running newbranch TICKET-123 handles the whole flow. It’s a tiny thing, but tiny things repeated hundreds of times matter.
The same principle applies to project scaffolding. If you’re copying and renaming files to create a new component or module, write a small generator script. Even a basic one saves time and reduces the chance of copy-paste errors.
AI-Assisted Coding: Useful, Not Magic
AI coding assistants have become a real part of the developer toolkit. Tools like Kiro, GitHub Copilot, and others can genuinely speed up certain tasks — writing boilerplate, generating test stubs, explaining unfamiliar code, or drafting documentation.
Where I find AI assistance most valuable is in the exploratory phase. When I’m working in an unfamiliar codebase or trying to understand how a library works, being able to ask questions in context and get relevant answers without leaving my editor is a real time-saver.
That said, the developers who get the most out of these tools treat them as a collaborator, not an autopilot. You still need to understand what the code does, review suggestions critically, and maintain ownership of your architecture decisions.
A Practical AI Workflow
Here’s how I typically use AI assistance during a coding session:
- Describe the problem or feature in plain language first
- Let the tool suggest an approach, then evaluate it against what I know about the codebase
- Use generated code as a starting point, not a finished product
- Ask follow-up questions to understand trade-offs
This keeps me in the driver’s seat while still benefiting from the speed boost.
Dev Workflows That Scale
Beyond individual tools, the structure of your workflow matters. A few patterns that have helped me and the teams I’ve worked with:
Trunk-Based Development with Short-Lived Branches
Long-lived feature branches are where productivity goes to die. Merge conflicts pile up, context gets stale, and code reviews become overwhelming. Keeping branches short — ideally merged within a day or two — keeps everything moving.
Pre-commit Hooks for Consistency
Using tools like husky and lint-staged to run linting and formatting before every commit means fewer CI failures and less back-and-forth in code reviews about style issues. Set it up once and forget about it.
// package.json
"lint-staged": {
"*.{js,ts,tsx}": ["eslint --fix", "prettier --write"]
}
Structured Commit Messages
Adopting conventional commits (feat:, fix:, chore:) makes your git history searchable and enables automated changelogs. It feels like overhead at first, but it pays off quickly when you need to trace when and why something changed.
Measure Before You Optimize
One trap I see developers fall into is optimizing based on gut feeling. Before you overhaul your workflow, spend a week noticing where you actually lose time. Is it context-switching between tools? Waiting for CI? Debugging environment issues? The answer might surprise you.
Tools like WakaTime can give you data on where your coding time actually goes. Sometimes the biggest win isn’t a new plugin — it’s fixing a flaky test suite that breaks your flow three times a day.
Wrapping Up
Developer productivity isn’t about working faster. It’s about removing friction so you can spend more time on the work that actually requires your brain. Start with your biggest pain point, fix it, and move to the next one.
If you’re looking for a dev environment that brings a lot of these ideas together — AI assistance, smart tooling, and workflow automation — check out what we’re building at agntbox.com. We’re focused on helping developers stay in flow and ship better code with less overhead.
🕒 Published: