A staff engineer's journey with Claude Code

At that point, why not just write the code yourself?

I reached this conclusion pretty quickly. With all the hand holding I can write it faster - and it’s not bragging, almost anyone experienced here could do the same.

Writing the code is the fast and easy part once you know what you want to do. I use AI as a rubber duck to shorten that cycle, then write it myself.

Partly it seems to be less taxing for the human delivering the same amount of work. I find I can chat with Claude, etc and work more. Which is a double edged sword obviously when it comes to work/life balance etc. But also I am less mentally exhausted from day job and able to enjoy programming and side projects again.

I’ve been trapped in a hole of “can I get the agent to do this?” And the change would have taken me 1/10th the time.

Choosing the battles to pick is part of the skill at the moment.

I use AI for a lot of boiler plate, tedious tasks I can’t quite do a vim recording for, small targeted scripts.

I am coming back to this. I’ve been using Claude pretty hard at work and for personal projects, but the longer I do it, the more disappointed I become with the quality of output for anything bigger than a script. I do love planning things out and clarifying my thoughts. It’s a turbocharged rubber duck - but it’s not a great engineer

My thoughts on scripts are: the output is pretty bad too, but it doesn't matter as much in a script, because its just a short script, and all that really matters is that it kinda works.

I guess each to their own? I can easily end up coding for 16 hours straight (having a great time) if I'm not careful. I can't imagine I'd have as much patience with an AI.

I'm finding what's happening right now kinda bizarre.

The funny thing is - we need less. Less of everything. But an up-tick in quality.

This seems to happen with humans with everything - the gates get opened, enabling a flood of producers to come in. But this causes a mountain of slop to form, and overtime the tastes of folks get eroded away.

Engineers don't need to write more lines of code / faster - they need to get better at interfacing with other folks in the business organisation and get better at project selection and making better choices over how to allocate their time. Writing lines of code is a tiny part of what it takes to get great products to market and to grow/sustain market share etc.

But hey, good luck with that - ones thinking power is diminished overtime by interacing with LLMs etc.

I wonder if this is an introvert vs extrovert thing. Chatting with the AI seems like at least as much work as coding to me (introvert). The folks who don't may be extroverts?

What you're describing is a glorified mirror.

Doesn't that sound ridiculous to you?

I don't feel like I need to say too much to the agent to get my work done. I'm pretty dang introverted.

I just don't enjoy the work as much as I did when was younger. Now I want to get things done and then spend the day on other more enjoyable (to me) stuff.

>ones thinking power is diminished overtime by interacing with LLMs etc.

Sometimes I reflect on how much more efficiently I can learn (and thus create) new things because of these technologies, then get anxiety when I project that to everyone else being similarly more capable.

Then I read comments like this and remember that most people don't even want to try.

And? Go create more stuff.

Come back and post here when you have built something that has commercial success.

Show us all how it's done.

Until then go away - more noise doesn't help.

I don't think there's anything I could tell you about the companies I've built that would dissuade you from your perspective that everyone is as intellectually lazy as your projection suggests.

How many of these boilerplate do you actually have to do? Any script or complicated command that I had to write was worthy to be recorded in some bash alias or preserved somewhere. But they mostly live in my bash history or right next to the project.

The boilerplate argument is becoming quite old.

Not GP, but I really want to know how your process is better than anyone else. People have produced quite good software (as in solving problems) on CPU that’s less powerful than what’s on my smart plug. And whose principles is still defining today’s world.

I just find that I learn faster by interrogating (or being interrogated by) a lossy encyclopedia than I do by reading textbooks or stackoverflow.

I'm still the one doing the doing after the learning is complete.

There is some line here. I don’t know if it’s introvert/extrovert but here are my observations.

I’ve noticed colleagues who enjoy Claude code are more interested in “just ship it!” (and anecdotally are more extroverted than myself).

I find Claude code to be oddly unsatisfying. Still trying to put my finger on it, but I think it’s that I quickly lose context. Even if I understand the changes CC makes, it’s not the same as wrestling with a problem and hitting roadblocks and overcoming. With CC I have no bearing on whether I’m in an area of code with lots of room for error, or if I’m standing in the edge of a cliff and can’t cross some line in the design.

