Building with Claude Code: A Real Workflow from a Non-Engineer Perspective

I'm not a traditional software engineer. I've picked up Python and JavaScript over the years, enough to be dangerous, enough to read documentation and understand what's happening. But I'm not writing production code from scratch.

Last month, I built a data pipeline using Claude Code that processes customer feedback, tags it with sentiment analysis, and pushes clean data to our analytics dashboard. The whole thing took about six hours across two days. A year ago, this would have taken me weeks, assuming I could even finish it.

Here's what that workflow actually looked like, including the parts that didn't work.

Table of Contents

1. The First Conversation: Setting Context
2. Where the Agent Saved the Most Time
3. The Review Loop Nobody Talks About
4. When Things Broke (And Why)
5. What You Actually Need to Know
6. The Verification Problem
7. What This Changes

The First Conversation: Setting Context

The biggest mistake I made on my first project was jumping straight into implementation. I described what I wanted, Claude started writing code, and thirty minutes later I had files I couldn't debug.

Now I start differently. I run what people call a "prime command," basically a setup conversation where I explain the project architecture before any code gets written.

For the feedback pipeline, that looked like:

• What data sources we're pulling from (CSV exports from our support tool)
• Where the output needs to go (PostgreSQL database)
• What the data structure should look like
• Performance constraints (processing 5,000 rows in under two minutes)
• My technical comfort level (I can read Python, debug basic errors, understand REST APIs)

That last point matters. Claude adjusted its explanations and code comments based on knowing I wasn't a senior engineer. It included more inline documentation, broke complex functions into smaller pieces, and explained why certain patterns were used.

Analogy: Think of it like working with a contractor who adapts their communication style. A good contractor doesn't use the same technical jargon with a homeowner as they would with another contractor, but they also don't pretend the plumbing is magic.

Where the Agent Saved the Most Time

Three areas made the time investment worth it:

Boilerplate elimination. Setting up database connections, error handling, logging frameworks. This stuff is necessary but tedious. Claude generated it in seconds with proper structure. I reviewed it, understood what each piece did, but didn't have to write it.

API integration. Connecting to the sentiment analysis API required handling authentication, rate limiting, retry logic, and response parsing. Claude wrote all of it, including edge cases I wouldn't have thought about (what happens when the API returns malformed JSON?).

Data transformation logic. The messiest part. Our CSV exports had inconsistent date formats, optional fields that sometimes appeared as empty strings and sometimes as null, and text fields with encoding issues. Claude built a cleaning pipeline with validation steps that caught these problems before they hit the database.

Here's roughly how time broke down:

Total saved: about 5 hours on a project that took 6 hours with the tool versus roughly 11 hours without it.

The Review Loop Nobody Talks About

This is the part that surprised me. Using an agentic coding tool doesn't mean you stop reviewing code. It means your review focus changes.

I'm not catching syntax errors or typos. I'm checking:

• Does this implementation match what I actually need?
• Are there security issues I can spot? (Hardcoded credentials, SQL injection risks)
• Will this break when real data runs through it?
• Can I understand this code well enough to modify it later?

The workflow became iterative. Claude would generate an implementation, I'd review it, spot something that wouldn't work with our actual data structure, and we'd refine it. This happened three or four times per major component.

For example, the first version of the sentiment analysis integration processed rows one at a time. Fine for testing, terrible for 5,000 rows. I caught this during review, described the batch processing approach I wanted, and Claude refactored it to handle batches of 50 with parallel requests.

I needed enough technical understanding to spot that problem. Not enough to write the solution from scratch, but enough to know it existed.

When Things Broke (And Why)

About four hours in, the pipeline started throwing database connection errors. Intermittent, hard to reproduce, and the error messages were vague.

This is where my workflow hit limits. I could read the code, understand what it was trying to do, but couldn't figure out why the connection pool was occasionally exhausting itself.

I did two things:

1. Described the error pattern to Claude with full stack traces
2. Asked it to add more detailed logging around the database operations

The logging revealed the issue: I wasn't properly closing database cursors in the error handling paths. Claude had implemented the happy path correctly, but the exception handling was leaking connections.

Claude fixed it in about two minutes once I provided the logging output. But I needed to know that adding logging was the right debugging step. I needed to understand connection pools exist and can be exhausted.

The pattern I've found: Claude handles implementation brilliantly once you can describe the problem clearly. But identifying what the problem is still requires some technical intuition.

Agentic Coding Workflow: Iteration Required

What You Actually Need to Know

After building three projects this way, here's my honest assessment of the baseline knowledge that makes this workflow effective:

You need to understand:

• How to read code in at least one language well enough to follow logic
• Basic architecture concepts (what APIs are, how databases connect to applications, what environment variables do)
• How to describe problems clearly, including providing error messages and context
• When something looks wrong, even if you can't articulate exactly why
• How to test components before integrating them

You don't need to:

• Write syntactically correct code from memory
• Know every library or framework
• Understand advanced algorithms or data structures
• Be able to build everything from scratch

The gap between "I can read code" and "I can write production code" is where these tools provide the most value. If you're at zero technical knowledge, you'll struggle to review implementations or debug issues. If you're already a senior engineer, the time savings are there but less dramatic.

The Verification Problem

Here's something I got wrong initially: trusting the first implementation too much.

Claude generates code that looks professional. Clean formatting, good variable names, proper structure. But that doesn't mean it's correct for your specific use case.

I now have a verification checklist:

• Run the code with realistic test data, not just happy path examples
• Check edge cases: empty inputs, malformed data, API failures
• Verify the output format matches what downstream systems expect
• Test error handling by deliberately triggering failures
• Confirm security basics: no exposed credentials, proper input validation

The sentiment analysis integration looked perfect in testing until I ran it against real customer feedback with emoji, HTML tags, and special characters. It broke in three different ways. Each fix took 10 minutes once I identified the issue, but I had to run it against messy real data to find them.

What This Changes

I can now build tools I need without waiting for engineering resources. Our feedback pipeline runs every morning, saves our analyst about two hours of manual work per day, and I can modify it when requirements change.

But I'm not building complex applications. I'm building internal tools, data pipelines, automation scripts. Things where the requirements are clear, the scope is contained, and the consequences of bugs are manageable.

The workflow requires active participation. I'm not typing commands into a magic box. I'm collaborating with a tool that handles implementation details while I focus on requirements, architecture decisions, and verification.

It's closer to working with a junior engineer who's extremely fast at writing code but needs clear direction and thorough review. That's powerful for operators and founders who need to build things quickly. But it's not a replacement for understanding what you're building.

The projects I've completed work. They run in production. They save time. And I understand them well enough to maintain and extend them. That's the real test.