How to build practical AI skills for today's tech job market

The tech job market feels very different today than it did a few years ago. Not long ago, the career advice for anyone trying to enter technology sounded fairly simple: learn to code, build a few projects, put them on GitHub, polish your LinkedIn profile, and start applying. It was never quite that easy, but the path felt clearer.

Today, a lot of people are doing everything they were told to do and still struggling. They learn Python and SQL, finish courses, build projects, send applications — and then, silence. Entry-level roles receive huge numbers of applications, recruiters seem quieter, companies are slower to hire, and even experienced engineers are more careful about changing jobs because the market feels less predictable.

I don’t think it helps anyone to pretend otherwise: the market is difficult. But I also think there’s another side to the story. While the general tech market has become tougher, companies are still trying to figure out how to use AI in real products and real workflows. They’re experimenting with LLMs, internal assistants, retrieval systems, AI agents, automation, document processing, evaluation, and all kinds of AI-powered features — and running into the same problem again and again: using ChatGPT is easy; building something useful and reliable with AI is not.

That gap is where I think a real opportunity still exists. Not a shortcut, not a promise that anyone can become an AI engineer in 30 days, not another “learn these five tools and get rich” story — a real opportunity for people willing to learn how AI systems are actually built.

Knowing about AI is not the same as building with AI

There’s no shortage of people talking about AI. Every week brings a new model, a new benchmark, a new agent framework, a new coding tool, and usually a few hundred predictions about which jobs are about to disappear. Keeping up with the field can be useful, but following AI news is not the same as having practical AI skills.

Using ChatGPT every day doesn’t automatically make someone an AI engineer. Watching videos about RAG doesn’t mean you can build a retrieval system. Reading about agents doesn’t mean you know how to stop one from getting stuck in a loop or calling the wrong tool. This is where I think many learners get distracted: they know the vocabulary, but they haven’t yet built enough.

A company hiring for practical AI work isn’t just asking whether you know what RAG means. The better questions are:

• Can you build one?
• Can you connect an LLM to private data?
• Can you evaluate whether the retrieved context is actually relevant?
• Can you make the model return structured output that another system can use?
• Can you handle API errors, and manage cost?
• Can you log failures, expose the system through an API, and deploy it?
• Can you tell whether a new prompt improved the system, or quietly made it worse?

These aren’t glamorous questions. They’re engineering questions — and that’s exactly why they matter.

Most companies are not trying to build the next GPT

When people hear “AI career,” they sometimes imagine teams training giant models on thousands of GPUs. That work exists, but most companies aren’t trying to build the next frontier model. A retailer isn’t training a competitor to GPT — and neither is a logistics company, a bank, a hospital, an insurance company, or a manufacturer. Their problems are usually much more practical: an assistant that answers employee questions using internal policies, a system that reads contracts and extracts important clauses, a classifier for incoming support requests, a summarizer for customer feedback, an assistant that searches technical documentation before answering, a system that writes SQL, runs only safe queries, and explains the result, or a workflow that automates most of a task but keeps a human approval step before anything important happens.

None of these projects requires training a foundation model. They do, however, require people who understand how to use existing models properly — which means working with APIs, data pipelines, retrieval, databases, application development, testing, and deployment. And more than anything, it means judgment.

That mix is why I find modern AI engineering so interesting. It sits somewhere between software engineering, data engineering, machine learning, and product thinking. For many people already working in tech, that’s good news: you may not need to throw away everything you know and start from zero. You may just need to extend what you already know.

Your existing technical skills still matter

Technology has a strange habit of declaring itself dead every few years. SQL is dead. Data science is dead. Backend engineering is dead. Programming is dead. Cloud is dead. And yet companies keep paying people to write SQL, build APIs, fix pipelines, manage infrastructure, deploy software, and debug production systems.

AI is changing technical work — there’s no point denying that. But I don’t think the lesson is that all your old skills are useless. The better lesson is that their context is changing.