I’m way more concerned with understanding the design and avoiding future pain than my “ship it” colleagues (and anecdotally am way more introverted). I see what they build and, yes, it’s working, for now, but the table relationships aren’t right and this is going to have to be rebuilt later, except now it’s feeding a downstream report that’s being consumed by the business, so the beta version is now production. But the 20 other things this app touches indirectly weren’t part of the vibe coding context, so the design obviously doesn’t account for that. It could, but of course the “ship it” folks aren’t the ones that are going to build out lengthy requirements and scopes of work and document how a dozen systems relate to and interact with each other.

I guess I’m seeing that the speed limit of quality is still the speed of my understanding, and (maybe more importantly) that my weaponizing of my own obsession only works when I’m wrestling and overcoming, not just generating code as fast as possible.

I do wonder about the weaponized obsession. People will draw or play music obsessively, something about the intrinsic motivation of mastery, and having AI create the same drawing, or music, isn’t the same in terms of interest or engagement.

One recent example of boilerplate for me is I’ve been writing dbt models and I get it to write the schema.yml file for me based on the sql.

It’s basically just a translation, but with dozens of tables, each with dozens of columns it gets tedious pretty fast.

If given other files from the project as context it’s also pretty good at generating the table and column descriptions for documentation, which I would probably just not write at all if doing it by hand.

A similar, non-LLM battle, is a global find and replace, but _not quite identical_ everywhere. Do I just go through the 20 files and do it myself, or try to get clever with regex? Which is ultimately faster...

I’m doing a lot of upgrades to neglected projects at the moment and I often need to do the same config over and over to multiple projects. I guess I could write a script, or get AI to write a script, but there’s no standard between projects. So I need the same thing over and over but from slightly different starting points.

I think you need to imagine all the things you could be doing with LLMs.

For me the biggest thing is so many tedious things are now unlocked. Refactors that are just slightly beyond the IDE, checking your config (the number of typos it’s picked up that could take me hours because eyes can be stupid), data processing that’s similar to what you have done before but different enough to be annoying.

I don’t do much of the deep prompting stuff but I find AI can write some code faster than I can and accurately most of the time. You just need to learn what those things are.

But I can’t tell you any useful tips or tricks to be honest. It’s like trying to teach a new driver the intuition of knowing when to brake or go when a traffic light turns yellow. There’s like nothing you can really say that will be that helpful.

I am still working on tweaking how I work and design with Claude to hopefully unlock a level of output that I’m happy with.

Admittedly, part of it is my own desire for code that looks a certain way, not just that which solves the problem.

Me too. I’ve been playing with various coding agents such as Cursor, Claude Code, and GitHub Copilot for some time, and I would say that their most useful feature is educating me. For example, they can teach me a library I haven’t used before, or help me debug a production issue. Then I would choose to write the code by myself after I’ve figured everything out with their help. Writing code by myself is definitely faster in most cases.

That's what rubber ducking is

In this case LLM is probably the answer. I’ve done this exact thing. No messing with regex or manual work. Type a sentence and examine the result in a diff.

I’ve just had to do just this, a one line prompt and one example was the difference between mind numbing work and a comfortable cup of coffee away from the monitor.

Writing the code in the grand scheme of things isn't the hard part in software development. The hard parts are architecture and actually building the right thing, something an LLM can't really help you with.

It's not AI, there is no intelligence. A language model as the name says deals with language. Current ones are surprisingly good at it but it's still not more than that.

It sounds better when you get more specific about what it is. Many people have fallen prey to this and gone a tad loopy.

What? Leading edge LLMs are great at architecture, schema design and that sort of thing if you give them enough context and are not working on anything too esoteric. I’d argue they are better at this than the actual coding part.

> For example, they can teach me a library I haven’t used before.

How do you verify it is teaching you the correct thing if you don't have any baseline to compare it to?

That there's really "nothing you can say to help someone develop yellow light stop/go intuition" is just wrong. There are guiding principles that give structure, even if you can’t compress the whole skill into a single rule.

Sure, some skills are more about practice, not rules, but hopefully you're not a driving instructor.

You are right, I don't have any baseline. I just try it and see if it works. One good thing about the software field is that I can compile and run the code for verification. It may not be optimal, but at least it's testable.