Tips for Improving Developer Workflows

Are you using Claude to autocomplete or to think in parallel with you? Many developers treat it like a faster tab key. The real power shows up when you use it as a second brain running alongside yours. Here’s what that looks like in practice. 1. Run Work in Parallel Spin up multiple sessions and worktrees so planning, refactoring, reviewing, and debugging happen simultaneously instead of sequentially. 2. Start Complex Tasks in Plan Mode Outline architecture and approach before writing code, so execution becomes clean and intentional instead of reactive. 3. Maintain a Living CLAUDE.md Document mistakes, patterns, and guardrails so Claude improves with your workflow and reduces repeated errors over time. 4. Turn Repetition into Skills Automate recurring tasks with reusable commands and structured prompts so you build once and reuse everywhere. 5. Delegate Debugging Provide logs, failing tests, or CI output and let Claude iterate toward solutions while you focus on higher-level thinking. 6. Challenge the Output Ask for edge cases, diff comparisons, cleaner abstractions, and alternative designs to push beyond “good enough.” 7. Optimize Your Environment Set up your terminal, tabs, and context structure so you reduce friction and maximize visibility while working. 8. Use Subagents for Heavy Lifting Offload complex or exploratory tasks to parallel agents so your main context stays clean and focused. 9. Query Data Directly Use Claude to interact with databases, metrics, and analytics tools so you reason about data instead of manually extracting it. 10. Turn It Into a Learning Engine Ask for diagrams, system explanations, and critique so every project improves your mental models. The difference is simple: Autocomplete makes you faster. Parallel thinking makes you better. The question is how you’re choosing to use it.

I've built 67+ AI agents in n8n. At first, I thought adding nodes and optimizing connections was what mattered. But I never really trusted them. Every output felt like a gamble. The bottleneck wasn't my architecture. It was my instructions. Avoid my mistakes and: 1. Separate static facts from inputs. Mixing them makes the agent guess context it should already know. → Example: Static = “Store opens at 9 AM.” Dynamic = “Order ID: 48281.” 2. Make the agent call out missing info. Guessing is the #1 source of silent failures. → Example: MISSING_FIELD: customer_email. 3. Force it to plan before acting. Step-planning stabilizes reasoning and reduces randomness. → Example: Plan internally. Output only the final result. 4. Give a fallback for impossible tasks. Without a fallback, the agent hallucinates a solution. → Example: ERROR_REASON: date_format_invalid. 5. Define “If X → Do Y” rules. Deterministic branching kills unpredictability. → Example: If date can’t be parsed → ask for a new one. 6. Allow creativity only where needed. Uncontrolled creativity = guaranteed hallucinations. → Example: Creative only in “Rewrite.” Everything else literal. 7. Limit the agent’s memory. Too much history makes the agent drift off-task. → Example: Use only the last 2 messages to determine intent. 8. Make it restate the task first. Repetition confirms the agent understood the request correctly. → Example: Task summary: extract the invoice number. 9. Validate inputs before generating outputs. Output built on bad inputs = guaranteed bad outputs. → Example: Invalid date: expected YYYY-MM-DD. 10. Require a termination signal. Your workflow needs a clear signal that the task is complete. → Example: End with “TERMINATE.” 11. Test your instructions with ugly inputs. If it only works on “happy path,” it’s not reliable - it’s lucky. → Example: Missing fields, malformed dates, weird formats. 12. Run a 10–20 sample eval before shipping. You can’t improve what you don’t measure. Vibes ≠ validation. → Example: Score each output: accuracy, format, tone, stability. 13. Iterate based on failures, not feelings. One word in your instructions can double your success rate. → Example: 2 outputs broke the format → tighten output rules. This is how you get from 30% to 80% success rate. Better instructions beat complex architecture. What's been your biggest challenge getting agents to behave consistently?

