Stop Waiting for Permission to Build with AI

A

Adil Sher

Author

Nov 13, 2026
4 min read
1 views
Stop Waiting for Permission to Build with AI

I spent three months last year convinced I couldn't use GPT APIs "properly" because I never studied machine learning. I'd open the OpenAI docs, see code examples, and immediately think: this isn't for me, I'm just a web developer. Then I actually tried it. I wrote eleven lines of JavaScript, passed a prompt to an API, and solved a problem that was eating two hours of my week. That moment, realizing I'd been gatekeeping myself, changed how I think about what "being a developer" actually means in 2024.

The weird part is how many developers I know are stuck in the same place. They hear "embeddings" or "fine-tuning" and assume there's some secret knowledge required. There isn't. What there is, is a fundamental misunderstanding about what our job has become.

The Real Shift Happened Quietly

Six months ago, a client asked me to build a feature that auto-categorized support tickets. My first instinct was to write rules. Complex if-else logic, pattern matching, maybe some regex if I was feeling fancy. It would've taken a week and been brittle as hell.

Instead, I spent an afternoon with Claude's API docs. I wrote a function that sends ticket descriptions to the model with clear instructions on what categories to return. Done. The client loved it. Cost me about 40 cents a month.

This is what nobody tells you about modern development: the hard part isn't the AI anymore. The hard part is knowing when to use it and how to talk to it. We've shifted from building the engine to driving it.

Three Things I've Actually Learned

Prompts are just instructions. When I stopped thinking of prompts as "magic incantations" and started thinking of them as requirements documents, everything clicked. If you were onboarding a junior developer and they kept returning garbage output, you wouldn't blame them, you'd write clearer specs. Same principle. I give models a role ("you are a sarcastic tech writer"), constraints ("max 280 characters"), and examples. The quality jumps dramatically.

Let the API do what it's good at. This sounds obvious, but I spent months writing validation logic when an LLM could do it in one line. Is this email spam? Does this product review mention shipping issues? Should this support ticket get escalated? These aren't compute problems, they're reasoning problems. Let the model handle them.

The corollary: don't outsource deterministic operations. Sorting, math, database queries, keep those in code where they're fast and predictable.

Structure your input like you'd structure a brief. Here's where amateurs and people actually shipping this stuff differ. I don't dump raw text at the API. I format everything clearly: explicit task descriptions, labeled sections, requested output format. When I ask for CSV output with specific columns, I get clean data I can pipe directly into my database. When I was lazy and just said "extract this," I got paragraphs I had to parse.

The Thing I'll Push Back On

The original article implies this is all cheap and cheerful. It's generally cheaper than hiring people, yes. But I've seen people build entire features on APIs and get surprised by bills when usage scales. I'm religious about tracking costs now. I set limits. I use cheaper models when they work. A $10 million startup built on a $0.10 per request API call is a cautionary tale waiting to happen.

Also, and maybe this is just paranoia, but I'm building on top of someone else's infrastructure that could change terms, pricing, or access tomorrow. I think about this more than I probably should. For core business logic, there's something nice about owning the code.

Here's What I Actually Do

async function categorizeTicket(ticketText) {
 const response = await openai.chat.completions.create({
 model: "gpt-4o-mini",
 messages: [
 {
 role: "system",
 content: `You categorize support tickets into exactly one category.
 Categories: bug, feature_request, billing, general.
 Respond with only the category name.`
 },
 {
 role: "user",
 content: ticketText
 }
 ],
 max_tokens: 10
 });
 
 return response.choices[0].message.content.trim();
}

Notice: clear instructions, tight constraints, expected output format. I've tested this against my fallback manual categorization and it's 94% accurate. Could be higher, I just haven't optimized the prompt further because it's good enough for production.

What's Your Actual Barrier?

I think a lot of us aren't held back by technical knowledge, we're held back by permission we've never actually needed. You don't need a degree. You need a credit card, some docs, and willingness to experiment for an afternoon.

My question: what's one feature you've been putting off because you thought it required AI expertise you didn't have? Try it this week. Seriously. Spend an hour. You'll probably surprise yourself.

Source: This post was inspired by "From Curious to Confident: How I Use AI APIs Without Being a Machine Learning Expert" by Dev.to. Read the original article

Written by Adil Sher

Full stack developer building high-traffic platforms, AI services, and custom web applications. Explore my portfolio, learn about my background, or get in touch.

Related Articles