A Typical Day with Claude - My Workflow
Even though I haven’t written a single line of code by hand, I have produced lots of software and finished several projects this year. AI-first development has fundamentally changed what it means to be a software engineer, and I feel we’re just at the beginning of this revolution. With every new state-of-the-art model release I’m getting closer to the point where my markdown documentation with instructions for Claude Code is my source code, and the actual code is a build artefact, just like compiled executables are a build artefact of higher-level languages.
These days, I spend about 80% of my time on designing, planning, and brainstorming, 0% on writing lines of code, and 20% on getting Claude to behave by reminding it to not skip steps, deeply think, research before answering, be critical rather than agreeable, etcetera. Anyone who has used AI to build software will know: LLMs can convince you they’re experts, but they don’t actually know what they’re talking about, and it takes a lot of herding to keep it on track.
As CTO of early-stage startup Qrtr, we’re building out our brand new product, and I spend most of my time currently doing hands-on software design and development. Below is what a typical day of my AI-first software engineering workflow looks like using Claude Code.
The Documentation Setup
In my project root I have a docs folder with three main sections:
- developer-docs: architecture documentation, how to set up a development environment, key design decisions, etc. This is a mix of hand-written and generated documentation.
- plans: design and implementation plans generated by superpowers, the comprehensive set of skills and prompts I use to guide my workflow. There are about 100 plan files by now. I mostly don’t look at these; I consider them “machine readable” worked out versions of my ideas, ready for implementation.
- ideas: handcrafted high-level ideas I sketch out and use as input for new features with the brainstorm skill, and as the “source of truth” for what I want Claude to do. This is the main type of document I create by hand, although I often ask Claude to update a particular document with new insights and ideas as I progress with my brainstorm sessions.
All docs are markdown. For example, I’ve got a docs/ideas/db-abstraction.md where I explain that I want flexibility with my database and vector embedding backends: in-memory for tests, file-based for local dev, postgres for my demo environment, and SQL Server for production.
For another project I have a deep dive into the mathematics of rendering Mandelbrot fractals at extreme zoom levels, largely created by Claude during many research and brainstorm sessions. I’ve used sections of that as input for actual features I want to implement, like: “Read @docs/ideas/maths.md section 3.5 and let’s brainstorm about implementing this feature”.
The Actual Workflow
My workflow looks roughly like this:
We use Linear to create and manage issues and the overall roadmap. That’s where I work with my product guy, designer, and other stakeholders. It’s also where I add issues or ideas myself for work I want to track that isn’t otherwise visible to non-engineers.
I use GitLab for the code repo and CI/CD.
I take an issue from Linear (you can hook up the Linear MCP server to Claude but I haven’t used that much yet) and if it’s a big enough story I’ll start thinking about what the story means, and how I could implement it. I create a high-level ideas document to organise my thoughts, and then start brainstorming with Claude, using the superpowes “brainstorming” skill.
This makes claude ask me one question at a time to work out enough details for a technical design, which it will present to me for feedback.
Often it turns out that I hadn’t thought things through very well yet, so I keep running into issues I need to think about more, and sometimes I throw away the plan claude created and start again from my ideas document, often amended with new insights. When all goes well, I end up with a design document, and claude will create a technical implementation plan using the superpowers “writing plans” skill.
I commit everything so I’ve got a clean git workspace, and tag where I am so I can easily throw everything out and start over with amended plans if Claude messes it all up. Which happens fairly often for big complex jobs. This is usually not really a big deal, because the actual writing code phase is really only a small part of the workflow.
In a new session, I tell Claude to read the original idea, the design, and the implementation plan, and tell it to use the “executing plans” skill to implement it, using fresh subagents per task and the code review agent.
For bigger changes, I sometimes break down my ideas document in sections, and do the whole brainstorm/design/implementation plan/code process separately for each section.
While claude is creating code and using test-driven design, I either switch desktops to work on another feature or go get a coffee for 20 minutes. When I come back, hopefully Claude will not have created too much chaos.
Testing and Debugging
The last step of the superpowers workflow is usually running all linting, formatting, unit tests, and integration tests. Claude loves tests, because it gives a very clear, programmatic way for claude to know when it’s done — if the tests are worth anything which is not always the case!
After claude claims the automated tests are all passing, I manually run all tests myself. Claude tries to be very helpful and skips stuff if it thinks things are too difficult or too big. So I end up giving it error messages and tell it to fix stuff, or I tell it to keep iterating on my “run all quality checks” scripts until everything comes back green.
Then I do manual user acceptance testing. Sometimes it works. Sometimes I realise that Claude really has no clue what it’s doing, what’s important and what isn’t, and find that Claude has either done something completely different, forgot to implement something, forgot to actually integrate the new code altogether, or didn’t write meaningful tests so the tests pass but the code is broken.
With all errors, bugs, and failures, I go back to Claude and ask it to “systematically debug” (another superpowers skill) the issue. I give it as much detail as I think is useful and tell it to figure out the rest itself.
Conclusion
And that’s pretty much it. Some days it’s truly amazing and makes me super productive, other days it’s hugely frustrating and I end up resetting the branch and starting over. Some days claude feels dumber than other days. I have no idea if this is really me having a bad day, or if claude’s backend just doesn’t have the same computational power every day.
Every couple of days I discover something really dumb that Claude did. Like building a completely different code path for the database for a new feature that circumvents the normal database session pool. Or finding out that half of Claude’s test code just mocks everything and then tests that the mocks work, instead of testing the actual code.
So I need to actually look more closely at the code and the architecture, and maybe fix stuff.
Tips and Tricks
I generally try to not let Claude compact, run multiple Claudes in parallel so I can work on different stuff, use git worktrees to work on two or three features at a time, or work on a different project in the background.
I’m a 20x MAX user, exclusively use Opus 4.5, and I still get close to running up against limits.
Anyway, I hope that’s helpful.