What Working With Claude Taught Me About Software Engineering

Photo by Daniel McCullough on Unsplash

Learning software engineering with AI taught me that engineering was never mostly about typing code — it's about the decisions around the code, and those decisions are exactly the ones a non-developer can learn to make. I came into building Coding Capybaras assuming the hard part was syntax, the part I couldn't do. A year of working with Claude showed me the syntax was the cheap part. The expensive parts were edge cases, small safe changes, naming, and knowing what could break. Those aren't programmer secrets. They're judgment, and watching a good AI assistant work made them visible to me in a way no tutorial ever did.

TL;DR

• The syntax was never the hard part. Working with an AI assistant made the real engineering — edge cases, structure, safety — visible to a non-developer.
• Software is mostly about what happens when things go wrong, not the happy path. That's where the work lives.
• Small, verifiable changes beat big rewrites. Google's 2024 DORA report found AI can hurt delivery stability, and small batches are the discipline that protects it.
• Naming and structure aren't cosmetic. They're how you and your AI both keep finding things six months later.
• Tests are a founder's safety net, not a developer luxury — they're how you change code you can't fully read and still sleep.

Software is mostly about the edges

The first thing that rewired my understanding: a working feature and a shippable feature are two very different amounts of work, and the gap between them is entirely edge cases.

When I'd ask Claude to build something, the "happy path" — the version where everything goes right — would come together fast. A signup form that works when you type a valid email and a good password. Then it, or I, would start asking the uncomfortable questions. What if the email's already registered? What if the password's too short? What if the network drops halfway? What if someone submits the form twice by double-clicking? Each of those is a branch the software has to handle, and a real feature is mostly those branches.

I used to think a developer's job was writing the happy path. It's not. The happy path is 20% of it. The other 80% is anticipating everything that can go wrong and deciding what should happen when it does. And that anticipation is a product skill as much as a technical one — I'd been doing a version of it for years in spreadsheets, worrying about the blank cell and the divide-by-zero, which is part of why the jump from Excel to SaaS founder was less of a leap than I feared.

Watching the assistant enumerate edge cases — and catching the ones it missed — is how I learned to see them myself. Now I ask "what are the failure modes here?" before I ask "does it work?" That single reordering made me meaningfully better at building software, and I still can't write the code by hand.

Small changes beat big ones

The second lesson cost me a weekend before it stuck. I asked for a large, sweeping change across several parts of the app at once. It sort of worked, then something unrelated broke, and I had no idea which part of the big change caused it, because everything moved at the same time. I couldn't isolate the problem because I'd given myself nothing to isolate.

Experienced engineers have a name for the fix: small batches. Change one thing, verify it, commit it, move on. When something breaks, the culprit is the one thing you just changed, not a haystack of twenty. It sounds obvious written down. It is not obvious when an AI assistant will happily rewrite half your app in a single response and make it look effortless.

This isn't just my hard-won opinion. The 2024 DORA report from Google's research team found that as AI adoption went up, software delivery stability actually went down — a reminder that raw generation speed without the old disciplines makes things worse, not better. Small batch sizes and solid testing are precisely the fundamentals the report says still protect you. The AI removed the typing bottleneck. It did not remove the need to move carefully.

Now I work in the smallest reasonable steps and commit constantly, so every change is a save point I can roll back to. It's the same instinct behind treating the assistant like a senior pair-programmer you steer one move at a time rather than a machine you hand the whole job.

What I thought engineering was vs. what it is

If I could hand my year-ago self one page, it would be this table. Almost every belief on the left was wrong, and each wrong belief cost me time.

| What I assumed | What it actually is | | --- | --- | | The hard part is writing code | The hard part is deciding what the code should do at every edge | | A feature that runs is done | A feature is done when it handles the ways it can fail | | Bigger changes make faster progress | Small, verified changes make faster progress | | Naming things is cosmetic | Naming is how you and your AI find things later | | Tests are a professional luxury | Tests are how a non-coder safely changes code | | The AI knows the right architecture | The AI executes an architecture; you own choosing it |

That last row took the longest to accept. The assistant is extraordinary at implementing a plan and mediocre at knowing which plan is right for your product six months from now. The architecture is still yours to own — a point I dug into more in how AI coding changed my relationship with shipping software.

