DEV Community

Juan Pablo Djeredjian
Juan Pablo Djeredjian

Posted on

How I use Claude Code to accelerate my software engineering job and improve my life

Claude Code has taken the software engineering world by storm and it's changing how the field looks in leaps and bounds. Prominent engineers are proudly saying that they're writing 0 lines of code already. Jaana Dogan, a Principal Engineer at Google working on Gemini, recently shared that she gave Claude Code a description of a distributed agent orchestrator problem, and it generated in about an hour what her team had been trying to build for the past year. She was careful to clarify: this was a proof-of-concept, not production-ready code. It still required validation, security reviews, performance testing. But still. An hour versus a year. Even with all the caveats, that's a staggering shift.

My feeling after working with Claude Code this year is actually: the upside is so huge that I'm surprised I'm not seeing it reflected in the amount of apps, features, and sheer progress in the software world. And I don't think we're in an early adoption phase anymore, as many argue. I think writing code has been commoditized already, and that just means the bottleneck has simply moved elsewhere: to generating new ideas, to testing and releasing, and above all, to distribution. The AI-generated apps might already be there, flooding the market; we're just not aware of them. They simply don't reach us.

And yet, while this is all exciting, it's also incredibly anxiety inducing. If you're a software engineer, you're probably feeling it too. Every week there's a new announcement, a new capability, a new "this changes everything" moment. And you're left wondering: am I keeping up? Am I falling behind? Will I still have a job in two years?

I don't have answers to those questions, I think nobody does yet for sure. But what I can tell you is how I've been using these tools to become significantly more productive, and how that productivity has actually made my job more enjoyable, not less. The more I use AI, the more I realize that the engineers who learn to collaborate effectively with these tools will have a massive advantage. That's what this post is about.

Section 1: Software Engineering

I'm not here to rehash Claude Code's features. Plenty of guides cover CLAUDE.md files, /commands, and skills. If you want a great starting point, Boris Cherny's thread (he created Claude Code) is excellent. His most striking revelation: "In the last thirty days, 100% of my contributions to Claude Code were written by Claude Code." And that includes 100% of the code written for the Claude Cowork project!

So, let me share what I've actually learned from almost a year of daily use. These aren't smart ways to use Claude's features, they're habits, workflows, and mental models that emerged from daily use. Things that simply weren't practical before Claude Code made them possible, but now are the very core of how I work as a software engineer.

Understand EVERYTHING

Joining a company used to mean months of gradual ramp-up. You'd slowly build mental models of different features, ask the same questions repeatedly, and forget half of what you learned. Today, there's no excuse for that.

With Claude Code, I send agents to investigate entire services, and point it to Jira tickets, GitHub PRs, Slack threads, whatever expands context. Then I have it produce an exhaustive, didactic guide in markdown and save it to a dedicated AI_DOCS/ folder in my repo.

Ask it to make extensive use of ASCII diagrams. Claude Code with Opus 4.5 really excels at this and is a wonder at explaining complex, multi-repo data flows and architectures.

Here's what I have Claude document for every major service:

  • Architecture overview
  • API endpoints and their purposes
  • Database collections and schemas
  • External service dependencies
  • Key files and their relationships

One of my guides distills dozens of conversations, PRs, and debugging sessions into a single source of truth. That's months of accumulated understanding I never have to rebuild.

The prompt pattern I use looks something like this:

Explore [SERVICE/FEATURE] and create comprehensive documentation:

1. Executive Summary - what is its core purpose?
2. Architecture - how is it structured? Include ASCII diagrams.
3. Data Flows - how does data move in and out? Visualize with diagrams.
4. API Routes - what endpoints does it expose?
5. Database - what does it store? Include schema overview.
6. External Dependencies - what other services does it call? How?
7. Key Files - where's the important logic?
8. Common Gotchas - what breaks? What's confusing? What's undocumented?
9. Common Operations - how do you test/deploy/debug it?
Enter fullscreen mode Exit fullscreen mode

This is your treasure. Every time you revisit that system, debug something adjacent, or tackle a related feature, you have instant context, both for yourself and to feed back to Claude. The knowledge compounds instead of evaporating.

Give Claude access to every possible tool

Claude will be able to use all tools at your disposal faster, more efficiently and deeper than you. There are some tools which I think are essential, and you'd be shooting yourself in the foot by not having them.