A Python developer can build LLM applications, evaluation tools, retrieval pipelines, and agents. A data engineer can build the pipelines and data systems that make AI applications useful. A backend engineer already understands many of the things AI demos often ignore: authentication, APIs, failure handling, testing, logging, queues, latency, and deployment. A data scientist or machine learning engineer may already be comfortable with datasets, experiments, evaluation, metrics, and model behavior. A SQL developer can help build safe systems that connect LLMs with structured data.

The foundation still matters. The mistake isn’t having older skills — the mistake is stopping there.

The biggest career advantage may be proof

In a crowded job market, saying “I know AI” doesn’t mean very much — it’s too easy to write. The same is true of phrases like “AI enthusiast,” “passionate about machine learning,” “experienced with RAG,” “interested in AI agents,” or “data-driven problem solver.” These phrases are everywhere, and they don’t give an employer much to work with.

Now compare them with something more specific: “I built a RAG system over technical documentation, created a small evaluation dataset, tested retrieval quality, exposed the application through FastAPI, added citations, and documented the failure cases.” That sentence is stronger because there’s something behind it. A hiring manager can inspect the repository. An interviewer can ask questions about the architecture. A recruiter can understand what skills were involved. The project becomes evidence.

This is something I think learners often underestimate: a project doesn’t need to be huge to be useful. It needs to be specific enough that another person can understand what you built and why. Even better, it should give you something real to talk about — why you chose that embedding model, how you split the documents, whether larger chunks worked better than smaller ones, how you tested retrieval, what happened when the model returned invalid JSON, how you managed costs, what your agent did when a tool failed, how you decided whether a new prompt was actually better.

Those questions are where the real learning lives, and you can only answer them properly once you’ve built something yourself.

Courses are useful. Endless course collecting is not.

I teach courses, so I obviously believe good training has value. A good course can save you a lot of time — it puts concepts in the right order, helps you avoid bad habits, and gives you a clear path through a difficult subject. But there’s a point where learning has to become building.

I see people who finish one course and immediately start another, then another, then another. Their browser is full of bookmarks, their learning platforms are full of unfinished courses, their LinkedIn profiles are full of certificates — but their GitHub profiles don’t show the same level of activity.

At some point, you have to close the tutorial and build something slightly uncomfortable: something where the instructions aren’t complete, the package version is different, the data is messy, the API fails, your agent calls the same tool five times, or the output looks great on one test question and completely falls apart on the next ten. That frustration isn’t a sign that the learning failed — that is the learning. Tutorials often remove the messy parts. Projects bring them back.

You do not need ten AI projects

One of the biggest mistakes I see in portfolio building is the belief that more projects always means a better portfolio. I don’t think that’s true — I’d rather see three thoughtful projects than fifteen copied demos. A good portfolio can grow in layers.

Start with a basic LLM application. Call a model through an API, handle messages properly, use environment variables for configuration, ask for structured output, validate the response, handle errors, and track token usage. That sounds basic because it is basic — but basic skills done properly are valuable.

Then build a RAG project. Choose a collection of documents, parse them, split them into chunks, generate embeddings, and store them. Retrieve relevant sections, send them to the model, ask questions, and add citations. Then do the part many tutorials skip: test it properly. Create 30 or 50 questions, write down the expected answers, check whether retrieval found useful context, check whether the final answer was actually supported by that context, and study the failures. Now you’re doing more than building a chatbot — you’re learning how the system behaves.

After that, build a small agent. Don’t start with a ten-agent autonomous company — give one model access to one or two useful tools. Maybe it can query a database, search a document store, use a calculator, or call an external API. Then try to break it: what happens when the tool returns nothing, when the API fails, when the agent repeats an action, when the user asks for something outside the system’s scope, or when a tool returns malformed data? These questions are what make the project interesting.

Finally, build something around evaluation. I think this is one of the most useful areas for serious AI learners. Many people can build a demo that looks impressive for five minutes; far fewer can tell you whether it works consistently. Can you create a golden dataset? Compare two prompts? Test structured outputs? Evaluate retrieval separately from answer quality? Track failure categories, or run regression tests before changing a prompt?

