My Real-World Software Engineering Stack for 2026
Documenting the tools I actually use day-to-day in my AI engineering practice as of Q2 2026.
My Real-World Software Engineering Stack for 2026

Image concept by author, generated by GPT Image 2
Software engineers are passionate about the carefully curated tools of their trade, and they love talking shop with other engineers. The discourse can range from a casual, friendly exchange of information to an all-out, zealotry-ridden melee between warring factions.
I’m here for all of it.
These are the top tools I use daily in my own engineering practice, as of Q2 2026. The ones I reach for when it’s time to get down to work and actually build some sht*.
This list would’ve looked markedly different just a year ago, and I expect it will again a year from now. The very nature of how I work has fundamentally changed over the last year, and the tooling reflects that, most notably in an exodus away from the IDE as Control Center. Documenting this stuff, for me, is part historical record, part shop talk, and mostly just fun.
(I am not affiliated with any of these products, and these are not affiliate links. I use and genuinely love each one. If any of these founders want to pay me to say as much, I’d totally accept the cash — it’ll just never be the reason I do it, and I’ll be up front about it if it ever happens.)
Warp

A little over three years ago, during a conversation about Mac development tools, a colleague offhandedly mentioned a new terminal he thought looked cool and sent me a link. He never followed up on it, but I did, and it turned out to be an early version of Warp. I was immediately blown away. I was handling release management for a squad of four teams with about 10 deployables to juggle at the time, and the rich text editing combined with a wide array of enhanced workflow features provided some serious productivity and UX gains for me.
Warp has been my terminal of choice ever since, and its role has only grown as it’s evolved into an Agentic Development Environment (ADE). All the original capabilities remain, but they’ve leaned hard into the CLI agent paradigm, positioning Warp as an agent-agnostic ADE that works with any coding agent you bring to it.
The fact that Warp itself bundles very capable live agents directly inside the terminal adds value that other CLI agents can’t match by nature. When I run a command, and it fails, Warp’s agent is right there offering to “do x and re-run to fix”, catching context as it enters the terminal and proactively suggesting or taking action. It does the same for coding agent output.
To illustrate this, here’s a real example of the Warp agent catching incomplete work from Claude Code after a session was aborted in the middle of a task:

Take Warp up on the offer by clicking that prompt, and the agent already has all of the same context that Claude Code had and is ready to get cranking:

And then it’s done:

In effect, Warp becomes a built-in pair programmer to your coding agent. Once you start leveraging that specifically as a feature, its core advantage in this realm becomes obvious.
Recent updates include remote control, more direct and visual agent integration within the terminal (giving that same rich text editing to agent input, along with system notifications and other UX enhancements), and the Oz Cloud Agents platform, bringing Warp fully into the autonomous, multi-agent orchestration space. Regardless of where I ultimately land with my primary coding agent selection (see below), Warp will remain the Control Center of my daily operations.
Claude Code

Claude Code has been my primary coding agent since its release. Most of the engineering world that’s dug deep into building with coding agents has landed there, too, so I won’t rehash what’s been said to death. I built my primary app with CC from the ground up and honed my AI-native engineering skills with it in the process, and it continues to be the primary coding vehicle for me.
I’ve spent the last year in deep, exploratory building with CC while refining my environment’s skills, hooks, memory, MCPs, and plugins. I’ve dug deep into context ngineering, and I’ve done enough dances with the session/5-hour/daily/monthly usage limits to be able to somewhat effectively manage my “tokenomics” to ensure I can work freely when I do. That’s held for the year.
The multi-surface continuity is not to be overlooked here, either, as that is becoming a hard requirement for me more and more these days. Outside of the CLI, I use the mobile app for spinning up cloud agent work while not at my desk, and I’ll transfer sessions between the CLI and the app to keep momentum going at times. Over time, I’ve developed a local environment and a workflow that feels comfortable at least (since dependability is elusive in this space).
But there are cracks showing. Increased flakiness with usage caps hitting at seemingly random times and the degradation of the harness’ consistency in general over the last few months have worn on me. And for every awesome new feature that Anthropic introduces with Claude, there is also some weird billing decision that isolates solo builders, or a business deal that seems to have them bearing down on enterprise adoption and IPO over ICs. It’s still great and still my primary at the moment, but the biz is weird and frustrations have been increasing in general.
All of this reminds me of several things:
- It’s not a good idea to use the same agent for everything anyway. Having a second agent performing an adversarial review of Claude’s work is better than getting Claude itself to do it, even with a different agent/session and model.
- The AI space in general is so wild and fluid right now that it’s also not a wise move to put all of our eggs into one basket with Anthropic (or anyone else, ever, for that matter).
- Open source models and agents are progressing almost at an equal clip to the frontier players these days, and even other commercial coding agents are worth looking at.
I started formally evaluating alternatives a while back, and two of them appear next as they have become counterparts, and backups, to CC.
Factory Droid

