Oh.My.Claude

The Claude of It All

It’s been an odd kind of month. Claude, a coding agent from the company Anthropic, turned 1 year old this month and it just so happens that I’ve spent a lot of time this month getting comfortable running it at work and adopting it for my own personal projects. Here’s some free-flowing thought about the month.

Things I Like


Terminals and CLIs are Home

I spent some time from the late ’90s to mid ’00s as a GUI enjoyer and really leaned into IDEs when they were available. It wasn’t long before I was bloat-weary and resented the “I AM DOING THIS TO HELP YOU!” energy of things like Microsoft Visual Studio Enterprise For Real Ones 2005 Super Duper Edition. I longed for simplicity1 and in the early ’10s chose Sublime Text until VS Code became a viable alternative. Give me a good terminal and a reasonable text editor2 and I was happy. Fewer fidgety, brittle, magic UI buttons, more straightforward scripts, configuration files, and CLIs.

Early 2017, I landed a job at one of my dream companies at npm and found others who also had deep love of CLIs. All this to say, if I can reach for something that runs in a terminal, I’m gonna do that and Claude was an npm install.

I dream in Markdown

I like Markdown because I don’t need to learn & perform complex keyboard combinations nor do I need to move my hand off the keyboard to fiddle with formatting widgets. Blessed be the Grube.

At this point it’s how I write by habit and when I encounter things that don’t support it natively, I treat myself to a nice grumble-fest3.

The ability to communicate my thoughts in Markdown to Claude was great. That it does a nice job of representing its state and intentions in Markdown won me over very quickly.

Effective With Legacy Codebases

My first several projects with Claude were modernizing old OSS projects I’d let bitrot. With Claude’s capable help, I had them rewritten in typescript with expanded testing. I was surprised by how little I needed to explain to it but I believe this is partly because all of my projects had markdown documentation of their behavior and API as well as decent test coverage for reference.

Claude turned what would have been weeks of slow, tedious work spread across pockets where I had free time and enough mental energy left over, into 15-60 minute adventures that resulted in revitalized projects that I could use again.

Delegating to the Machine

In my career, I have held a number of management titles (up to VP on two occasions) and thanks to good coaching and feedback, I learned to let people write code the way they write it (so long as the team finds it acceptable) and focus more on the design and qualities of the system (maintainability, testability, operability, observability, resiliency, scalability, etc.).

Furthermore, writing passable code requires deep focus. It’s not the kind of thing I excel at when I’m dealing with lots of interruptions or times when I have to step away from the keyboard for more than a minute or two. If you ignore the token quotas for a moment4, Claude’s attention and ability to focus are inexhaustible by comparison. It doesn’t need breaks and it can produce source code while I go make dinner.

Better Dev Loops

In the past, creating docker-compose setups for complex systems could be a time suck at best and a headache inducing chore at worst. Claude is good at build, test, and dev automation. In a short period of time, a project I rebooted went from disparate services with no home to something that I could run and keep up-to-date with changes in my local environment.

I’ve never written a playwright test in my life, but it turns out Claude is also quite capable at writing UI tests that validate that the UI works so that I don’t have to go and click through every interaction when I (or Claude) makes changes.

I have seen folks at work with a very impressive SDLC setup where Claude is getting instructions from a work management system, performing the work, and updating the status of tasks through a clever use of MCPs.

It’s Reasonably Good

Compared to time spent with things powered by OpenAI, I’ve been consistently surprised with how well Claude does with asking for clarification, doing what it’s asked on the first try, and helping me identify and correct issues resulting from ambiguous instructions or regressions. When it comes to technical correctness, I haven’t run into many situations where it hallucinated an API, a design approach, or implementation detail.

Things I Don’t Like


Annoying bugs

I don’t like being told by the Claude-ists that what I really need to do is turn it loose, disable the safeguards, and let it run wild in a sandbox because Anthropic hasn’t figured out how to get the granular tool permissions correct (yet). Even the side-projects I’ve looked at can’t seem to resolve this truly obnoxious issue.

