Using AI tools without technical skills: lessons from daily work
Ten stories shipped in a day, three walls hit: what our non-engineer learned using AI tools daily.
When I first opened Claude Code, I assumed it was engineer territory. You need to know prompting. You need to know what a token is. You need to understand the model underneath. That was my assumption on day one, and it was completely wrong.
Some context for what day one means here. I work at GattyWorks. The engineering side of the studio audits vendor software and ships web builds. I am the non-engineer. I run the content and social side: the /news roundups, the Threads and Instagram packages, the approval reports. All of that goes through Claude Code, the same agent tool the engineers use on every build, and before this I had never used anything like it.
What I assumed
I assumed there was a barrier. Some body of knowledge I was missing that stood between me and using these things properly.
That sounds obvious now. It was not obvious then. I spent a genuinely embarrassing amount of time preparing to use a tool that required no preparation at all. My work in it is typing plain sentences: which story to package, what the banner should say, what a draft got wrong. The tool edits the files. I make the calls.
The 40/60 split
I watched a lot of videos before I started. They help, and I am not dismissing them. But here is my estimate after months of daily use: a good video gets you about 40 percent of the way. It shows the interface, the headline features, one or two workflows the creator likes.
The other 60 percent does not transfer through a screen, because the other 60 percent is your pipeline, not theirs. Nobody has a tutorial about our Instagram staging contract or the edge scan on our carousel slides, because those checks exist only in our repo. The only way to learn the part that matters was to open the tool on a Tuesday morning with a real story to publish and no tutorial to follow.
What changed in me, not in the tools
Looking back, the interesting thing was not the tools. It was what each stretch of use rearranged in my head.
Stage one. The quality of what comes back tracks the quality of what goes in. Vague ask, vague answer, and that includes banner copy. Nobody sat me down and explained this. I was quietly annoyed at bad responses for a few weeks until I noticed the pattern was me.
Stage two. I stopped breaking work into small safe pieces. The clearest example is August 18, when a ten story AI and tech roundup went out on our /news page as one batch, researched and drafted through Claude Code sessions with me steering. Once I trusted I could hand over something that size and get a coherent result back, the size of what I was willing to attempt changed. That was a confidence shift, not a technical one.
Stage three. I stopped asking questions and started delegating, and delegating means reviewing. All ten of those August 18 stories got Threads packages: a thread drafted per story in the desk pipeline, and a rendered banner staged on the site under `public/social-media/active/threads/`. None of it posts by itself. An approval report gets written, I read it, and the publish to Threads or Instagram happens only after a person confirms it by hand. You are not querying a search box anymore. You are handing work off, then checking it, the way you would with a person.
Stage four, ongoing. There are tools in our own stack I still do not have a firm view on. Not because I lack the technical depth to judge them, but because I have not put in the hours. That is the honest reason, and it is the same reason it always is.
None of those four things is technical knowledge. They are habits. Habits come from repetition, not from study.
The walls taught me the internals
Here is the part I underestimated. You have to make the work harder on purpose, because the tools only show you their machinery under strain. Three walls from my own laptop.
Line endings. On a fresh checkout on my Windows machine, the Instagram staging step failed its own contract check. The cause: Windows and the repo disagree about how a line of text ends, CRLF versus LF, an invisible difference I did not know existed. Now I know what a line ending is and why the files get normalized before staging.
A hairline black border. Instagram carousel slides kept rendering with a thin dark seam at the edge. Chasing that seam is why the pipeline now renders each slide isolated on a light canvas and then scans the edges of the finished image for stray dark pixels. I learned what a render pipeline is by watching ours grow a verification step over a one pixel line.
The day OneDrive ate the repo. On August 16 my sync client quietly hollowed out the hidden `.git` folders that hold the project's history. That is how I learned what `.git` actually is: by needing it and not having it. We rebuilt from the copies on GitHub, and push early stopped being advice I nodded at and became a rule I follow.
The machines get checked too
If there is one studio lesson under all of this, it is that AI output ships as a draft, never as a decision. Every post for the site goes through a reviewer agent twice, once as a pitch and once as a finished draft. The build fails if an article's images are missing. The carousel edges get scanned. The social packages wait for a signed approval report. After a deploy, a script polls the live site until the exact new commit is confirmed serving.
I know that reviewer gate is real because it caught me. The first draft of this essay was denied on August 31 for naming no real tool, no real project, no real date, and no real number. The version you are reading exists because the studio's review-everything rule got applied to my writing the same way it gets applied to AI output.
Where I am still stuck
The basics are catchable by anyone. Two weeks of real daily use and you will be productive. I am confident about that part.
Going deep is a different problem. Why a model behaves the way it does, what is happening inside, where the real limits sit. That is a steep climb and I am still on it. There is a wide gap between using something well and understanding it properly, and I am sitting in that gap. But the gap does not block the work. You do not need to understand an engine to drive well.
What I would tell you
If you are waiting to feel qualified, you are waiting for something that arrives after you start, not before.
- Pick one tool. Not three.
- Use it every day for two weeks on real work, not toy examples.
- Watch a video when you are stuck on something specific, not as preparation.
- Find one person who is a bit ahead of you and ask them when you get blocked.
That is it. The thing you are looking for does not live in a tutorial. It lives on the other side of two weeks of slightly frustrating use.
Start now. Go get the 60 percent.
Written by Anusha Gatty, GattyWorks. We build with these tools daily. If you want help getting your team to the same place, reach out at hello@gattyworks.com.