A demo asks, “Can this work?” Evaluation asks, “How often does this work, when does it fail, and can we trust it?” The second question matters much more in production.

One project can become an entire portfolio story

I think learners sometimes underestimate how far one good project can go. Imagine you build a document Q&A assistant. The first version simply lets users upload documents and ask questions. Then you improve the chunking, add metadata filters, add citations, build a small evaluation dataset, track retrieval metrics, wrap it in a FastAPI backend, containerize it with Docker, add logging, deploy it, write a blog post about the failure cases, and record a short demo video.

That’s still one project. But now it gives you a GitHub repository, a technical blog post, a portfolio entry, a LinkedIn post, an interview story, and possibly a live application. More importantly, you understand it deeply — you’ve watched it fail, changed it, made decisions, and can explain those decisions. That depth is far more useful than copying five unrelated tutorials.

Visibility matters, even if self-promotion feels uncomfortable

A lot of technical people dislike self-promotion, and I understand that. Online career content can be exhausting — someone finishes a two-hour tutorial and writes a post that sounds as if they just solved artificial general intelligence. Nobody wants to become that person.

But the alternative shouldn’t be complete invisibility. You can share your work without exaggerating it. You can write: “I tested three chunking strategies for a small RAG project. The most complicated option wasn’t the best. Here’s what I learned.” That’s useful. Or: “My agent kept calling the same tool. I added clearer tool descriptions, a step limit, and stopping rules. Here’s what changed.” Good. Or: “I changed one prompt and seven old test cases failed. This is why I now run regression tests before updating prompts.” That shows how you think.

You don’t have to pretend to be an expert — you just have to share something real. Your public work creates evidence over time. A recruiter may find a post. A hiring manager may inspect a repository. A founder may watch your demo. A future colleague may remember one of your explanations. Most of these things will probably lead nowhere. A few may not. The difficult thing about opportunities is that you rarely know in advance which small piece of work will create one.

Use keywords, but connect them to something real

There’s nothing wrong with using technical keywords in your LinkedIn profile, resume, or portfolio — recruiters search by keywords, and that’s simply how hiring works. Terms like LLM APIs, prompt engineering, RAG, embeddings, vector databases, AI agents, LangChain, LangGraph, FastAPI, LLM evaluation, observability, Docker, SQL, and cloud deployment can all help describe your skills.

But keywords alone aren’t enough. If you say RAG, show the project. If you say AI agents, show the workflow. If you say evaluation, show the test set, metrics, or comparison. If you say FastAPI, show the API. If you say deployment, show how you deployed it. Keywords may help people find you. Proof helps them trust you. You need both.

Learn to understand failure, not just success

The first stage of the generative AI boom was mostly about amazement — people asked a chatbot a question and were shocked by the answer. Then we connected models to documents, then to tools, then to databases, then to business workflows. Now the questions are getting less exciting and more useful: What happens when the model is wrong? What happens when retrieval returns the wrong document, or the user asks an ambiguous question, or the model returns prose instead of valid JSON? What happens when latency becomes unacceptable, API costs suddenly increase, an agent chooses the wrong tool, a model provider changes behavior, or a prompt improvement fixes one case and breaks five others?

This is where I think some of the best opportunities will be. Companies don’t only need people who can make AI demos — they need people who can make those systems less fragile. That means guardrails, testing, logging, retries, fallbacks, monitoring, human approval, access control, cost limits, and clear boundaries.

Sometimes the smartest solution is to use an LLM for only one small part of a workflow. Sometimes the best solution is normal software. Sometimes the correct answer is not to use AI at all. Good engineers should be able to make that decision.

Do not forget the business problem

It’s easy to become obsessed with tools. You learn LangChain, then LangGraph, then another agent framework, then a new vector database. But at some point, you need to ask a simple question: what problem are you solving? “An AI agent built with LangGraph” is not a business problem. “A multi-agent architecture” is not a customer need.

