Skip to main content
← Leadership Dispatch · Dispatch #10 · Clinical AI & Governance · · 5 min read

Almost a Year Coding with AI: Coming Back Inside the System

For almost a decade, I didn’t really code. Not because I couldn’t—but because modern software moved faster than I could reasonably re-enter. AI changed that. This is a reflection on coming back inside the system—and what it means to build responsibly at the intersection of systems and people.

Kyle P. Atkins
Kyle P. Atkins, Ed.S., PMP, CVAHP, NRP, eFACHDM
RSS
Almost a Year Coding with AI: Coming Back Inside the System

How AI Enabled a Return to Building at the Intersection of Systems and People

For most of my career, I’ve been comfortable inside systems.

Not flashy systems. Not trend-driven ones. The kind built because someone needed to solve a real problem and couldn’t afford for the solution to be wrong. Databases. Business logic. Operational workflows. Systems where, if you understand the inputs, outputs, and constraints, you can make things behave predictably.

I came up in RPG IV and SQL. Green screens. Explicit structure. You load what you need, you run what you’ve loaded, and the system does exactly what you tell it to do. I learned by getting curious and by debugging—by breaking things, tracing why they broke, and fixing them. I didn’t always know the shortcuts or the “simplest” way to do something, but I built solid programs and enhancements because I understood what the system was supposed to do.

That foundation mattered.

Then modern software development arrived.

React. Hooks. State. Toolchains layered on top of toolchains. Files importing files importing files, sometimes just to render a button. I could understand the logic, but the ecosystem felt increasingly hostile to re-entry unless you committed fully—unless you made it your entire professional identity.

And for the next ten or eleven years, I mostly didn’t code.

Not really.

Standing Outside the Glass

During that time, I touched WordPress. I played with PHP boilerplate systems. I tried to hack ideas together at the edges, mostly out of curiosity. But I wasn’t inside software anymore. I was standing just outside it—close enough to see what was happening, far enough away to feel like it was changing faster than I could reasonably catch up.

What’s important is this: I didn’t stop thinking like a developer.

I spent years in IT roles. I worked as a developer and a DBA. I designed databases. I mapped workflows. I translated operational needs into technical requirements. I lived in systems—even if I wasn’t actively coding them.

But every time I looked back toward modern development, the stack had changed again. New frameworks. New conventions. New “right ways” to do things. The learning curve felt steep enough that unless you committed fully, you stayed on the outside.

I wanted back in.

But not enough to start over as if the last decade of experience didn’t matter.

AI changed that.

Not because it made software simpler—but because it made re-entry possible without erasing who I already was.

“AI didn’t make me a beginner again. It let me return as who I already was.”

What AI Actually Changed—and What It Didn’t

AI didn’t suddenly make me a better programmer in the traditional sense. I didn’t wake up fluent in React. I still need help—often.

What changed was my ability to move.

AI lowered the activation energy enough that I could stay focused on system design instead of getting trapped in syntax. I could build first, then learn by inspecting what worked and what didn’t.

Instead of spending weeks stalled at the edge of a framework, I could create something real and work backward to understand why it behaved the way it did.

“AI didn’t replace learning. In changed the order of learning”

That shift required letting go of a deeply ingrained belief: that if I wasn’t writing every line myself, I wasn’t really building.

That belief is everywhere in technical culture. Struggle equals legitimacy. Assistance equals weakness. But it also keeps a lot of capable people permanently on the sidelines.

Domain Knowledge Is the Real Constraint

When I came up, I lived inside software built by developers who could code—but didn’t truly understand the domain they were coding for.

That distinction matters more than most people want to admit.

Anyone can learn syntax. Anyone can make something compile. But without domain knowledge, you’re guessing. And a lot of technology—especially in healthcare, education, and public safety—is built on guesses that look fine in a demo and fail in the real world.

I’ve spent most of my career on the other side of that equation. I understand workflows. I understand operational constraints. I understand why systems exist, who they serve, and what happens when they fail at the wrong time.

That’s always been my edge.