Naming and structure are the actual work

I assumed naming was decoration — call the variable x or userEmail, who cares, the computer doesn't. The computer doesn't. You do, and so does your AI assistant on the next session.

Here's what clicked. When I gave things clear names and put them in sensible places, the assistant got dramatically better at helping me, because it could understand my code the same way I could. When I let names get sloppy and files pile up in the wrong folders, the assistant got confused right alongside me, and its suggestions got worse. Good structure is a gift you give your future self and your future AI session at the same time.

This is why Coding Capybaras is split into three clearly-named regions — platform, website, product — with strict rules about what goes where. It's not architectural vanity. It's so that when I open a session months later, both the assistant and I can find the thing we need without spelunking. The structure is what keeps the codebase legible to a non-developer, which is the only way I can operate it alone. And getting the structure of your data wrong early is one of the most expensive mistakes there is — I've watched it become a nightmare, which is the whole subject of the database schema mistakes that haunt founders.

Tests are how a non-coder sleeps

I ignored automated tests for months because they sounded like a professional-developer indulgence — extra code that doesn't ship a feature. Then I changed something small and broke something I couldn't see, in a part of the app I wasn't even looking at, and shipped the break to real users. That's when tests stopped being abstract.

A test is a small piece of code that checks another piece of code still does what it's supposed to. For someone who can't fully read the implementation, that's not a luxury — it's the safety net that makes change survivable. When I ask the assistant to modify something and the tests still pass, I have evidence the old behavior didn't silently break, even though I couldn't verify it line by line myself.

This matters more with AI in the loop, not less. Stack Overflow's 2025 survey found the top developer frustration was "AI solutions that are almost right, but not quite" — code that looks correct and isn't. A test catches "almost right" when your eyes can't. So now I ask for tests on anything important, and a failing test is one of the most useful things that can happen to me, because it caught a problem before a customer did.

The engineering was human all along

The meta-lesson under all of these: the parts of software engineering I couldn't do — the fluent typing, the syntax recall — turned out to be the parts that matter least now that AI does them well. Nadella has said a fifth to a third of Microsoft's own code is AI-generated, and that share keeps climbing. The typing was never the moat.

The parts that remain deeply human — anticipating failure, moving in small safe steps, naming and structuring for the future, deciding what's worth protecting with a test — are judgment. I could learn them without learning to write the code, because working alongside a capable assistant put them on display every single day. That's the strange gift of this moment: the AI didn't replace the engineering, it revealed it.

Frequently asked questions

Can a non-developer really learn software engineering with AI?

You can learn the judgment part — edge cases, safe changes, structure, testing — without learning to write code fluently. Working alongside an AI assistant makes those decisions visible, and they're the parts that matter most. The syntax you can increasingly delegate.

What surprised you most about how software actually works?

That the "happy path" where everything goes right is a small fraction of the work. Most of building a real feature is deciding what happens when things go wrong — duplicate submissions, dropped connections, bad input. That's product thinking, not just programming.

Why do small changes matter so much with AI coding?

Because an AI assistant can change a lot at once, and when something breaks you need to know which change caused it. Small, verified, committed steps give you that. The 2024 DORA report even found AI adoption can reduce delivery stability, and small batches are a core defense.

Do I need to write tests if the AI writes my code?

Especially then. Tests catch the "almost right, but not quite" output that AI is prone to and your untrained eye will miss. For a non-developer, a passing test suite is the evidence that a change didn't silently break something you couldn't verify yourself.

Does using AI mean I don't need to understand my own architecture?

No. The assistant is great at implementing an architecture and unreliable at choosing the right one for your product's future. Owning the high-level structure — where things live and why — is what keeps the codebase operable by you, alone, months later.

Where this leaves a non-technical founder

A year ago I thought software engineering was a locked room I didn't have the key to. What I actually found is that the lock was on the typing, and the typing is the part getting automated. The real craft — thinking in edges, changing carefully, naming clearly, protecting with tests — was always judgment I could build.

I write about this learning curve regularly on the Coding Capybaras blog — the boilerplate is free if you want to study a real production codebase — three regions, tests, and standing AI context — built and operated by a non-developer working with an AI assistant every day.