Start with the person using the system. What are they trying to do? What takes too much time? Where do mistakes happen? What information does the system need? Which part should the model handle, and which part should normal code handle? Where should a person approve the result? How will you know the system is useful, and what happens when it fails?

These questions aren’t as exciting as choosing an agent framework, but they usually lead to better projects — and to much better interview conversations. Companies don’t hire technology stacks. They hire people who can help solve problems.

Start small enough to finish

Another mistake is choosing a first project that’s simply too big. “Build a fully autonomous AI company” is probably not the best place to start, and “create a multi-agent platform that researches, codes, deploys, markets, sells, and runs a company automatically” can wait until later.

Start smaller. Build a customer support assistant for a small set of documents. Build a text-to-SQL assistant over a sample database. Build a tool that turns messy text into validated JSON, a contract clause finder, a prompt comparison tool, or a small agent that uses two tools and has clear stopping rules. Then finish it, test it, document it, publish it, and improve it.

Finished projects give you feedback. Huge unfinished projects usually just give you folders.

A realistic path for someone starting now

Suppose you already know a little Python and SQL. Here’s the path I’d suggest.

Start with LLM APIs. Learn messages, roles, structured outputs, streaming, context limits, retries, rate limits, and cost, then build something small.

After that, learn retrieval: embeddings, similarity search, chunking, metadata, vector databases, and the difference between retrieval failure and generation failure.

Then learn tools and agents — but keep the first projects small: one model, a few tools, clear instructions, logging, a step limit, and proper error handling.

Then learn evaluation: create test cases, run them repeatedly, compare results, and record failures.

Finally, learn how to expose and deploy the system: build an API, containerize it, manage environment variables correctly, add basic logging, and deploy it somewhere.

This path won’t make someone an expert in three weeks. But it will create something far more useful than surface-level familiarity — an understanding of how the pieces of a practical AI system fit together. And it will give you proof.

The opportunity is real. The hype is optional.

I want to be careful with the message here. Whenever a new technology becomes popular, bad career advice appears around it: “learn AI and become rich,” “become an AI engineer in 30 days,” “no coding required,” “build agents and make passive income.” I don’t think this kind of advice helps anyone.

Practical AI engineering is still engineering. You need patience, fundamentals, and the willingness to debug things, read documentation, work with data, test your work, explain your decisions, and finish projects. And yes, you may still apply for jobs and get rejected. That’s the honest version.

But the honest version is still encouraging. There are real technical problems around LLM applications, retrieval, agents, evaluation, integration, cost, safety, and deployment — and people who get good at solving those problems can create real value. That’s the opportunity.

My advice: become useful

If I had to reduce this entire article to one idea, it would be this: try to become useful. Not impressive — useful. Learn how the system works, build something, break it, fix it, test it, explain it, publish the evidence, and then do it again.

The job market may stay difficult for a while. Some roles will change, some tools that look important today will disappear, some frameworks will be forgotten — that’s normal in technology. The deeper skills last longer: Can you learn a new API? Can you work with unfamiliar data? Can you debug an unreliable system? Can you measure whether something improved? Can you explain your technical decisions clearly? Can you connect a technical system to a real problem? Those abilities matter beyond any one framework, model provider, or AI trend.

AI is changing the technology market, but it isn’t removing the need for people who can think clearly, build carefully, test honestly, and communicate well. The bar may be higher than it was a few years ago. That’s frustrating, but it also tells us what to do: don’t stop at “I learned AI.” Build something. Show the work. Explain your choices. Measure whether it works. Study where it fails. Keep improving.

In a difficult market, you can’t control every hiring decision, layoffs, how many people apply for the same position, or whether a recruiter replies. But you can improve the quality of your skills, build evidence, make your work visible, and learn how practical AI systems are really built — becoming someone who understands both the potential and the problems.

That doesn’t guarantee a job. Nothing honest can. But it gives you more ways to create value, more things to show, more interesting conversations to have, and more directions your career can move. And in a tough job market, having more options matters.