So when the term “vibe coder” started circulating, I wasn’t sure what to do with it. Maybe I am one—maybe I’m not. I’ve written RPG. I’ve written a lot of SQL. I’ve worked in Java. I understand logic and debugging deeply. I just didn’t take the traditional computer science path, and I don’t pretend to have every modern framework nuance memorized.

What feels more accurate is this:

“I don’t build from syntax outward.I build from intent inward.”

Today, I operate as an AI-assisted systems architect and program manager. I bring the ideas. I bring the domain expertise. I bring the ethical boundaries. AI helps translate that into code.

Back to an Old Role—With Better Tools

In a lot of ways, AI didn’t give me a new role.

It gave me my first one back.

Right after high school, my job wasn’t to be the best developer in the room. Actually, I was a customer support rep who became a programmer out of need. As that evolved, I found a new purpose on the team. It was to sit between developers and people—to listen to what users needed, understand what systems could realistically do, and translate between the two.

That’s the work I’ve always been good at.

AI lets me do that work now and execute. I’m no longer limited to diagrams, requirements, or advice. I can build the thing—review it, refine it, and make sure it behaves the way it should.

That combination is powerful. Not because it replaces developers—but because it closes a gap that’s existed for a long time.

Ownership Without Illusions

Some tools are excellent at UI and UX—but they come with a tradeoff. They generate things I didn’t explicitly ask for. They make decisions on my behalf that I can’t always trace.

I recently built a customer project management tool using Lovable. It moved fast—and it built things I didn’t fully understand. That made me uneasy.

Cursor became my go-to not because it’s perfect, but because it keeps me in the loop. I review the code. I question changes. I may not recognize every syntax pattern instantly, but I know what I’m looking for.

“Ownership isn’t writing every line. It’s understanding what you ship.”

That distinction matters.

The Shift I Didn’t Expect: Confidence

The biggest change wasn’t technical.

It was emotional.

Refactoring stopped feeling dangerous. Touching unfamiliar code stopped triggering anxiety. When something breaks now, my first reaction isn’t panic—it’s curiosity.

What changed? Why did it fail? What’s the cleanest way to fix it?

That mindset is the difference between systems that stagnate and systems that evolve.

Building With People in Mind

One of the projects I’ve spent the most time on—Quill—was built with my wife in mind. She didn’t realize that at first. When I finally told her, she thought it was one of the sweetest things I’d ever done.

That moment mattered to me because it reminded me why I build at all.

“The best systems aren’t impressive. They’re helpful.”

AI didn’t create that intention. But it removed enough friction that I could follow it—without getting lost in tooling or gatekeeping.

The Real Takeaway

Here’s what I want people to hear:

You can absolutely build with AI.

But meaningful systems don’t come from prompts alone. They’re built at the intersection of programmatic understanding—what computers can do—and people-centered design—what humans actually need to be helped by a system.

“AI is powerful. Direction is Everything.”

AI didn’t make me less technical. It made my domain knowledge, ethical grounding, and systems thinking finally usable at scale.

Where I’ve Landed

After almost a year of building with AI, this is the belief I’m comfortable standing on:

AI isn’t a shortcut to expertise. It’s a compression layer for experience—if you engage with it intentionally.

The real skill now isn’t memorizing syntax. It’s knowing what to ask for, what to reject, and what you need to understand yourself.

Used well, AI doesn’t make you lazy.

It makes you capable - quietly, steadily, and with purpose.

Kyle P. Atkins

Written by Kyle P. Atkins, Ed.S., PMP, CVAHP, NRP, eFACHDM

Founder & Chief Architect of Veritas Technology Solutions , and author of The Healthcare Leader’s Guide to AI and SAFEHARBOR: A BLACKBOX Story .

Leadership Dispatch

Occasional essays on healthcare AI governance, clinical education, and executive leadership. Sent directly when a new article or resource is published—no weekly filler.

Enter a valid email address (e.g., [email protected]). Unsubscribe anytime.
Please enter a valid email address before subscribing.

Direct Correspondence

Contact Kyle P. Atkins

Speaking invitations, healthcare AI governance advisory, or general inquiries.

Direct email: [email protected]