I came to Factory Droid indirectly. I’d been loosely aware of it and loved the product vibes, but never dug in. When I looked at GitHub Copilot for its code review features, it was about as underwhelming as expected. I’d heard Factory was exceptional on the review front with a solid GitHub app integration, so that got me looking at it seriously .
I started just by having Claude Code build a feature, then spinning up a review Droid against the uncommitted code for an adversarial take, and the improvement in quality over Claude Code reviewing its own work was immediately apparent.
Droids are now a regular presence in my flow, keeping Claude (and Cline) honest and taking on increasingly substantive tasks as I’ve gotten more comfortable with the platform. I’ve got the Factory GH app running on my primary repo for formalized PR reviews, but the pre-commit adversarial review workflow with Factory as validator works exceptionally well, ahead of commit.
What sets Factory apart for me is the engineering practice DNA baked into the product itself. Built-in code review and security review pipelines, the Missions framework for multi-agent orchestration over long-running objectives (more to come on this), and the architecturally considered approach to plan-then-act all demonstrate the attentiveness of the product design to engineering best practices from the ground up.
You also get access to a variety of frontier US and Chinese models via Factory’s own inference (including the same Anthropic models you use in Claude Code). The Factory:GLM pairing has, for me, become something that genuinely contends with CC:Sonnet for most general dev work, and the planning capabilities of Factory:Opus may actually edge out CC:Opus at this point. I’m still exploring the full depth of it, but Factory has earned the secondary spot in my lineup, full stop.
Cline and Kanban

I’ve been using Cline as a backup to Claude Code for the last nine months or so, after first evaluating it at an enterprise level for work during AI rollout explorations and falling in love with the plan-then-act approach it fosters. Cline was the first agent I encountered that put that workflow front and center, and it made a real impression on how I think about structured development with agents. That it’s one of the few OSS coding agents to gain any real enterprise traction doesn’t surprise me in the least.
Another big advantage of Cline, even more so than Factory, is the sheer volume of model access it provides at low price or free, whether through its own inference or BYOP. There are always at least 1–2 seriously capable OSS models on tap in the free department while many others are available to explore, providing a solid way to stay informed and try out the capabilities in emerging OSS models. The major players in premium models are there as well, for a premium price that is still on par than the vendors.
Even with CC as my primary, I’ve kept coming back to Cline for a second set of eyes on debugging, small-to-medium refactors, and plan mode cross-thinking on specs in progress. And when CC usage caps hit mid-session (as they increasingly do these days), Cline is a ready and able backup at a dramatically lower cost.
With the recent addition of the Kanban tool for agent workflow orchestration, its massive OSS community, LLM-agnostic model, and free-to-reasonable pricing all going for it, Cline is a 3rd quality contender for me in the primary agent race. Kanban has already settled itself into being a part of my workflow since its release, and the fact that it is driven entirely by Cline itself likely means Cline has some sort of permanent spot in the rotation.
WisprFlow