💡 If both options exist, I prefer CLIs to MCPs (which fill up the context and can be slow). CLIs are extremely capable and fast and will give you the same features (or more) than its respective MCP.

Here's my essential toolkit:

  • GitHub CLI: For PRs, issues, checking CI status, everything. Claude can create PRs, review code, check workflow runs, all without leaving the terminal.
  • AWS CLI: For debugging Lambda logs, checking SQS queues, DynamoDB queries. Also Localstack for local dev, which uses the same CLI interface.
  • Logs (Datadog): We use Datadog, so I have Claude query logs directly. When debugging production issues, this is invaluable.
  • Database (mongosh): Give Claude access to staging, and if you can, read access to prod. If you can't, staging should suffice to answer questions like understanding schemas or checking data states.
  • Slack MCP: This one's super important. So much historical knowledge and context is trapped in Slack (Searchable Log of All Conversation and Knowledge!). The point is, your LLM needs to access this data in a way that doesn't require you to copy paste.
  • Atlassian MCP: For Jira tickets and Confluence pages. Here I do use an MCP because I found the API to be annoying to work with directly.

Make all knowledge LLM-consumable

Every startup has that ONE person who knows how feature X works, what that esoteric Clojure project does, or how to wire up Salesforce in local dev. In the past, you'd schedule a meeting, frantically take notes, maybe record it. Then good luck rewatching that hour-long video every time you needed to follow the steps.

Here's the trick: AI can extract that tribal knowledge and turn it into permanent, queryable documentation.

A Meeting Copilot summary won't cut it here. When you need extensive detail (steps to follow, historical decisions, specific commands), a summary loses too much. You need the raw material: video + transcript.

Here's what I do:

  1. Record the knowledge transfer. Send a Meeting Copilot, or just screen-record while the expert walks you through the process.

  2. Get video + transcript. You want both. The transcript captures what was said, but the screen shares show what was done.

  3. Extract frames from the video. Claude can't process video directly (yet), but it can process images. I use ffmpeg to grab a frame every few seconds:

ffmpeg -i meeting_recording.mp4 -vf "fps=1/3" frames/frame_%04d.png
Enter fullscreen mode Exit fullscreen mode
  1. Point Claude at the frames + transcript. Ask it to create a detailed guide, using the frames as inline screenshots matched to the relevant steps.

The results are remarkable. Claude produced a step-by-step guide with screenshots accurately selected based on what was being discussed at each moment, pulling information from both the transcript and the shared screen.

Now you have a guide you'll never need to remake. But here's the real payoff: feed that guide back to Claude, and it can probably do the task for you.

This is what I mean by making knowledge LLM-consumable. Extract tribal knowledge once, and it becomes available to AI forever. The expert's time is captured, not lost.

Learn in context

Learning a new technology used to be tedious. Read the docs, try their toy examples, maybe spin up a starter boilerplate. But those never felt like real use cases. You'd understand the syntax without understanding how it fits into a real codebase with real constraints.

Claude Code flips this. Instead of learning in isolation, I learn in context: my actual app, my actual complexity, my actual requirements.

Here's what that looks like:

  1. Ask Claude: "What would [technology X] give me in this app? What are the tradeoffs?"
  2. Have it actually implement it
  3. Ask it to swap in a competing option
  4. Compare them side by side, in your codebase

A real example: I was building an app that needed agentic workflows and wanted to evaluate frameworks: OpenAI Agents SDK, Claude Agents SDK, Google ADK, and AWS Strands. I had Claude build a POC with the OpenAI SDK first, explaining the architecture and tradeoffs as it went. Once I understood how that worked, I opened multiple Claude terminals and asked it to rebuild the same functionality with each of the other frameworks, documenting the differences.

Within an afternoon, I had four working implementations and a clear sense of the tradeoffs. All in running code I could modify and extend.

Then I pushed further. I'd heard vaguely that Temporal could help with "long-running workflows" and human-in-the-loop patterns, but I didn't know how that would fit or help my app.

So I asked Claude: "What Temporal features could help me here?" It returned seven specific use cases, including the exact scenario I needed, each with proposal of parts of my codebase where it could help, with diffs and explanations for each.

But I didn't stop there. After going through the recommendations and understanding the proposals, I asked: "So, why is Temporal necessary? Can't I achieve this without it?" And it showed me a side-by-side comparison of both architectures, with side by side code samples pulled directly from the app I'd already built.