We know LLMs can substantially improve developer productivity. But the outcomes are not consistent. An extensive research review uncovers specific lessons on how best to use LLMs to amplify developer outcomes. 💡 Leverage LLMs for Improved Productivity. LLMs enable programmers to accomplish tasks faster, with studies reporting up to a 30% reduction in task completion times for routine coding activities. In one study, users completed 20% more tasks using LLM assistance compared to manual coding alone. However, these gains vary based on task complexity and user expertise; for complex tasks, time spent understanding LLM responses can offset productivity improvements. Tailored training can help users maximize these advantages. 🧠 Encourage Prompt Experimentation for Better Outputs. LLMs respond variably to phrasing and context, with studies showing that elaborated prompts led to 50% higher response accuracy compared to single-shot queries. For instance, users who refined prompts by breaking tasks into subtasks achieved superior outputs in 68% of cases. Organizations can build libraries of optimized prompts to standardize and enhance LLM usage across teams. 🔍 Balance LLM Use with Manual Effort. A hybrid approach—blending LLM responses with manual coding—was shown to improve solution quality in 75% of observed cases. For example, users often relied on LLMs to handle repetitive debugging tasks while manually reviewing complex algorithmic code. This strategy not only reduces cognitive load but also helps maintain the accuracy and reliability of final outputs. 📊 Tailor Metrics to Evaluate Human-AI Synergy. Metrics such as task completion rates, error counts, and code review times reveal the tangible impacts of LLMs. Studies found that LLM-assisted teams completed 25% more projects with 40% fewer errors compared to traditional methods. Pre- and post-test evaluations of users' learning showed a 30% improvement in conceptual understanding when LLMs were used effectively, highlighting the need for consistent performance benchmarking. 🚧 Mitigate Risks in LLM Use for Security. LLMs can inadvertently generate insecure code, with 20% of outputs in one study containing vulnerabilities like unchecked user inputs. However, when paired with automated code review tools, error rates dropped by 35%. To reduce risks, developers should combine LLMs with rigorous testing protocols and ensure their prompts explicitly address security considerations. 💡 Rethink Learning with LLMs. While LLMs improved learning outcomes in tasks requiring code comprehension by 32%, they sometimes hindered manual coding skill development, as seen in studies where post-LLM groups performed worse in syntax-based assessments. Educators can mitigate this by integrating LLMs into assignments that focus on problem-solving while requiring manual coding for foundational skills, ensuring balanced learning trajectories. Link to paper in comments.

I started coding again when the first ChatGPT launched in November 2022—curiosity turned into obsession. Since then, I’ve tried nearly every AI coding tool out there. Recently, I’ve become hooked on Cursor. It’s common to see two extremes: • New/junior devs often overestimate what AI can do. • Senior engineers usually distrust it entirely. Both are wrong! The sweet spot is using AI as an empowering partner, not a full dev replacement. You’re still in control—AI can help you go faster and think deeper, but only if you stay in the loop. After months of heavy use, here are some practical tips and a prompt sequence I rely on for deep code reviews and debugging in Cursor 👇 ⸻ 🔁 1. LLMs have no memory. Every chat is stateless. If you close the tab or start a new thread, you must reintroduce the code context—especially for complex systems. 📌 2. Think in steps, not monolith prompts. Work in multi-step prompts within the same chat session. Review each output before proceeding. ⚠️ 3. LLMs tend to do more than asked. Start by asking: “What are you going to do?” Then approve and ask: “Now do only that.” 💾 4. Commit before you go. Save your last working state. AI edits can be powerful—and sometimes destructive. 🧠 5. Use the right model for the job. • Lightweight stuff → Sonnet 4 • Deep analysis or complex refactoring → Opus 4 or O3 (these cost more, but they’re worth it) ⸻ 👨💻 Prompt Workflow Example: Reviewing a Complex App with Legacy Code Here’s a sequence I use inside a single Cursor chat session: ⸻ 🧩 Prompt 1 “As a senior software architect, review this app. Focus on [e.g. performance, architecture, state management, UI]. Provide an .md doc with findings, code diagrams, and flow logic.” ✅ Carefully review what’s generated. Correct or expand anything that feels off. Save it for reuse. ⸻ 🔍 Prompt 2 “Based on this understanding, identify the top 5 most critical issues in the app—explain their impact and urgency.” Ask for clarification or expansion if needed. ⸻ 💡 Prompt 3 “For issue #3, suggest 2–3 possible solutions (no code yet). For each, list pros/cons and outline what needs to change.” Choose the most viable solution. ⸻ 🛠️ Prompt 4 “Now implement the selected solution step by step. After each step, run ESLint (and if available, unit tests).” ⸻ 🔬 Pro tip: Ask Cursor to generate a full unit test suite before editing. Then validate every change via tests + linting. ⸻ This is how I use AI coding tools today: as a thought partner and execution aid, not a replacement. Would love to hear your workflows too. #CursorIDE #PromptEngineering l #DeveloperTips #CodingWithAI