I’ve been recording “voice notes” to capture ideas since I was humming guitar riffs, Beavis and Butthead style, into a microcassette recorder in my 20s. For some reason, I never extended that technique out to my note taking practices until recently, and certainly never considered it being something useful in software development.
I started using WisprFlow to record voice notes directly into my notes app so I could capture ideas and thoughts quickly, with minimal friction in the moment. That practice alone has been one of the most meaningful accelerants for me in the last couple of years. But where it’s really changed my workflow most recently is in coding agent session (yes, the hype is real). Just pushing a button and speaking my thoughts right into the terminal, then moving on mentally, removes many cognitive barriers for me.
It doesn’t even have to be WisprFlow specifically, there are certainly alternatives I haven’t looked at, and voice inputs are virtually everywhere in now anyway. But pick one agent input point and give it a real stretch of a few sessions where you’re doing the most long-form thinking or interacting with the agent heavily. The initial weirdness clears out fast, and you feel the friction disappear the first time you really fire on it. YMMV, but for me it’s now just part of the machine.
Shottr

A great screenshot tool is indispensable, and it became unexpectedly more so the first time I used a screenshot instead of words to direct a coding agent at a UI/UX bug. If you’ve ever spent an hour trying to describe a layout glitch in chat and watched the agent miss it three times in a row, you know the feeling. A screenshot with a highlight drops in two seconds what three paragraphs can’t.
Shottr is no-nonsense, no fluff, just a simple keystroke->capture->save workflow. I can edit, organize, and export later if I need to, and the files are easy to locate on disk if I need to do any bulk processing operations. Shottr stays out of my way until I need it, it does its thing with excellence, and then it’s gone. Period.
WisprFlow + Shottr together have become a must-have combination in how I interact with coding agents. Two of the highest-leverage tools in my daily flow, and neither of them was built for engineers
Excalidraw

I’ve been a Draw.io guy for years when it comes to every day diagramming and modeling, but it hasn’t always kept pace with my work, and I often find myself getting distracted or taxed looking for the right shapes when I just want to whip up something quick. After six months with Excalidraw, there’s no going back for daily use.
I still reach for Draw.io or Lucid for professional presentation of enterprise systems, depending on the audience, but for quick whiteboards, low-friction diagrams, and working out lo-fi versions of things that might end up somewhere more polished — Excalidraw, no contest.
With a rich community behind it, driving all sorts of interesting features and integrations, along with MCP and CLI offerings that make agent integration a breeze, you can easily create and move diagrams between formats and artifacts as needed in your flow. Having Claude Code or Droid include diagrams when building docs, etc. is a huge boost in the quality of the output, to both human and machine. The long-sought after holy grail of keeping models and code in sync starts to feel actually attainable when there are no protocol or formatting barriers in the pipeline.
Bruno

I used Postman professionally for API testing for years until their licensing debacle a few years ago. Then we switched to Insomnia at work, but I never really fell in love with it and eventually had less of a need for either tool. They both feel bloated for my needs these days.
When I got back into serious solo builder work last year, I went looking for a real Mac alternative. There are solid VSCode plugins that handle API testing well and keep developers in the IDE, but I spend less and less time in VSCode these days and have always preferred the dedicated workspace approach of tools like Postman and Insomnia anyway.
Bruno hit the mark, and I used it heavily for my app’s API and BFF buildout, troubleshooting, and testing third-party integrations as I moved along. The most important thing it gives me is the ability to avoid thinking about the tooling when I just need to see what’s actually happening at the request/response level. That is a singularly manual, human task for me at that point, so I don’t need AI, team, network monitoring, or any other features bolted on top to get in the way of clarity.
REST and GraphQL support, pre- and post-request hooks, scripting, and call chaining. All of it is there, and all of it is competitive with Postman and Insomnia, with zero bloat.
Proxyman

