At first, I thought AI would mostly help me write code faster. That’s how it’s usually presented, as a way to speed up implementation or generate code automatically.

But after using it daily for a while, I realized that this is not where it actually brings the most value.

AI doesn’t really change how fast I type code. It changes how I approach problems, especially the parts of the job that are slow, repetitive, or mentally expensive.

The way I think about it today is simple: AI behaves like a very fast junior engineer.

It can generate ideas quickly, suggest implementations, and help explore possibilities. But it doesn’t truly understand the system, the business context, or the consequences of a decision.

Once I started treating it this way, it became much more useful — and much less dangerous.

The discourse around AI software development is stuck between two extremes: people shipping toy apps in a weekend, and people insisting these tools are useless in real codebases. My experience has been neither.

AI doesn’t replace software engineering judgment. It amplifies it best when you use a disciplined workflow built around context, planning, staged execution, and strong verification.

I’m a Staff Software Engineer with 23 years of experience, and this is the workflow I use to ship production software with AI in 2026. I will walk you through how I am leveraging AI tooling to deliver new features into production software products.

...

I’m a software engineer, and I honestly feel a bit disconnected from how negative a lot of the conversation around AI coding has become.

I’ve been using AI a lot in my day-to-day work, and I’ve also built multiple AI tools and workflows with it. In my experience, it has been useful, pretty stable, and overall a net positive. That does not mean it never makes mistakes. It does. But I really do not relate to the idea that it is completely useless or that it always creates more problems than it solves.

What I’ve noticed is that a lot of people seem to use it in a way that almost guarantees a bad result.

If you give it a vague prompt, let it make too many product and technical decisions on its own, and then trust the output without checking it properly, of course it will go sideways. At that point, you are basically handing over a messy problem to a system that still needs guidance.

What has worked well for me is being very explicit. I try to define the task clearly, give the right context, keep the scope small, ask it to think through and plan the approach before writing code, and then review the output or using a new agent to do the test.

To me, AI coding works best when you actually know what you are building and guide it there deliberately. A lot of the frustration I see seems to come from people asking for too much in one shot and giving the model too much autonomy too early.

So I’m genuinely curious. If AI coding has been bad for you, what exactly is failing? Is it code quality, architecture, debugging time, context loss, or something else?

If you’ve had a rough experience with it, I’d really like to hear why.

Whether we like it or not, AI is here to stay. Personally, I am tired of hearing about it and how people "vibe coded" something. That being said, that is pretty much what this post is about. Just to clarify, I am using AI to refer to Large Language Models also known as LLMs.

I was asked to have a meeting to talk to other developers about how I use AI tools to write code. I have over time found it to be a major time saver using AI tools by letting it focus on the coding and let me focus on making sure the product is what the users are looking for.

...

I use AI agents in every step of my development workflow.

Here's what that looks like:

When I first started using AI to code, I'd just open a chat and start prompting.

Vibe coding works for small scripts, demos, and bug fixes. But for real software it falls apart fast.

AI agents don't change how good software gets built. They change how fast.

Having said that - process scales with the task. A bug fix probably doesn't need a full spec or complex workflow.

The key is matching the level of process to the complexity of the work.

Here's the 5-step process I follow:

1. Spec (what, why, how)

AI can't replace good thinking. The best engineers think about design before implementation.

Start with a PRD. Define what's being built and why.

Then write a technical spec covering architecture, data models, and constraints.

A PRD is about requirements. A technical spec is about architecture choices.

2. Tasks

Break the spec into small, well-defined tasks you can hand off to agents.

I push tasks into Linear via MCP.

3. Build

Hand off tasks to agents and ensure they have all the context they need.

4. Review

First-pass AI code works but it's usually full of problems.

Always run a dedicated review pass to check quality, reduce complexity,
and make sure the output matches the spec.

Quality = iteration.

Build, review, fix, improve, simplify. Repeat until it's clean.

5. Ship

Tests, linting, CI gates. Automation catches regressions.

I try to avoid:

1/ Delegating design decisions to AI. The agent follows instructions.
You still have to make the right calls.

2/ Skipping the iteration loop. First-pass AI code always has bugs.

What's your workflow for coding with agents?

---

---

Enjoy this? ♻️ Repost it to your network and follow for more.

PS: I genuinely appreciate you taking the time to read this. I make videos to help people build amazing things with AI (no hype) but I'm a tiny account. If you got value from this, subscribing would mean the world: https://lnkd.in/eUZ3Y96V 🙏

🚀 I built this project using Claude Code but not casually.

I applied real workflow engineering principles behind it.

After going deep into how top teams use Claude internally, I realized most AI frustration is not about capability.

