One Month With Claude Code

A the end of May/beginning of June I decided to try and fully embrace agentic coding into my workflow. For the last 30ish days I have had claude code write the majority of my code and taking on a more product manager role.

This is my experience so far and based on other articles I have read it seems to mimic what other developers going down the same path.

The TL;DR of this:

• make it follow a plan
• manage context as efficiently as possible

Side note: I mainly write Golang, (and given it's simple nature seems to work very well with agentic coding agents) so these tips might not apply to your specific language of choice.

If you want to see this in action, I have also made a video about my approach to 'vibe coding':

You can do more

One of the first discoveries was that I can now effectively (at least, it feels more effective, time will tell) work on more things simultaneously than I could before from the simple fact that I now describe what/where/how something should be added/updated/deleted and then let claude code cook.

I often work on multiple projects at once, and context switching from one to another to has always taken me a bit of time (note: from switch to writing code). I have the overall context of the project, and it has been much easier to describe and plan what needs to get done, than to actually write it, across projects.

However, this also produces a lot of code that I'm not on a first name basis with, that I need to make sure is sound and of high quality. In Go, you tend to only have one way of doing things so most of the time, so the agent more often than not gets the code right. This is a general pro of Go, it pushes you to focus on the problem at hand and how that is best solved, not what elements/features of the language you chose to use.

But I can still produce a PR that introduces 1000s of new lines in a couple of minutes and, we have to remember what Biggie once said:

Mo Code Mo Problems

The jury is still out on this one with a heavy bias towards worry. Do I really understand all the outputted code? How is my understanding of the overall structure? I review all the code generated by claude code as I would any other co-worker. This does catch some issues but most of the bugs/mistakes/errors I catch in the planning phase.

Garbage in Garbage out

You see a lot of articles and arguments that agentic coding produce absolute garbage code and that if you're wowed by its capabilities, you're probably a bad developer. That might be true, and I might just be a bad developer, it's in the realm of possibilities, but I have seen good code being produced when following a specific workflow.

Claude code is great at following instructions. Making sure it has a solid plan to follow will correlate with higher quality code being outputted. It still makes mistake and I sometimes have to jump in and make edits or guide it in the general direction I want it to go.

Now, I tend to work in a two step flow where I first have it create a plan based on my general directions (files, design patterns, algos etc). I then review that plan in a markdown file and once happy, type /clear to give it more context, point it to that plan and let it cook.

My CLAUDE.md file currently look like this:

 1# Workflows
 2
 3This is a collection of workflows. When the user tells you to use one of these workflows YOU MUST FOLLOW ALL STEPS in the outlined order.
 4
 5An example of the user specifying what workflow to use:
 6workflow: standard. <task description comes afterwards>
 7
 8## Standard
 9
10This is the most commonly used workflow and should be your default if in doubt.
11
12Do not start implementing the task without explicitly being told by the user to do so.
13
141.  Think hard about the task given (collect context and get deep understanding)
152.  Ask the user questions if you have any doubts
163.  Generate a plan for how to implement the task and save it to a file called task.md. Once you have saved your plan, provide the user with a 2-3 line summary of the plan and of your understanding of the task. It's VERY important to give the user opportunity to correct both the plan and understanding.
17
18## Prepared Task
19
20This is used when there is a complete task outline in a task file the user will point you to.
21
221. Examine the content of the task file
232. Think hard about it and investigate files to gather context
243. Ask any questions you might have
254. Provide the user with a short summary of your understanding for approval BEFORE beginning
265. Implement the prepared task once approval is given from user

Sometimes it's a bit trigger happy, ignores this planning phase and jumps straight into coding. Most of the times though, it creates a good plan with a clear direction and structure so that I can open a new agent with a fresh context window, to actually implement the task.

These two elements, planning and context management, goes hand in hand. With no plan, it can still do pretty cool things but they are way more random. Planning adds a bit of determinism into the workflow. Managing the context window improves the output.

I sometime break a feature down into multiple sub-tasks that have its own steps and branch, aiming at a change of roughly 500 lines for each sub-task. When the agent completes on sub-task, I have it add a summary of the work, so that when a new agent picks up the next task it has sufficient context of what has come before. This often stops it from going wild with the search tool, filling up the context window with a lot of unnecessary files and code.

If you have follow Thorsten Ball's excellent How to build an agent you have first hand experience of just how 'empty' a world view the agents have when you spin one up. And even though context windows has gotten larger in the last couple of years, filling it too much hurts the output. The analogy to a human brain is apt here: we can only hold so much context in our head before we start forgetting details, confusing various elements etc.

More code reviews

I've already talked about this but I want to stress it: you either just go into complete yolo/vibe mode and accept everything the agent outputs as gospel, or you meticulously review it. I hate doing code reviews, it's something that provides me with absolute zero joy. But, I like building products even more that I'm willing to do more code reviews, if it gets a product out faster.

This is the trade-off, at least from my experience, that you have to make. You have now become part code reviewer and part product manager. Depending on your reasons for getting into tech this will either be fine or horrible. The code is no longer yours,BUT it's still your responsibility to ensure that whatever goes into master is of high enough quality.

Make it Work, Make it fast, Make it pretty

One of my first coworkers would always tell me:

Remember mbv, make it work, make it fast, make it pretty. And always in that order

That quote has followed me throughout my career and served me well. With claude, I feel like I make it through the loop faster. Having claude create a naive implementation fast, so I can verify this is the correct path or not, and then make improvements once I have more confidence that this path is a good bet. Code is temporary, at least when working on applications (not so on libraries), and we should treat it as such. With AI, this has now become a much more feasible approach as the time investment is lower.

I still do all the planning, but the making it work part, that has been taken over by claude. My thinking remains that the faster the feedback loop on making it work, the better the end result will be. I might just end up building the Homer car faster, true, but with some discipline and skepticism, I'm betting on this being very unlikely.

The future is now, old man

Now, there might be one question that lingers in your mind, and have for some time: will this replace me?

I think the answer is: maybe. It's definitely possible that these models gets so good that everyone with a little bit of know about software and tech can start building products, purely by prompting. But I also think it's the wrong question to ask. Instead, I think you should ask yourself: how will this change my work?

The big tech CEOs have all been out making big bold statements that in X months, developers will be replaced by AI. But, like the self-driving car, this timeline always seems to shift to sometime next year while they keep hiring new developers.

And it's not like they have a vested interested in generating panic that you will be left behind if you do not adapt these tools they are selling /s.

I think there are two ways to look at this:

1. When WordPress came about, the end result was not fewer developers, but exponentially more websites and therefore also more developers. The market simply grew to accommodate more developers since the demand was higher. Sure, it's very hard now to have a business that charges 5k USD to build simple websites. But the tech industry has never been bigger. I suspect the same thing will happen with AI tools.
2. Let's say that tomorrow someone invented a new surgical machine that you could prompt to do an operation, like: "You're an expert surgeon, and your task is to remove the patients spleen" and it would then do it. If I then gave you the choice between having a trained medical professional write the prompt, or me, who would you choose?

I'd still choose the expert.