Critique this (real) team's experiment. Good? Bad? Caveats? Gotchas? Contexts where it will not work? Read on: Overview The team has observed that devs often encounter friction during their work—tooling, debt, environment, etc. These issues (while manageable) tend to slow down progress and are often recurring. Historically, recording, prioritizing, and getting approval to address these areas of friction involves too much overhead, which 1) makes the team less productive, and 2) results in the issues remaining unresolved. For various reasons, team members don't currently feel empowered to address these issues as part of their normal work. Purpose Empower devs to address friction points as they encounter them, w/o needing to get permission, provided the issue can be resolved in 3d or less. Hypothesis: by immediately tackling these problems, the team will improve overall productivity and make work more enjoyable. Reinforce the practice of addressing friction as part of the developers' workflow, helping to build muscle memory and normalize "fix as you go." Key Guidelines 1. When a dev encounters friction, assess whether the issue is likely to recur and affect others. If they believe it can be resolved in 3d or less, they create a "friction workdown" ticket in Jira (use the right tags). No permission needed. 2. Put current work in "paused" status, mark new ticket as "in progress," and notify the team via #friction Slack channel with a link to the ticket. 3. If the dev finds that the issue will take longer than 3d to resolve, they stop, document what they’ve learned, and pause the ticket. This allows the team to revisit the issue later and consider more comprehensive solutions. This is OK! 4. After every 10 friction workdown tickets are completed, the team holds a review session to discuss the decisions made and the impact of the work. Promote transparency and alignment on the value of the issues addressed. 5. Expires after 3mos. If the team sees evidence of improved efficiency and productivity, they may choose to continue; otherwise, it will be discontinued (default to discontinue, to avoid Zombie Process). 6. IMPORTANT: The team will not be asked to cut corners elsewhere (or work harder) to make arbitrary deadlines due to this work. This is considered real work. Expected Outcomes Reduce overhead associated with addressing recurring friction points, empowering developers to act when issues are most salient (and they are motivated). Impact will be measured through existing DX survey, lead time, and cycle time metrics, etc. Signs of Concern (Monitor for these and dampen) 1. Consistently underestimating the time required to address friction issues, leading to frequent pauses and unfinished work. 2. Feedback indicating that the friction points being addressed are not significantly benefiting the team as a whole. Limitations Not intended to impact more complex, systemic issues or challenges that extend beyond the team's scope of influence.

Recently helped a client cut their AI development time by 40%. Here’s the exact process we followed to streamline their workflows. Step 1: Optimized model selection using a Pareto Frontier. We built a custom Pareto Frontier to balance accuracy and compute costs across multiple models. This allowed us to select models that were not only accurate but also computationally efficient, reducing training times by 25%. Step 2: Implemented data versioning with DVC. By introducing Data Version Control (DVC), we ensured consistent data pipelines and reproducibility. This eliminated data drift issues, enabling faster iteration and minimizing rollback times during model tuning. Step 3: Deployed a microservices architecture with Kubernetes. We containerized AI services and deployed them using Kubernetes, enabling auto-scaling and fault tolerance. This architecture allowed for parallel processing of tasks, significantly reducing the time spent on inference workloads. The result? A 40% reduction in development time, along with a 30% increase in overall model performance. Why does this matter? Because in AI, every second counts. Streamlining workflows isn’t just about speed—it’s about delivering superior results faster. If your AI projects are hitting bottlenecks, ask yourself: Are you leveraging the right tools and architectures to optimize both speed and performance?

