My Journey With AI: How It Changed My Freelance Career
Seven years of full-stack freelancing taught me that AI doesn't replace engineering skill — it amplifies it. A first-person look at how AI moved from proposal helper to real coding partner, the trust curve, the identity adjustment, the day it deleted a remote folder, and the system that makes AI actually work.

*Originally published on LinkedIn — November 8, 2025*
I've spent 7+ years freelancing as a full-stack and DevOps engineer across hundreds of projects.
AI first entered my workflow through proposals, then slowly became a real coding and DevOps partner.
It wasn't an instant transition — trust, structure, and guardrails had to be built over time.
AI didn't replace my skills; it freed me from burnout, brought back momentum, and changed how I work and who I am as a developer.
Today, I use AI as both a coding teammate and a co-architect, and I help clients adopt it responsibly and effectively.
---
When I look back at the last seven years of freelancing, I didn't expect AI to reshape my work and identity the way it did. I started as a typical "figure-it-out" full-stack engineer on Upwork — jumping into all kinds of tech stacks, solving unique problems for clients around the world, and carrying the mental load of being the only engineer many founders relied on.
My early freelance years were built on learning fast, adapting constantly, and doing everything myself. If a client needed React one week and WordPress the next, I adjusted. If their AWS bill skyrocketed or an old PHP system broke, I dove in. It was exciting, unpredictable, and mentally heavy all at once.
AI didn't enter my journey as a revolution. It entered quietly, almost as a helper I didn't take seriously. What I didn't realize at the time was that it would eventually change how I work, how I think, and how I see myself as a developer.
Freelancing Before AI: The "Figure It Out" Era
For most of my freelance career, my reputation was built on being the person who could drop into any system and make things work. I've handled projects in:
- React, Next.js, React Native
- Node.js, Python, PHP/Laravel, WordPress, Craft CMS
- AWS, DigitalOcean, Cloud Functions, Docker, CI/CD
Some founders came to me with a well-defined architecture. Many came with half-finished prototypes in Replit or Lovable, or apps stitched together with tutorials and hope. Others came with legacy codebases nobody wanted to maintain.
I loved the variety, but it came with a cost.
There were periods where I juggled five different codebases, five different stacks, five different sets of expectations — and only one me to deliver. It wasn't unusual to finish a deployment at 2 AM, nap for a few hours, then wake up to a new Slack thread from another client with "urgent" in the message.
Freelancers don't talk about this enough: the pressure to know everything, fix everything, and never drop a ball. It's a constant, invisible mental load.
When AI first appeared, I didn't see it as an answer to any of this. I saw it as a novelty.
The First Practical Use: Upwork Proposals
My first real use of AI wasn't for coding — it was for proposals.
If you've freelanced, you know how much unpaid time goes into applying for projects. Before AI, I had templates I customized. They worked fine, but they felt repetitive.
When ChatGPT first became available, I tried feeding it my background and a job post. It created a proposal that sounded sharper and more tailored than what I usually wrote.
At first, I saw it as a shortcut.
Over time, something interesting happened: clients responded more. They commented on how "aligned" my proposals felt with their needs. I still edited them, refined the voice, and removed any AI-sounding phrases, but the efficiency was undeniable.
GPT-5 took that to another level — more context-aware, more personalized, and more human. A proposal that might've taken me 20 minutes could now take 5.
Some clients even said, "This proposal really stood out." A few times, I told them I used AI. Most didn't mind — they cared that I understood their goals.
One lesson I learned early:
> A proposal isn't a writing contest. It's a demonstration that you understand the problem and care about solving it.
AI helped me do that without burning hours I couldn't bill.
My First "AI Surprise" Moment (Story #1)
There was a day when I gave the AI a rather complex request:
I asked it to explain an unfamiliar codebase, map the architecture, and show where certain logic lived.
I expected a vague summary.
Instead, it broke the system down into components, identified patterns, pointed out likely pain points, and highlighted areas that would cause scaling issues later if not addressed.
I sat there staring at the result, thinking:
> "I didn't expect it to see that."
It wasn't perfect, but it wasn't beginner-level either. It felt like interacting with a junior engineer who had read the entire codebase in seconds and produced a structured report.
That was the first time I realized AI wasn't just a "faster StackOverflow." There was potential for deeper reasoning and support — if I learned how to guide it.
Using AI for Code: The Trust Curve
My early attempts at coding with AI were cautious. ChatGPT could write small snippets, but it hallucinated plenty. It produced functions for Craft CMS that never existed and made up WordPress hooks. You couldn't trust it blindly.
Then Claude introduced repo-aware workflows, and that changed the game.
Suddenly I could:
- Upload code
- Provide context
- Ask for specific improvements
It documented the pipeline, identified redundancies, and helped me rewrite it cleanly.
When the deployment finally worked smoothly, I felt something I hadn't felt in a while: relief mixed with genuine joy. It wasn't about speed — it was that I didn't have to carry the mental burden alone.
That moment felt meaningful. AI didn't replace me — it supported me in a way that made the work enjoyable again.
The Identity Adjustment (Story #3)
I'll be honest: there was a phase where I questioned what it meant to be a "good developer" now.
For years, my value came from knowing a lot across many stacks and being able to solve almost anything manually. It was part of my identity. Letting an AI help felt… uncomfortable. Almost like I was "cheating" on the craft I spent years building.
I had to work through that. I realized:
- My value wasn't in typing code.
- My value was in thinking, solving, architecting, and delivering outcomes.
- AI didn't remove the need for my judgment — it increased the impact of it.
That mindset shift freed me to use AI as a partner instead of a threat.
A Client Who Didn't Believe in AI (Story #4)
One client specifically told me, "No AI on this project."
They'd hired a developer before who used AI poorly. The result was bloated, inconsistent code that the client had to pay to clean up. They were burned.
I didn't argue. I respected their boundary.
But as I worked on the project, I noticed sections that could be improved significantly. After building trust through conventional work, I asked permission to show how AI could help under my guidance. We tried it together — but with rules:
- Keep code consistent with existing patterns.
- No unnecessary file creation.
- Run tests before and after each change.
When they saw the improvement and code clarity, their skepticism eased. They eventually said, "I get it now — AI isn't the problem. Bad use of AI is."
That experience taught me:
> AI adoption is more about mindset and process than tools.
The System That Made AI Actually Work
Once I understood how to use AI effectively, I created a simple system that changed everything. I treated AI the way I'd onboard a junior engineer.
Before letting AI touch code, I now prepare the repo with:
/README.md— clear instructions and purpose/CLAUDE.md— rules for AI: patterns, style, file boundaries/docs/— architecture notes, workflow explanation/tests/— meaningful unit tests to catch regressions
This structure gives AI context and guardrails. It prevents unnecessary rewrites, hallucinated APIs, and messy architecture.
How I Assign AI "Roles"
- Coding Agent
- DevOps Agent
- QA Agent
One agent per responsibility works better than one agent doing everything.
The Dark Side: Yes, AI Can Break Things
Let's normalize the truth: AI can cause damage if you're not careful.
There was a time I told the AI, "I backed up the files, you can delete the folder now," intending to delete a local copy. It deleted the folder on the remote server. Thankfully, I recovered it.
That experience reminded me:
- Be painfully specific with destructive commands.
- Label local vs remote environments.
- Always have snapshots or backups before changes.
Automation accelerates results — but it also accelerates mistakes.
A Glimpse into the Future: AI as a Teammate
Today, I regularly use 2–3 AI agents per project:
- One for DevOps
- One for code
- One for QA and testing
I rotate between projects while AI "thinks" or runs tasks. My role has become more strategic — planning, reviewing, guiding, and assembling the pieces.
AI hasn't replaced my engineering skills. It amplified them.
It took away the heavy parts of freelancing — the isolation, the never-ending cognitive load, the mental fatigue of being the only one responsible.
Now, I build with support.
And that changed everything.
What I'd Do Differently if Starting AI Today
- Create an AI-ready repo from day one.
- Separate agent responsibilities early.
- Set usage limits to avoid surprise bills.
- Talk to clients about the why before the how.
- Start small, ship early, iterate often.
AI isn't a magic button. It's a multiplier — of clarity, process, and discipline. If those aren't there, it multiplies chaos. If they are, it multiplies output and joy.
---
*If you're exploring how to integrate AI into your company/project, I'm available for consulting, hands-on development and fractional AI engineering support. I help clients deploy projects and products and help maintain or enhance existing systems. Learn more at helpwithweb.com.*
*— Dino Bartolome*
Need Help With Your Website?
I fix these problems every day. Send me a message and I'll take a look.
Get Help Now