There’s a rule going around that real developers stay in the terminal and anything with a window is for juniors. After 14 years of legacy code and broken deployments, I don’t buy it. The tool that wins is the one that takes the most friction out of my day, and for a good part of my work that’s Claude Cowork.
Cowork usually gets filed as the simple version of Claude Code, the one for people who don’t write code. That’s a mistake. The CLI is still faster for quick edits, but when I’m planning structure or chasing a bug across several files, I want to see the thing. Diagrams and a context window rendered in front of me beat guessing at what a terminal-only agent is holding onto.
Managing the 1M token context window
The Opus models now take a 1 million token context window, which sounds like the end of every context problem. In practice I’ve watched sites go down and agents fall into logic loops because somebody pasted in a whole monorepo and left the model to sort it out. More noise, worse answers. Treat the context window the way you treat your server’s RAM and keep it lean.
I covered the build side of this in my notes on the Claude Cowork plugin for WordPress. The habit that matters most is keeping tasks apart. Don’t fix a checkout bug in the thread where you just refactored a header. The context tab in the right-hand menu lets you drop files by hand once they stop being relevant, and I use it more than I expected to.
Plan mode, before it writes any logic
The recurring problem with agentic tools is the gap between what you meant and what the agent built. Type “fix the WooCommerce hook” and you get messy code. Plan mode closes most of that gap, because the model has to lay out what it intends to change before it touches any PHP. That’s where you catch the bad idea, rather than three files later.
<?php
/**
* Example of a "Skill" output reviewed for logic.
* Prefixing functions to avoid namespace collisions.
*/
function bbioon_validate_order_context( $order_id ) {
$order = wc_get_order( $order_id );
// Always check if transient exists before heavy logic
$cached_data = get_transient( 'bbioon_order_check_' . $order_id );
if ( false !== $cached_data ) {
return $cached_data;
}
// Logic generated by Claude Cowork - needs verification
if ( ! $order->has_status( 'processing' ) ) {
return false;
}
set_transient( 'bbioon_order_check_' . $order_id, true, HOUR_IN_SECONDS );
return true;
}
You still have to read what comes back. The snippet above is a reasonable logic gate, but keeping it inside WordPress conventions, the transient wrapped around the heavy lookup for instance, is your job and not the model’s. For how this compares with a terminal-only workflow, there’s my guide on simplifying plugin development with Claude Code.
Skills for the tasks you keep repeating
Repeatable work is where dev hours quietly disappear. API documentation, boilerplate CSS for a Gutenberg block, the same scaffolding every time. That work belongs in a skill, which is really a prompt template that carries your alignment, text size preferences and coding standards with it. Mine includes a security audit skill that flags eval() and unserialize() the moment they show up.
If getting Claude Cowork to behave is eating hours you would rather spend shipping, I can take it on. I’ve been working with WordPress since the 4.x days.
Where that leaves the terminal
The terminal keeps its place for quick edits. Cowork earns its place for flowcharts and architecture reviews, as long as the context stays clean. Whichever one you reach for, the measure is whether the code holds up in production and whether you still have any patience left at the end of the day. The Anthropic documentation has the specs if you want them.
