Author: Muhammad Muhsin

  • My 2026 Development Workflow: Claude Code Desktop + Cursor

    My 2026 Development Workflow: Claude Code Desktop + Cursor

    I’ve been refining my development workflow over the past few months, and I’ve landed on a combination that feels incredibly productive: Claude Code from the Desktop app paired with Cursor for code review. Let me walk you through how I work.

    Anthropic recently added a native “Code” tab directly inside the Claude Desktop app. It is a GUI for the engine that powers the CLI. One notable feature is its support for isolated Git worktrees. This means you can have a brainstorming conversation in one tab while a “Code” session runs in another, making changes in a separate worktree that won’t touch your main working directory until you’re ready to merge.

    Why not git worktree? My workflow is simple enough that I just work directly in my main/feature branch and review everything in Cursor before committing. But if you’re juggling multiple experimental features or want that extra safety net, the worktree support is there.

    Why not the CLI? I know many developers swear by the Claude Code CLI, but I’ve found the Desktop app suits my workflow better. There’s something about having a dedicated window for my AI conversations that keeps things organized. I can easily reference previous discussions, and the interface feels more natural for the kind of back-and-forth dialogue I have when working through complex problems.

    The Workflow

    Here’s how my typical development session looks:

    1. Brainstorm with Claude Desktop

    Before writing any code, I start by talking through the problem with Claude. I describe what I’m trying to accomplish, share relevant context about my project, and bounce ideas back and forth. This conversation helps me clarify my thinking and often surfaces edge cases I hadn’t considered. It’s like having a patient colleague who’s always available to rubber duck with.

    I then ask Claude to generate a prompt for Claude Code based on this discussion.

    2. Generate Code with Claude Code

    I open Claude Code in the Desktop app and paste in the prompt generated from step 1. It would have context about my project structure, the technologies I’m using, and any constraints I’m working with. Claude generates code, explains its reasoning, and I can ask follow-up questions right there in the conversation.

    3. Review in Cursor

    Once Claude has generated the code, I switch to Cursor. This is where I put on my reviewer hat. I don’t just blindly accept what the AI produces—I read through it carefully, understand what it’s doing, and verify it aligns with my project’s patterns and standards.

    Cursor’s diff view makes this review process smooth. I can see exactly what’s being added or changed, accept individual hunks, or modify the suggestions before committing.

    4. Test, Accept, and Commit

    After reviewing and testing, I accept the changes I’m happy with and commit them with meaningful commit messages.

    Why This Combination Works (for me)

    The separation of concerns is what makes this workflow powerful:

    • Claude Desktop for Brainstorming — This is where ideas take shape. I describe the problem I’m solving, share context about my project architecture, and have a back-and-forth conversation to explore different approaches. Claude helps me think through edge cases, consider alternative implementations, and refine my requirements before writing any code. By the end of this phase, I have a clear mental model and a well-crafted prompt ready for code generation.
    • Claude Code Desktop for Generation — With the refined prompt from brainstorming, I switch to Claude Code which has direct access to my codebase. It understands my project structure, existing patterns, and dependencies. The code it generates is contextually aware—it follows my naming conventions, integrates with existing modules, and respects the architectural decisions already in place. I can iterate here too, asking for adjustments or alternative approaches.
    • Cursor for Review — This is my quality gate. I examine every diff carefully, understanding not just what changed but why. Cursor’s interface makes it easy to accept good changes, reject problematic ones, and make surgical edits where needed. This deliberate review process ensures I never ship code I don’t understand. It’s also a learning opportunity—I often discover new patterns or techniques by studying what the AI produced.

    This two-step process forces me to slow down and actually review what the AI produces. It’s easy to fall into the trap of accepting AI-generated code without understanding it. By deliberately switching tools for the review phase, I create a mental checkpoint that keeps me engaged with the code.

    Tips for This Workflow

    1. Be specific with Claude — The better your prompts, the less cleanup you’ll need in Cursor
    2. Review as much as possible — Don’t let the convenience of AI make you lazy about code review
    3. Commit incrementally — Small, atomic commits make it easier to track what the AI contributed
    4. Keep learning — Use the review phase as an opportunity to understand patterns you might not have written yourself

    Final Thoughts

    AI coding assistants are powerful tools, but they work best when you stay in the driver’s seat. My Claude Code Desktop + Cursor workflow keeps me productive while ensuring I remain the decision-maker for every line of code that ships.

    If you’ve been looking for a way to integrate AI into your development process without losing control, give this approach a try. The key is finding the right balance between leveraging AI’s capabilities and maintaining your own understanding of the codebase.

    Thanks for reading. Let me know whether you agree/disagree or have a different take.

  • Once You Go Mac — Should You Go Back?

    Once You Go Mac — Should You Go Back?

    One of my first bosses, on the day I joined the company asked “Why are we using Windows?” as they saw me struggle with setting up a project using Docker on my Windows laptop. The following day I got a MacBook Pro. I thought I would not look back.

    And look back I did. And here I am writing a blog post on a Windows desktop 7 years later.

    As the walled garden kept getting richer, the walls started climbing higher. That is not the issue really. The cost of staying within those walls increased as well.

    By December 2025, I caved in and got a Nothing Phone. Boy do I love a nice clean Android phone.

    Shortly after, I realized what started with an innocent Mac purchase had sucked me in deep in to the ecosystem. Time to get in control, I decided.

    That was when I realized I suddenly wanted a PC. In this economy, you may ask. Well, several friends advised that it is better to get it TODAY than to wait another day. So, by the last week of December, I went and purchased a PC with 32GB memory and a GeForce 5060 TI Graphics with 8GB video memory. Plan is to try and run some local LLMs and hoping it speeds up development work.

    Now, Should You Go Back?

    I am still seeing some issues around npm modules installing on Windows. Either that or I need to figure how to do it the Windows™ way.

    At this point in time, I am giving myself a few months – iPhone on left pocket and Android on the right. MacBook on the desk and a Windows tower on the ground. Hoping to go like this and see where it takes me.

    Here are my past writing on this topic:

    Let me know your thoughts on the whole ecosystem war!

  • A Decade with WordPress: What I’ve Learned (and Built) Along the Way

    A Decade with WordPress: What I’ve Learned (and Built) Along the Way

    I logged in to this site today, and was pleasantly surprised to be welcomed by this notification.

    I figured today, is as good as any day to reflect on my time using WordPress and what I had been doing with it.

    2015: The Beginning

    Created a blog at mtwoblog.wordpress.com thereby creating a free account on WordPress.com. Wrote about my experiments with Arduino. Little did I know my nephews would pick up that hobby almost a decade later.

    2016: It Gets Real

    Moved from a free hosting to a self-hosted site with a custom domain. Hosting was provided by my friend who now runs GuardKite. Learned about custom plugins and themes as well as about the WP repository.

    Started frequenting the WordPress Colombo Meetup group. Met some amazing folks who I am in touch with until today.

    Also, founded a WordPress agency based in Colombo.

    2017: Community First

    Helped organize the first WordCamp in my country.

    Explored the WordPress REST API and GraphQL; two technologies that would define a large part of my career.

    2018: Going Global

    Wrote 3 articles for Smashing Magazine – a leading web publications for those working on the web.

    Spoke at my first large online conference; another aspect that would go on to define my life and career.

    2019: The Big League

    Joined rtCamp – a top WordPress company in the world as a React Dev working remotely.

    Represented at WordCamp US – my first flagship event – albeit remotely, as I did not get to physically be there.

    2020: Adapting

    COVID happened. I continued working remotely and writing on various topics, such as lessons learned which were not strictly about work or tech. This category of my writing resonated a lot with you all and I love to write about it too.

    2021: Going Headless

    Worked on a production headless WordPress project with GraphQL and Gutenberg. Continued speaking at a few events including the first WordCamp India.

    It’s been an incredible decade. What started as a simple Arduino blog on WordPress.com has evolved into a career, a community, and a way of life.

    2022: Deepening Roots

    Continued deepening my expertise in headless WordPress and the block editor. The ecosystem was maturing rapidly, and I found myself at the intersection of traditional WordPress and modern JavaScript frameworks.

    2023: Full Site Everything

    Expanded my speaking engagements and continued contributing to the WordPress community. The rise of Full Site Editing brought new opportunities to explore and share knowledge about the evolving platform.

    2024: Building Forward

    A year of consolidation and growth. WordPress continued to evolve, and so did my role within the ecosystem. The community remained as vibrant as ever, with new faces joining and veterans continuing to contribute.

    2025: A Decade In

    And here we are – 10 years since I first created that Arduino blog. WordPress has been more than just a platform; it’s been a gateway to incredible opportunities, lasting friendships, and continuous learning.

    Looking Back, Moving Forward

    Ten years ago, I couldn’t have imagined where this journey would take me. From experimenting with Arduino projects to writing for Smashing Magazine, from attending local meetups to speaking at international conferences, from running a small agency to working with one of the top WordPress companies in the world – every step has been shaped by this remarkable open-source community.

    WordPress taught me that technology is ultimately about people. The code we write, the sites we build, the content we create – it all comes back to connecting with others and making their lives a little bit better.

    Here’s to the next 10 years. 🎉

    Conclusion

  • Why I Still Bet on WordPress

    Why I Still Bet on WordPress

    Every few months, someone declares that WordPress is dead.

    I keep building outside it — and still coming back.

    Not because I’m stuck.

    Not because I don’t know better tools.

    But because after a decade of shipping real products, WordPress continues to win in places most comparisons ignore.

    Yes, I’ve built outside WordPress

    I’ve pulled Gutenberg out of WordPress entirely to build editor experiences. I’ve shipped headless setups where WordPress is nothing more than a content API. I’ve built React applications that never touch PHP. I’ve worked on projects where WordPress would have been the wrong choice — and I knew it.

    I’m not betting on WordPress because it’s all I know.

    What I got wrong about headless & decoupled frontends

    For a long time, I believed headless and fully decoupled frontends were the inevitable future — and not without reason. I chased cleaner architectures, React-first workflows, and the promise of total flexibility. In many cases, they delivered exactly that.

    What I got wrong was treating this approach as a default instead of a tool.

    The hidden cost wasn’t performance or technical complexity — it was friction. Previews broke. Editorial workflows slowed down. Simple changes required deploys. Teams gradually lost autonomy in ways that were easy to ignore at first.

    Headless isn’t the problem; uncritical adoption is. Over time, I learned that most projects don’t need maximum flexibility. They need reliability, ownership, and a stack that doesn’t fight back.

    That realization is a big part of why I still bet on WordPress today.

    What Gutenberg quietly got right

    Gutenberg’s value isn’t the editor — it’s the architecture underneath.

    Blocks are portable UI contracts. A block defines its structure, its attributes, its allowed variations. That definition travels with the content, not the theme. Switch themes, the content survives. Query blocks programmatically, the structure is already there. This is what years of shortcode chaos never gave us.

    Then there’s the shift toward declarative configuration. block.json and theme.json moved WordPress away from scattered PHP hooks toward predictable, tooling-friendly JSON. You can lint it, version it, generate it. It’s not perfect, but it’s a direction that finally aligns with how modern development works.

    The separation of structure from styling matters more than people realize. Classic WordPress tied content to presentation so tightly that switching themes meant rebuilding pages. Blocks broke that coupling. Structure lives in the content layer; styling lives in the theme. Long-term projects benefit from this in ways that aren’t obvious until year two or three.

    Blocks also scale better than their reputation suggests. Patterns, variations, and InnerBlocks let you build component systems without page builder bloat. Agencies are shipping block libraries now — not plugins full of shortcodes, but composable pieces with real contracts.

    Gutenberg is misunderstood by both its critics and its fans. Critics see it as a slow page builder chasing Elementor. Fans oversell it as a design tool for non-developers. Both miss the point. The real value is that WordPress finally has a content model that isn’t just HTML in a database column. That’s a foundation you can build on for years.

    Why I still bet on WordPress

    At this point in my career, I care less about architectural purity and more about leverage.

    WordPress gives me distribution, mature editorial workflows, and a content model that has finally caught up with modern development. It lets me choose when to decouple, when to go headless, and when to keep things boring — without forcing that decision upfront.

    Most platforms push you toward extremes. WordPress lets you stay in the middle longer, and that’s where most real projects live.

    I don’t bet on WordPress because it’s perfect. I bet on it because it compounds. The skills last. The ecosystem lasts. The content lasts. And with Gutenberg, the architecture finally does too.

  • DIY Breadcrumbs in WordPress with Full Site Editing

    DIY Breadcrumbs in WordPress with Full Site Editing

    Let’s look at how you can use Gutenberg and Full Site Editing to create Breadcrumbs for your WordPress site.

    You would need to install the latest version of WordPress and a plugin that has FSE (Full Site Editing) support.

    You would also require the The Icon Block by Nick Diego.

    Here’s the code. You can copy it and paste it in your Single Post template.

    Once copied and saved, the frontend of the template would look something like this:

    Enjoy!

  • Add Multiple Products to WooCommerce Cart at Once

    Add Multiple Products to WooCommerce Cart at Once

    We were working on a WooCommerce project that required us to add multiple products to the cart from a single click of a button.

    We wanted a solution from the JavaScript side, and we came up with the following code. This should fire when the “add to cart” button is clicked:

    Here’s a gist that contains the solution.

  • WP REST API can still cut it

    WP REST API can still cut it

    Most developers have used an API (and more specifically the REST API) in some point in their careers; and a WordPress developer is no exception. We may have used the WordPress REST API for fetching data from a remote WordPress instance, or update some record somewhere with authentication or to create a Headless WordPress site. Perhaps we simply used it within a Gutenberg block.

    GraphQL is an alternative to the REST API, and also a great technology. However, using GraphQL with WordPress requires the installation of a new plugin. If you are using GraphQL to merely solve the under-fetching/over-fetching problem for basic queries, you might want to continue reading this post.

    WP REST API 101

    The easiest way to play with the WP REST API is to visit any WordPress site’s URL followed by /wp-json. I’d recommend a REST client like Postman or Insomnia. In case you do not download these apps, you can visit the URL on your browser. If you go this route, however, I’d recommend an extension to view JSON data. You can find them on your Browser’s extensions library. Taking this site as example, let’s say you visit the following URL:

    https://muhammad.dev/wp-json

    You will get a huge chunk of JSON data. There will be multiple namespaces. I’d recommend you go explore the the WP namespace first:

    https://muhammad.dev/wp-json/wp/v2

    You will get the endpoints inside of the core WP namespace. Let’s look at the latests posts:

    https://muhammad.dev/wp-json/wp/v2/posts

    Solve over-fetching using _fields

    If you followed the last link, you would have seen a bunch of fields for the latest 10 posts. Let’s say you only need the title, and excerpt. Here comes the key part: you use the _fields URL parameter to limit the fields to just what you want:

    https://muhammad.dev/wp-json/wp/v2/posts?_fields=title,excerpt

    The above will only return the posts’ titles and excerpts. This would reduce the load time significantly since it’s much less data as compared to retrieving the entire dataset from the posts endpoint.

    Get the full categories, tags, and featured image

    Another “limitation” with the REST API is that you cannot see the name or slug of the attached category or tag for a post if you go to the /posts endpoint.

    The solution to this is to pass the _embed param to the URL.

    https://muhammad.dev/wp-json/wp/v2/posts?_embed

    The above will give you the terms (categories, tags) used for the posts. Additionally, you will also get the featured image details for the give post. This will save you from making multiple calls to the remote endpoint, thus saving time and money.

    Although this is not a full-on nested call like you can do with GraphQL, this is good enough for a lot of use cases.

    A note on using _fields and _embed

    As you try to use these tips, you would be tempted to use both the _fields and _embeds params in one call. You will notice that it is not possible to do so.

    When I tried the above scenario, it returned empty results. So, I followed this solution StackOverflow to get over this roadblock.

    TLDR;

    Perhaps you are discouraged from using the WP REST API because it fetches fields you do not need. Perhaps it is because the results do not contain the featured image URL or the category/tag name and slug. If so, then you might want to consider sticking to the REST API before looking elsewhere.

  • New to WordPress Development? Here’s a 2025 Guide!

    New to WordPress Development? Here’s a 2025 Guide!

    Precursor

    Let me start with a personal take.

    I started dabbling with WordPress 10 years ago in 2015.

    In that period, there have been changes several changes. Still, there have also been things that have stayed the same.

    I’ve learned an important trick; to develop foresight, you need to practice hindsight.

    Jane McGonigal

    Let’s focus on the fundamentals, first – the things that stood the test of time and will do in future.

    We can use WordPress for many purposes. It can serve as a tool builder, like a resumé maker. It can also be a platform or even a billboard. Nevertheless, the fundamental reason we use WordPress is for content.

    When we say content, it can mean many things – including Instagram reels or TikToks. However, with WP, content primarily means the written word. That’s what I believe the Word in WordPress stands for.

    Although, we can upload and embed videos and images, the power of words is what makes WordPress, well, powerful.

    So, it is a Content Management System as its core.

    The Foundations

    Now that we know what WordPress is (a CMS), let’s dive into what you need to learn to become a developer in the short term.

    By near term, I mean a quarter of a year. Let’s say you start now; you could hopefully become a Junior WordPress Developer by June 2025.

    These are the tools you need to master to get going:

    1. An understanding of the WordPress basics. What is a post and how does it differ from a page? What is a post type? What is a taxonomy? How do I change a theme or install a plugin? And so on.

      There is an endless list of questions you may have as you follow through. I recommend you befriend your friendliest AI tool to ask questions and get clarity.
    2. A Development Environment. Avoid working on projects without a dev environment if you can. Do not work on projects with just a single production site where all the work happens. I also recommend having a local WP environment. This way, all your development work is on your computer. You can do this while you are working. LocalWP and Studio by WP.com are both great for beginners.

      Think of it this way. Would you be doing carpentry at the location of your customer or at your work shed? I would do it at my work shed or a home office shed (remote work FTW). So, let’s use a local development environment.
    3. Basic Web Development. I would say you should possess the basics of HTML, CSS, and JavaScript. I am not a purist, so w3schools.com is a good resource for learning that. If you happen to be a purist, head over to mdn!
    4. Some backend knowledge. It is also good to know some PHP and MySQL. Or even the basic syntax and ideas are sufficient.

      Again, ChatGPT is your friend. Pester it with your questions and test yourself against it.

    Intermediate

    Now, we are getting to where most developers should get to. However, a lot of them will take a false path. Others will stop with the foundations. For instance, they will still use the Classic Editor. They will rely solely on a Page Builder. They will also stick to store bought themes and plugins without considering any customizations.

    WordPress Hooks (filters and actions) 🪝 are an important part of advancing as a WordPress developer. It’s crucial we learn it right – and practice it.

    Gutenberg was merged to core in 2018 and there has been a mixed reaction from the community. I believe it is about time (albeit a bit too late) to embrace the block editor with both arms.

    There are so many terms when it comes to the block editor. But keeping abreast of the nuances pays off handsomely in the long run.

    With that said, let me throw some words:

    1. Blocks – they can be core or custom
    2. Block Patterns
    3. Block Filters
    4. Block Styles
    5. Block Variations
    6. Block Plugins
    7. Block Themes and Full Site Editing
    8. Block Templates
    9. Reusable Blocks
    10. Dynamic Blocks – as opposed to Static Blocks

    I do not want to explain here what each means. Nor do I want to be considered an expert in critiquing the decisions that went into its nomenclature. You could learn a ton about these from fullsiteediting.com or through Google / ChatGPT.

    You can also learn from wpdevelopment.courses. Please note, it is a paid resource and I am a student of the course. The course helped me a ton to level up in block theme development. And no, I am not being paid to say this.

    ES2015+ or ES6 is also a decade old now. And React is 12 years old now; almost a teenager. The reason I mention it is so that we are aware its about time we learned these. So along with learning Gutenberg, it’s essential to also learn modern JS.

    Of course, here comes the other essentials like security best practices. Escaping, Sanitizing, Validating – the whole nine yards.

    An excellent resource is WPVIP’s course on security.

    It could take a year or more to get comfortable at this.

    Advanced

    You are in the big boy league now.

    It can take a several years to become great at WordPress.

    Courses from here are great to get good at some advanced WP concepts.

    Also, feel free to go through these best practices.

    The best way to become great, in my opinion, is to go through the works of the best people in the industry.

    For example, reading through WP Core or Gutenberg Core’s code on GitHub, perhaps reading through a major plugin’s code like Google Site Kit, or by contributing to core and other open source software yourself.

    An obvious way to get advanced is by working on large site rebuilds or plugins that touch many sites and has great impact.

    Closing Thoughts

    Do not forget about the community.

    You would be doing yourself a great favor by participating in dialog with the WordPress community, over on Twitter or at local events such as Meetups and WordCamps. A friend I made at a meetup 10 years ago is my almost like a mentor now!

    Of course, when you get to the advanced level, it’s good to contribute back to WordPress in the form of code, events, teaching, encouraging, documenting, organizing, volunteering, and so on.

    So, how do I get started?

    It depends on what you want to achieve with WordPres.

    If I were to give you one call to action, it would be that you register as a member of WordPress.org – you will hopefully look back and thank yourself that you did so.

    The more important CTA, however, is to head over learn.wordpress.org and choose your path!

    Closing Thoughts

    I initially set out to write about the WordPress ecosystem—the so-called bubble where outsiders often dismiss WordPress developers as “not real developers.” Instead of merely highlighting a problem, I decided to offer a solution: a practical roadmap to becoming a proficient WordPress developer. I hope this approach provides real value and inspires you to embrace the journey ahead.

    Thank you for reading this far.

  • Siri-controlled DND 🎧 for my office room

    Siri-controlled DND 🎧 for my office room

    Pausing notifications on your phone is great. The iPhone’s Do Not Disturb (DND) feature is also great. Would it not be awesome if we had a DND for our room/office? Well, that was when I had an idea for a mini project.

    My nephews and I went to a local electronics store and bought some gadgets. I just bought the ESP32-C3, which has two USB-C ports.

    These were the steps I did in order. Of course, ChatGPT helped me every step of the way.

    1. I ensured the ESP32 was working by running a blinking sketch, which I created using Arduino IDE.
    2. I then created an on-off switch using the BOOT button on the ESP32. This would turn the LED to switch between Green and Red alternatively each time you press the BOOT button the the microcontroller.
    3. Then I connected the ESP32 to Blynk.
    4. Once it was connected to Blynk with the token, etc. I used three links:
      • One would turn the Green light on when a GET request is sent to it.
      • The other would turn the Red light on when a request was sent to it.
      • The third one would give the current status of the light.
    5. Then I did some configurations using Siri Shortcuts. They were:
      • Office Green: which would essentially visit the above link I spoke about followed by turning off Do Not Disturb on the iPhone/Apple Watch.
      • Office Red: which would essentially visit the second link above, followed by turning on Do Not Disturb on the iPhone/Apple Watch.
      • Office Switch: this would get the current status of the light. If the currentStatus was 1, it would run Office Green, otherwise it would run Office Red.

    The end result was something like this:

    In case you have any inspiring ideas for such projects, feel free to build on it and share to the world!

    If you find this post inspiring, I have done my job. If you asked yourself why not just close the door instead of this contraption? Well, then you have done your job of critical thinking.

    Cheers!

  • Dolphins, Deer, and a whole lot of splashes

    Dolphins, Deer, and a whole lot of splashes

    Today concludes our 4-day trip to Trincomalee, which is in the northeast region of Sri Lanka 🇱🇰.

    Here are some of the Instagram posts that came out of the trip:

    Follow me on the gram for more!

    Hopefully, 700km has made me a tiny bit wiser.

    Stay tuned for more travel and remote work content.