My Development Workflow 2026-Q1 Edition

read

I’ve been talking to friends and colleagues about what I’ve been building at Runlayer with MCPs, and the same thing keeps coming up: my workflow. Most devs outside our X/LinkedIn bubble don’t know about the current state of the art in software engineering tooling. So here’s my attempt to share what’s working for me: links, approaches, and all.

Fair warning: this kind of post ages like milk in the sun.

You’re (probably) not losing your job

Developers are moving closer to the business. The era of agentic development has begun. I see engineers becoming deeper experts in product and domain areas (identity, SRE, tooling) while the technology to solve these problems becomes cross-cutting. Coding or learning a new language/stack is no longer the bottleneck.

In the future, I see software engineers writing the software factory (relevant OpenAI paper) instead of writing production code directly. We should expect new software verticals, like doctors creating software, the state of the art being pushed forward, but also a “fast food software” era where people spin up small disposable tools for personal use.

The fastest way to produce meaningful software has changed rapidly: ChatGPT copy-paste, then GitHub Copilot autocomplete, then Cursor, then Claude Code… and something new every week. What all this progress has in common is that the developer’s eyes don’t need to be on every character change anymore.

I like this analogy: context is like a scuba tank. The longer you can stay underwater, the better. The longer the context window we can feed our tasks with good reasoning, the better the output. Despite some skepticism about LLM architectures hitting a ceiling, we’ve found smart ways to keep this flow efficient. We started with a few tabs and autocomplete suggestions. Now you can have a full 10-hour session of working software being produced with minimal human intervention.

The Workflow

I split my workflow into five phases: brainstorm, design, plan, code, review + improve.

1. Brainstorm & Design

The idea phase is straightforward. I create a single markdown file, docs/IDEA.md or whatever, and dump everything I’m thinking about the problem. Caveats, possible future issues, codebase tweaks, edge cases. This is the time to say everything. In this phase, I deliberately avoid heavy AI intervention until I’ve fully stressed the outcomes myself.

Deep Research on ChatGPT is genuinely useful here, especially when the work involves an RFC or spec to follow.

Once the idea file exists, I take one of two paths (usually both, then pick whichever produces the better plan):

Option A: Clean up the idea file for grammar and conciseness, then feed it to Cursor with Opus 4.6 to write a design document.

Option B: Use the Superpower skills in Claude Code. The brainstorm phase here is excellent: it automates the idea back-and-forth, turning topics into workable features while investigating your codebase. If your guardrails are solid in the IDEA.md file, it does a great job asking pointed questions and turning your rough ideas into a structured plan.

The design-before-plan step is a good forcing function. It fills thought gaps, catches missing requirements, and surfaces hallucinations early, before they become code.

A few MCPs (more on those below) are helpful here: Context7 for documentation lookups, or your GitHub MCP in brownfield projects where you can pull in issues or previous PRs to give agents richer context.

Tip: Always ask for negative test cases. 100% code coverage isn’t enough. Multiple layers of tests build confidence, help agents get context, and serve as running documentation for AI agents.

The output of this phase: a design file with all the context needed for planning.

2. Plan

This is where automation shines. Feed your favorite agent the design file and let it generate a plan. In Cursor it’s a button. In Claude Code, it’s the Superpower plan skill.

Side note: You can run multiple worktrees and let agents work in parallel, or clone the repo multiple times. Just make sure each instance runs on different ports and resources. You don’t want to confuse your code/testing agents.

Take your time reviewing the plan. Usually ~90% of what’s written here is what your codebase will end up with. This is the moment to catch major hallucinations and ensure the final product matches your intent.

3. Code

Now it’s code time. A few things matter here:

AGENTS.md / CLAUDE.md files are critical. These are general guidelines scoped to a folder, and you can have specialized instructions in subfolders. That’s why clean architecture with clear boundaries matters: it prevents agents from getting confused and hallucinating.

You can also craft custom skills to kick off your coding job depending on what you’re working on. Sometimes you’re creating, sometimes condensing, sometimes fixing a single line.

Classic code metrics still apply. I’ve written before about type safety being your best friend, but cyclomatic complexity, fitness functions, and architectural tests are equally vital for codebase health.

I use Sonnet 4.5 for general coding tasks, sometimes Codex for frontend. If you have best practices for code quality and software engineering in place (now you have time to set them up), you shouldn’t have problems. Let your agents run tests. You can have a dedicated AGENTS.md just for testing.

Side note on bugfixes: TDD is your best friend here.

4. Review

Code finished. Now the real bottleneck: human eyes.

Greenfield projects usually mean a big boom commit with everything for the MVP. Even in brownfield, some cross-cutting features land in a single step, and the volume of changes can hurt.

Agent reviewers can help catch the obvious things (shout-out to Devin, and a firm boo to Sentry’s reviewer). But your experience is fundamental to ensure the code does what it needs to do without making the codebase worse. Review skills help here too, especially for catching AI slop: oversized comments, weird variable names, unnecessary abstractions. Zoom in and zoom out.

5. Improve

Your coding session is gold. Lots of assumptions and hallucinations were made along the way. This is the time to review your AGENTS.md files, add hooks, or craft new skills for your development process. Each session makes the next one better.

A Quick Note on MCPs

If you’re not familiar with MCPs, here’s a quick intro: they work like AI connectors. Instead of copying and pasting everything, service providers create these connectors so you can automate workflows more efficiently. Connect your favorite MCP client (Cursor, Claude, VSCode, Windsurf) to these connectors and automate all sorts of work:

“Get the last Datadog issues related to X, open tickets on Linear for each problem, start a sub-agent to triage, and write a plan to fix it.”
“Read all my emails and create a task list on Notion for today.”

The possibilities are only limited by your creativity.

Security Concerns

Of course, there are real concerns around security. It’s not easy to create safeguards for all these autonomous tools, and the attack surface for engineering teams is significant: credentials leaking, agents causing outages. This is the problem we solve at Runlayer. We empower teams to build even more automated workflows with security concerns covered in a single platform.

What a Good Day Looks Like

A good day starts with a prompt asking Cursor to check all my pending PRs, reviewing feedback from coworkers (especially those in other time zones), addressing and responding one by one. The occasional human intervention happens when a tradeoff needs discussion, but if the design is solid and requirements were aligned, no surprises should appear.

In parallel, I start dissecting new feature request designs by filtering Linear tickets. For mature designs, I create tickets and define priorities for the day, often with a single prompt.

When emergencies hit, I prompt with the Sentry link, investigate logs on CloudWatch via the AWS MCP, craft a plan, and report progress on Slack in real time.

The stack that makes this work: GitHub + Sentry + AWS + Linear + Slack bots.

All of these flows happen in my daily routine. The future is here. Embrace it.

Links

If you’re building automated workflows and care about security, check out Runlayer — it’s the platform we built to let engineering teams automate with MCPs while keeping credentials, access, and blast radius under control.

MCPs mentioned in this post

GitHub MCP Server — GitHub’s official MCP server for issues, PRs, repos, and more.
Sentry MCP Server — Access Sentry issues, errors, and AI analysis from your agent.
AWS MCP Servers — AWS Labs’ collection of 60+ MCP servers for AWS services.
Linear MCP Server — MCP server for Linear issue tracking.
Slack MCP Server — Slack’s official MCP server for messages, channels, and canvases.
Context7 — Up-to-date documentation lookups for your agents.