I love a good packet sniffer, and Proxyman is the king of network debugging on macOS across the board — a true native, wire-level tool that surfaces hidden requests made by apps, services, and libraries several abstraction layers below what you think you’re actually looking at. Run it while your agents and chatbots are working and watch how much is happening that you’d have zero awareness of otherwise.
Where Bruno handles directed, purposeful API work, Proxyman handles everything else: deep visibility, response mocking with Map Local (local file-based mocking that noticeably drops API costs during pre-production work), scripting, and breakpoint debugging.
The Bruno + Proxyman combo handles about 85% of my manual testing and debugging needs lately, and Proxyman in particular is one of those tools that is genuinely fun to use.
Docker Desktop

Every engineer reading this knows what Docker Desktop is, so I’ll skip the preamble and get to why it’s in here.
The big thing for me lately has simply been the Docker Hub integration, and what it enables for self-hosted services. All of my app servers and local automations run in Docker, along with local testing instances of app-integrated, self-hosted services like PostHog, and my research and publishing pipelines in n8n.
The ability to pull and spin up self-hosted services from Docker Hub in a few clicks, and recently the same ability with LLMs in Model Runner, has turned DD into a personal cloud platform for not only my local dev environment, but much of my day-to-day workflows as well. And managing it all visually is just faster and lower-friction than pure CLI scripts (which I’ve stubbornly insisted on leveraging exclusively over the years). Gordon, the Docker Agent, has even proven helpful when managing and troubleshooting containers, along with answering just general “which is better here…” questions.
Much of this has been available to me forever, I just hadn’t had a compelling need for it until more recently. Either way, Docker has become such a fundamental part of the plumbing of modern software engineering that it is totally overlooked in most tooling lineups, so I wanted to give it its flowers here as I expect it to still be here next year (and well beyond that).
GitKraken

Managing multiple repos with AI agents crawling all over them is a real cognitive load, and GitKraken has become my workbench for staying sane about it. I’m still the one manually pushing merge at the end of the day, so solid source management tooling still matters.
The Launchpad gives me the right amount of mental organization, and everything else (worktree and branch management, inline editing during reviews, merge conflict inspection and resolution, activity logs for when things go sideways) is right there in one place. The recent updates around “agentic code review” are an excellent addition to an already very capable tool, making the act of reviewing agent-generated code much more organized, and less taxing cognitively.
Despite living in the terminal most of the time these days, or maybe because of it, GitKraken has become a welcome cognitive mode switch for me. A break from directing agents and staring at the CLI. Quick git workflow commands will always happen in the terminal, but when it’s time to review, commit, merge, or manage branches and worktrees, GitKraken gets the call.
Things I Expect to Change
What are the things I expect to change this year?
My primary coding agent Factory and Cline are showing me a lot right now, with both providing near-level value at the agent/harness level as Claude Code — even better in some cases, when it comes to planning and consistency in engineering discipline — and each provides access to not only the same Anthropic models I use in CC, but every credible OSS model on the market as well, which is right where I want to be at the moment.
Amp is another CLI agent that is really looking great at the moment with its extremely low-friction, though opinionated flow. OpenCode and Kilo are also on my radar.
So, I’ll be closely evaluating the six of these over the next six months. It may very well be, in the end, that there is no primary, and that the scope of the work at hand determines which agent gets which task based on strengths. That’s sort of what I’m naturally seeming to do anyway, though the calculus moves with any meaningful update from any of them.
The way I work with agents Multi-agent orchestration across long-horizon development work is where I’m digging in at the moment, and I expect to be iteratively building workflows around this and other emerging disciplines.
So that’s the primary kit in my toolbox as of Q2 2026. In an upcoming series, I’ll map out an end-to-end, AI-native product engineering workflow from ideation through release, with all of these tools integrated, along with others, into a coherent workflow.
In the meantime, what’s in your toolbox?
메타데이터
- post_id
- 070cc7ca72e1
- slug
- my-2026-software-engineering-tool-stack-070cc7ca72e1
- url
- https://medium.com/@keenescott/my-2026-software-engineering-tool-stack-070cc7ca72e1
- canonical_url
- https://medium.com/@keenescott/my-2026-software-engineering-tool-stack-070cc7ca72e1
- author_url
- https://medium.com/@keenescott
- status
- ok
- fetched_at
- 2026-06-09 15:37:30