I didn't come into automation through computer science. I came through design.
For years, my work was visual — graphic design, web design, building digital presence for businesses across very different industries: sportswear, leather goods, dental clinics, a US-based clothing brand I worked with for about two years. I was good at making things look right. But somewhere along the way, "looking right" stopped being enough for me. I wanted to build things that did something, not just things that looked good doing nothing.
That's what pulled me into AI automation.
Where it started
I didn't jump straight into building agents. I started with n8n — learning how to connect APIs, trigger workflows, and let a system handle work that used to eat up hours of manual effort. I went through n8n Academy's certification path properly, not just skimming docs, because I wanted to actually understand the platform, not just copy templates.
The first real proof that this was working: a workflow I built — an error-handling system connecting n8n, Notion, and Slack — got accepted into n8n's template library. It wasn't flashy. It solved a boring, real problem: when an automation fails, someone needs to know immediately, with enough context to fix it fast. That's the kind of "unglamorous but necessary" engineering I've come to actually enjoy.
What I'm building now
Right now, most of my focus is on an AI-powered operating system for dental clinics — automating scheduling, patient communication, and front-office workflows end to end. It's still early. Parts of it work well, parts of it are still rough, and I'm learning more from the rough parts than the polished ones.
Building something end-to-end — not just a single workflow, but a full system that has to handle real edge cases, real patients, real failure modes — has taught me more about production thinking than any course could. Things like:
- What happens when an API call fails mid-workflow
- Why "it works on the happy path" isn't the same as "it works"
- Why human-in-the-loop steps matter more than fully autonomous ones, especially in something as sensitive as healthcare operations
What the design background actually gives me
I used to think coming from design was a disadvantage in this field — like I was starting from behind people with formal CS backgrounds. I don't think that anymore.
Design taught me to care about how something is communicated, not just whether it technically works. That shows up in how I document my projects now — architecture diagrams, clear explanations of tradeoffs, honest notes about what's still unfinished. A lot of automation work I see online is a black box: a JSON export with no explanation of why it was built that way. I'd rather show my thinking, not just my output.
What's next
I'm continuing to build in public — publishing real projects (not just tutorials) on GitHub, documenting what breaks and what I learn from it, and pushing further into agent-based systems beyond simple workflow automation.
If you're working on AI agents, automation, or workflow systems — or if you came into this field from a non-traditional background yourself — I'd genuinely like to hear how that's gone for you.
I write about AI automation, n8n, and building AI-powered systems. Find my work on GitHub and connect with me on LinkedIn.
Top comments (0)