It’s about workflow.

So while building my upcoming project, I followed these principles:

1️⃣ Plan Mode First

Before writing a single line of code, I:
• Broke tasks into clear steps
• Wrote specs
• Reduced ambiguity
• Designed verification before implementation

No rushing into coding.

⸻

2️⃣ Subagent Strategy

For complex problems:
• Used multiple parallel explorations
• Offloaded research and structure analysis
• Kept main context clean and focused

Think of it like running a small AI engineering team instead of a single assistant.

⸻

3️⃣ Verification Before Done

Nothing was marked complete unless:
• Logs were checked
• Edge cases reviewed
• Behavior diffed between versions
• Production state verified

No “it works locally” mindset.

⸻

4️⃣ Autonomous Bug Fixing

Instead of micromanaging fixes:
• Pointed AI at logs
• Let it trace distributed flows
• Forced root cause analysis

Real debugging. Not patching.

⸻

5️⃣ Skill Reuse & System Thinking

Turn repeated tasks into reusable skills.
Reduce context switching.
Design process once, reuse forever.

⸻

6️⃣ Continuous Self-Improvement Loop

After every correction:
• Document the lesson
• Update rules
• Reduce future mistake rate

AI improves when your workflow improves

I’ve been using the Copilot CLI on a daily basis for coding, review, planning, design, and for debugging production systems. It’s awesome! Glad to see it reach GA. 👏

Most people use AI coding tools to write code. I'm using Claude Code to help build a personal operating system as a CEO.

I've hooked it up to many different tools that are important to us: Todoist, Slack, Linear, Notion, Salesforce, Gong, email, and so on. I've found it to be far more useful and sticky than the vanilla ChatGPT approach.

I now think of it as a mini coach+chief of staff. Some particularly valuable ways I'm using it right now or things I'm experimenting with:

🧠 Distillation of knowledge
I have a knowledge base that auto-syncs meeting transcripts from Granola, documents from Notion, indexes them by type (1:1s, customer calls, leadership), and makes them queryable across any conversation. It syncs to my Mac hourly. This means I can go see someone at their desk, Granola the conversation, and the context is now available for any future work I want to do with Claude.

🧘‍♂️ Removing distractions
A small but useful skill I've built is the slack-cleanup skill. It scans my 170+ channels, checks 6 months of activity, cross-references Salesforce and many other tools before deciding what to leave. Keeps me focused.

💭 Self-reflection and persistent memory
It knows our yearly initiatives, quarterly targets, and I write a weekly check-in before the week starts. So when I ask "what should I focus on today?", it doesn't just read my calendar. It checks whether my week is tracking against what actually matters. It's a gentle and useful accountability system.

🧐 Thinking quality
I'm experimenting with a /frame skill that takes messy context and distils it into a one-sentence problem, the binding constraint, and the eigenquestion — the question whose answer determines the answers to all the other questions. I use it to force forward progress on hard problems.

🔎 "Cheap", one-off analyses
For example, a competitive deep-dive into win rates, backed by specific customer quotes on gaps, with Gong snippets. That was a multi-day project compressed into minutes, backed by hard evidence, so I can sense check correctness.

Ultimately, I think the most benefit comes from work that would never have happened in the first place because it was far too expensive to do, vs. making me faster at what I already do. I recommend!

I use AI to write code every single day.

Copilot, Claude, ChatGPT - they're part of my workflow.
They make me faster. They handle boilerplate.
They suggest patterns I might not have considered.

But here's what they don't replace:
• 8+ years of understanding why systems fail
• The intuition to know when generated code looks correct but isn't
• The ability to design a system architecture from scratch
• The judgment to make tradeoffs between speed, cost, and quality
• The experience of debugging production issues across distributed systems
• The skill to look at requirements and know which ones will change

AI is the best tool I've ever had.
But a tool is only as good as the person using it.

A vibe coder with AI is someone with a power tool and no training.
A senior engineer with AI is a professional with a power tool.

Both will produce output.
Only one will produce something you can build a business on.

If you're hiring someone to build your MVP, don't ask if they use AI.
Ask what they were building before AI existed.

That answer tells you everything.

I wrote my first real code in 2015
10 years and hundreds of thousands of lines of code later, that flow state is all but gone. Coding agents are awesome and here to stay: I can ship at ~10x my earlier pace and handle more of the full stack while AI writes code faster and often better than me. My role has shifted to guiding the agents
providing context, correcting course, reviewing/verifying their work and focusing more on what problem to solve, what to build, how to iterate from feedback, and how to architect for scale (with AI doing much of the execution under my supervision).