That's the difference. Real comparisons, in your code, for your use case. So you can learn and understand by making sense of new things in a context that actually matters and makes senses to you.

Use multiple AI tools together

Every model has blind spots. On any given run, one might miss an edge case, another might over-engineer, another might take a completely different architectural approach. When you run the same complex task through multiple models and compare their outputs, the differences themselves reveal tradeoffs you wouldn't have considered.

For any non-trivial task, I'll prompt:

  • Claude (via Claude Code)
  • Codex (OpenAI)
  • Gemini CLI (subsidized right now, basically free)

Then I compare their approaches. Sometimes one spots edge cases the others missed. Sometimes they propose completely different architectures. By combining insights from multiple outputs, I often end up with a more robust implementation than any single model would have produced alone.

I also do cross-model review. After one AI generates a plan or code, I have another review it:

Here is a plan that Claude generated for [TASK]:
[Paste the plan]

Please review this plan and identify:
1. Potential edge cases not covered
2. Security concerns
3. Performance implications
4. Missing error handling
5. Simpler alternative approaches
Enter fullscreen mode Exit fullscreen mode

Think of it as an AI forum. You put models in healthy competition, letting them challenge and refine each other's thinking. The result is better than what any single model would produce, and you get there faster than going back and forth with just one.

Section 2: How to use Claude Code to improve your life

A few weeks ago I read Molly Cantillon's "The Personal Panopticon" and it broke something in my brain.

Her core insight is this: we are drowning in data about ourselves and yet we remain catastrophically blind. Our commitments exist in six different apps and cohere in none. Our finances are scattered across brokerages that refuse to talk to each other. Our goals live in some forgotten note from January. We have more information about ourselves than any human in history, and we can barely see any of it.

Her solution to this problem is simple: Build your own panopticon. Put yourself in the tower. Use Claude Code as the apparatus of sight, but point it inward.

She runs multiple Claude Code instances in parallel, each watching a different part of her life. Finances, health, email, personal projects. Her finances get synthesized overnight from multiple brokerages, cross-referenced with market data, and she wakes up to a brief. Her product metrics get pulled automatically and turned into actionable insights. Her email reaches inbox zero with auto-drafted replies she just reviews.

I'm not there yet. But I started building toward it.

I have a main folder with a CLAUDE.md file where I let Claude know basically everything about me, or tell it what external data sources to pull from to know:

  • Who I am: name, age, where I'm from, where I live
  • Family situation: married, one kid, another on the way
  • What I do for a living, what company I work for
  • What my skills and gaps are
  • How much I make per year
  • How much my wife makes per year
  • What our expenditures are (rent, utilities, subscriptions, everything)
  • What our assets are (savings, investments, property)
  • What my schedule looks like on an average day
  • General life objectives (retirement goals, travel plans, where we want to live long term)
  • Near term projects (learning a new skill, home renovation, job considerations)
  • Health information relevant to decisions
  • Important relationships and commitments

Yes, basically everything there is to know about me. I know how that sounds. But I've realized that the more Claude knows, the more useful it becomes. When I ask "should I take this job offer?" it doesn't give me generic advice about pros and cons. It knows my financial situation, my career trajectory, my family plans, my risk tolerance. It can actually reason about MY situation, not some hypothetical person's.

To start this out, I asked ChatGPT (which has the memory feature) to create a comprehensive personal profile guide to be consumed by Claude Code. Since ChatGPT already knew a lot about me from our conversations over the past year, it was able to compile a pretty good starting point. Then I reviewed it, added details, corrected things it got wrong, and now I keep it updated as things change.

Some real question Claude has helped me answer:

  • Financial planning: "Given our income, expenses, and the baby coming, can we afford to move to a bigger apartment?"
  • Schedule optimization: "I want to start running again but my mornings are packed. Look at my routine and suggest where."
  • Decision making: "My manager offered me this role change. Here's what I know about it. What am I not considering?"
  • Goal tracking: "It's been 3 months since I set these goals. Pull up the file and help me review progress."

And unlike a human advisor who you'd have to re-explain your whole situation to every single time, Claude just reads the file and has full context immediately.

I'm also starting to play with Clawdbot, a self-hosted assistant that connects Claude to my messaging apps. So instead of opening a terminal, I can just message my AI through WhatsApp or Telegram, from anywhere.

Cantillon ends her essay with: "The tools of synthesis belong to the individual now. Govern yourself accordingly."

I'm trying to.

Top comments (0)