No, I don’t want to have to check back every few minutes because Claude needed to pipe to tail after configuring it to always allow that command.

It’s not a deal breaker given the over-all power of the tool, but this bit is such a weird lingering bug for what is now the most expensive piece of software I use.

So Many Quotas

Given the cost of inference, I totally get how every model needs to limit use based on subscription. Why, oh, why do I have a session window, as well as weekly all model quotas and a weekly Sonnet only quota? I’ve made the most use of Sonnet so far and I’ve been happy with the speed and outcomes. It’s hard not to feel like I’m being pushed into other models that would either be overpowered or underpowered for the work I’m regularly doing.

Opus, The Token Burner

I was excited to see that Anthropic gave me some bonus usage so that when I was on the $20 plan, I could try out an advanced model without losing my tokens for several days after. I was much less excited after Opus took longer to perform the same task with roughly the same outcome and the primary difference was that it used a lot more tokens.

What I do think this means is that if you don’t know you need Opus, don’t use that. We don’t need a flame thrower to clear a light dusting of snow from our walkways and you probably don’t need Opus unless you’re trying to solve for a particularly difficult, novel coding problem.

The Illusion

As long as I’ve been a software engineer, large software companies have promised non-technical decision makers, “yOu wOn’T eVEn nEEd sOfTwARe pEOplE aNYmORe!!” A lie so bold and reckless that one wonders how it is that no one seems to be catching on that until we reach AGI, it’s a total fabrication.

Shifting the focus away from writing lines of code is not the same as “anyone can design a good system now”. The agents are a long way off from transparently handling the implications of decisions that they make in the absence of clear instruction. Neat prompt tricks won’t displace a broader comprehension of a discipline that one tends to accumulate over many years of experience and intentional learning.

The complexity of software systems is constantly, rapidly expanding. Unless you are only building software for a handful of people who don’t have alternatives5, you can’t just slam “MAKE IT DO A HARD THING” into a prompt and expect to get something that’s going to be:

  • sustainably extendible as your system grows to address more use cases
  • sustainable to deploy, operate, and support
  • suitable for purpose

It is cool that Claude is so capable that you can give it pretty simplistic instructions and it will try its hardest to make something useful. It is uncool that we are going to have to relearn that the field of software systems is about a great deal more than being able to write syntax that passes a linter/compiler check. My expectation is that quite a few disciplines are about to learn that you can spend a lot of tokens (money) producing something that falls over.

”YOU’RE-NOT-A-REAL-SOFTWARE-ENGINEER! REEEEEE!!”

My friend, if I had a dollar for every time someone has implied or outright said this kind of gate-keeping thing to me, I’d be able to pay my monthly Claude subscription for a year or so.

It turns out that while I’ve always been happy to do the keyboard-face-roll6 until tests pass, after 30+ years of writing code in most languages you’ve heard of (and some you probably haven’t), I’m increasingly less interested in the mechanics of entering lines of code but find that designing architecture, creating solutions, and collaborating with others continues to hold my interest and where I feel like I get the highest reward for time spent.

I know some of you love practicing leetcode problems in your off-hours (otherwise how is anyone getting through these silly interview gauntlets), but, and I say this with love, the number of jobs where you need to smash out rote algorithms7 is vanishingly small, friends.

Fundamentals won’t go out of style, but I believe that the most important skills have always been the ability to think at a systems level, articulate good design principles, and creatively select and apply the right technology to solving real problems.

On the upside, I think we have a real opportunity to focus more of our time towards thinking about the right ways to effectively deploy technology towards better outcomes and less time worrying about the mechanics of writing code.

Footnotes

  1. shut up about Vim tho ↩

  2. no, not Vim … or Emacs. ↩

  3. self care is important! ↩

  4. but don’t forget the quotas because those are real ↩

  5. if the cost barriers of building systems decreases, captive audiences won’t be a given ↩

  6. what? you still coding with your hands? it’s 2026, broh. ↩

  7. most of this stuff is part of the language or readily available in a library ↩