Kanban: We Should Be "Done" With "In-Progress" One of the best ways to use Kanban is by visualizing meaningful work states on your board. Thoughtfully designed boards can transform how teams deliver value, spot inefficiencies, and improve collaboration. Unfortunately, many teams miss these opportunities by relying on vague, catch-all columns like “In-Progress.” Let’s talk about why “In-Progress” is practically useless, and how breaking it into clearer work states is a smarter strategy. Why “In-Progress” Fails The term “In-Progress” might seem harmless, but it’s so broad that it adds little value. “In-Progress” doesn’t explain what’s actually happening. Is a task being coded, reviewed, or tested? Without specifics, delays and inefficiencies stay hidden. A generic column hides bottlenecks. For example, slow code reviews go unnoticed when everything sits under “In-Progress.” Vague statuses make it harder to know who should act next. Confusion leads to reduced accountability, delays, and misaligned expectations. Without data showing where tasks spend the most time, teams can’t identify trends or resolve inefficiencies. The Case for Clarity Replacing “In-Progress” with specific work states turns a Kanban board into a powerful tool for managing flow and driving improvement. For example, a software development team might use: Backlog: Items awaiting prioritization. Ready for Development: Work ready to start. In Development: Developers are actively working. Ready for Code Review: Development is complete, awaiting review. In Code Review: Review process underway. Ready for Testing: Code is ready for QA. In Testing: QA is actively testing. Ready for Deployment: Testing is complete, awaiting release. Done: Work is completed. Each state reflects a clear step in the workflow (not necessarily a handoff). This improves visibility, accountability, and makes bottlenecks easier to spot. Your team’s context might call for different states, but the goal stays the same: clarity. Spotting Bottlenecks Granular states make delays visible. If tasks sit too long in “Ready for Code Review,” reviewers may be overloaded or not prioritizing reviews. A backlog in “Ready for Deployment” could mean release processes need work. Tasks stuck “In Testing” might point to unclear requirements or a stretched QA team. Tracking time-in-state reveals where delays occur, helping teams reallocate resources or refine processes. Collaboration Benefits Meaningful work states improve collaboration. When a task moves to “Ready for Testing,” testers know it’s their turn to act. This reduces idle time and makes transitions smoother. Be Done With “In-Progress” Create columns for key steps in your workflow. Don’t overcomplicate things. Aim for enough granularity to reveal bottlenecks without overwhelming your team with administrivia. Set clear entry and exit criteria for each column. Kanban isn’t just about making work visible; it’s about making the right work visible.

Agent-assisted coding transformed my workflow. Most folks aren’t getting the full value from coding agents—mainly because there’s not much knowledge sharing yet. Curious how to unlock more productivity with AI agents? Here’s what’s worked for me. After months of experimenting with coding agents, I’ve noticed that while many people use them, there’s little shared guidance on how to get the most out of them. I’ve picked up a few patterns that consistently boost my productivity and code quality. Iterating 2-3 times on a detailed plan with my AI assistant before writing any code has saved me countless hours of rework. Start with a detailed plan—work with your AI to outline implementation, testing, and documentation before coding. Iterate on this plan until it’s crystal clear. Ask your agent to write docs and tests first. This sets clear requirements and leads to better code. Create an "AGENTS.md" file in your repo. It’s the AI’s university—store all project-specific instructions there for consistent results. Control the agent’s pace. Ask it to walk you through changes step by step, so you’re never overwhelmed by a massive diff. Let agents use CLI tools directly, and encourage them to write temporary scripts to validate their own code. This saves time and reduces context switching. Build your own productivity tools—custom scripts, aliases, and hooks compound efficiency over time. If you’re exploring agent-assisted programming, I’d love to hear your experiences! Check out my full write-up for more actionable tips: https://lnkd.in/eSZStXUe What’s one pattern or tool that’s made your AI-assisted coding more productive? #ai #programming #productivity #softwaredevelopment #automation

𝐃𝐞𝐯 𝐭𝐞𝐚𝐦𝐬 𝐚𝐫𝐞𝐧’𝐭 𝐬𝐥𝐨𝐰 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐨𝐟 𝐜𝐨𝐝𝐞. 𝐓𝐡𝐞𝐲’𝐫𝐞 𝐬𝐥𝐨𝐰 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐭𝐡𝐞𝐢𝐫 𝐰𝐨𝐫𝐤𝐟𝐥𝐨𝐰 𝐤𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 𝐢𝐬𝐧’𝐭 𝐞𝐱𝐞𝐜𝐮𝐭𝐚𝐛𝐥𝐞. 𝐒𝐊𝐈𝐋𝐋.𝐦𝐝 𝐟𝐢𝐱𝐞𝐬 𝐭𝐡𝐚𝐭. Most teams think “AI coding speed” comes from better prompts. I disagree. Speed comes from turning your team’s unwritten rules into triggerable skills that load only when needed. Here’s the practical pattern I’m seeing: 1. Use progressive disclosure: YAML frontmatter loads first, the SKILL.md body loads only when relevant, and linked refs get pulled on demand. Token-efficient, but still deep. 2. Treat the description field like a router. It has to say WHAT the skill does and the exact phrases users will type. “Helps with projects” won’t fire. “Plan my sprint in Linear” will. 3. Assume brittle rules will break you. Folder naming must be kebab-case. SKILL.md must be exact and case-sensitive. No README inside the skill folder. Miss one detail and you’ll get silent failure. 4. Don’t put interpretation where you need certainty. Put validation logic in scripts, not language instructions. Deterministic beats “the model will probably do it.” 5. Prevent skill hijacking. Add negative triggers so skills don’t over-fire and derail unrelated work. 6. When workflows span tools, coordinate in phases: Figma export → Drive storage → Linear task creation → Slack notification. Validate before moving to the next phase. If you want one debug move that actually works: ask the model, “When would you use the [skill name] skill?” If it quotes your description back, you just found the gap. Save this if you’re building an internal AI workflow. Send it to the one person on your team who keeps saying “we just need better prompts.” And if you disagree and think prompts are the whole game—tell me why. #Claude #SoftwareEngineering #DevTools #AIEngineering #AgenticWorkflows

10 tips from Anthropic's Claude Code team. Boris Cherny (creator of Claude Code) shared the engineering team's habits. The mindset shift: Claude Code is not autocomplete. It's a massively parallel engineering partner. Here are the 10 tips: 𝟭. 𝗚𝗶𝘁 𝗪𝗼𝗿𝗸𝘁𝗿𝗲𝗲𝘀 → The single biggest productivity unlock. → Run 3-5 Claude sessions in parallel. → While one runs tests, another refactors. 𝟮. 𝗣𝗹𝗮𝗻 𝗠𝗼𝗱𝗲 (𝗦𝗵𝗶𝗳𝘁+𝗧𝗮𝗯 𝘅𝟮) → Spend 90% of your energy on the plan. → With a solid plan, Claude can one-shot it. → Stuck in error loop? Go back to Plan Mode. 𝟯. 𝗖𝗟𝗔𝗨𝗗𝗘.𝗺𝗱 𝗮𝘀 𝗠𝗲𝗺𝗼𝗿𝘆 → Every time you correct Claude, say: "Update CLAUDE.md so you don't make this mistake again." → It learns your conventions and anti-patterns. 𝟰. 𝗖𝘂𝘀𝘁𝗼𝗺 𝗦𝗹𝗮𝘀𝗵 𝗖𝗼𝗺𝗺𝗮𝗻𝗱𝘀 → Turn repetitive tasks into commands. → /techdebt, /context-dump, /commit → Store them in .claude/commands/ 𝟱. "𝗟𝗮𝘇𝘆" 𝗕𝘂𝗴 𝗙𝗶𝘅𝗶𝗻𝗴 → Don't explain the bug. Paste raw data. → Screenshots, Slack threads, Docker logs. → Just say: "fix" 𝟲. 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲 𝘁𝗵𝗲 𝗔𝗜 ("𝗚𝗿𝗶𝗹𝗹 𝗠𝗲") → "Grill me on these changes and don't let me PR until I pass your technical test." → Don't accept code without questioning it. 𝟳. 𝗩𝗼𝗶𝗰𝗲 > 𝗞𝗲𝘆𝗯𝗼𝗮𝗿𝗱 → Double-tap fn on Mac for dictation. → We speak 3x faster than we type. → Critical for agentic workflows. 𝟴. 𝗦𝘂𝗯𝗮𝗴𝗲𝗻𝘁𝘀 → Use "use subagents" for massive compute. → Offload sub-tasks to fresh context windows. → Ideal for tests and documentation. 𝟵. 𝗚𝗼𝗼𝗱𝗯𝘆𝗲 𝗦𝗤𝗟 → Connect Claude to your DB via CLI (bq, psql). → Boris: "Haven't written SQL in 6 months." → Describe the data, Claude fetches it. 𝟭𝟬. 𝗖𝗹𝗮𝘂𝗱𝗲 𝗮𝘀 𝗧𝘂𝘁𝗼𝗿 → Enable "Explanatory" styles in /config. → Ask for ASCII diagrams or interactive HTML. → Learn while you produce. The gap between standard and AI-enhanced professionals grows every day. Which tip will you implement first?