Prompting Is Not Engineering: The Skills AI Cannot Replace

In 2023 and 2024, "prompt engineer" became one of the hottest job titles in tech. Headlines screamed about prompt engineers earning $300,000+ a year. LinkedIn influencers declared that traditional coding was dead and prompting was the future. Courses on "prompt engineering" popped up everywhere, some charging hundreds of dollars to teach you how to talk to ChatGPT.

Here is what actually happened: when large language models first became widely available, there was a brief window where knowing how to write effective prompts was a rare and valuable skill. Companies were scrambling to integrate AI into their products, and the people who understood how to get good outputs from these models had leverage. That was real, and some people made real money from it.

But the window is closing fast. AI models are getting better at understanding poorly written prompts. Tools like Cursor and Claude Code are abstracting away the prompting entirely, handling the prompt construction behind the scenes so developers never write a prompt at all. The "prompt engineering" skill that commanded premium salaries in 2023 is rapidly being automated by the very technology it was designed to work with.

This does not mean prompting is useless. It means prompting is becoming a basic literacy skill (like knowing how to use a search engine) rather than a specialized, high-value expertise. The people who built entire careers around prompting and skipped learning actual engineering are now in a precarious position. The people who learned prompting as one of many skills in their toolkit are fine.

The lesson is not "do not learn prompting." The lesson is "do not mistake prompting for engineering." They are fundamentally different activities, and understanding that difference matters for your career.

Software engineering is not "writing code." That is like saying architecture is "drawing buildings." Code is the output, but the work is everything that comes before and after the code: understanding problems, designing solutions, making trade-offs, handling failure, and maintaining systems over time.

Here is what a software engineer actually does on a typical week. None of this can be replaced by writing better prompts:

System design. Deciding how to structure an application. Where does the data live? How do services communicate? What happens when one component fails? Should this be a monolith or microservices? These decisions have consequences that last years, and they depend on understanding the specific business context, team size, budget, performance requirements, and growth trajectory. No AI model has access to all of this context, and even if it did, these decisions involve trade-offs that require human judgment.

Debugging production failures. Your payment processing system stopped working at 2 AM. Users are angry. Your boss is calling. The logs show a cascade of errors across three services. You need to systematically isolate the problem, identify the root cause, implement a fix, verify the fix does not break anything else, and communicate the status to stakeholders. This requires deep system knowledge, the ability to stay calm under pressure, and the kind of diagnostic reasoning that comes from years of experience with similar systems.

Performance optimization. Your API endpoint takes 4 seconds to respond. Users are leaving. You need to profile the code, identify bottlenecks, decide whether to optimize the query, add caching, restructure the data model, or scale the infrastructure. Each option has different costs, risks, and implementation timelines. This is engineering judgment, not prompt writing.

Security. Ensuring that user data is protected, authentication is robust, inputs are validated, secrets are managed properly, and the system is resistant to common attacks. Security thinking is a mindset that pervades every design decision. AI tools are notorious for generating code with security vulnerabilities because they optimize for "does it work?" not "is it safe?"

Long-term maintenance. A codebase is not a one-time deliverable. It is a living system that needs updating, refactoring, migrating, and extending over years. Making changes to a 3-year-old codebase without breaking existing functionality requires understanding the system deeply, knowing which parts are fragile, and having the discipline to improve the code incrementally rather than rewriting everything.

Prompting, at its core, is the skill of communicating effectively with an AI model. You describe what you want, provide context, specify constraints, and the model generates output. It is a real skill, and doing it well produces significantly better results than doing it poorly.

Good prompting involves:

• Being specific about what you want (not vague or ambiguous)
• Providing relevant context (what the code should do, what constraints exist, what patterns to follow)
• Structuring your request clearly (breaking complex tasks into steps, giving examples of desired output)
• Iterating on the output (refining your prompt based on what the model got wrong)

These are useful skills. They make you more productive with AI tools. But notice what they are: communication skills. You are describing a problem and evaluating whether the solution is correct. That is valuable, but it is a fundamentally different activity from designing, building, and maintaining the system.

Here is the distinction that matters: prompting is about getting code. Engineering is about knowing whether the code is right.

Anyone can prompt an AI to "build a REST API for a blog." The AI will generate something that looks reasonable. But knowing whether that API handles concurrent writes correctly, whether the authentication is actually secure, whether the database queries will perform well at scale, whether the error handling covers real-world failure modes, and whether the code is structured for maintainability as the product grows: that is engineering. The prompt gets you a starting point. Engineering is everything after that.

To use an analogy: a prompt engineer is like someone who can describe a building they want to an architect. That is useful. But they are not the architect. The architect understands structural loads, material properties, building codes, environmental constraints, and the hundreds of trade-offs that determine whether the building stands for 50 years or collapses in the first storm. Describing what you want is the easy part. Making it work in the real world is engineering.

AI coding tools are getting better every month, and it is tempting to project that trend into "AI will do everything eventually." But some aspects of software engineering are fundamentally resistant to AI automation, not because of technical limitations today, but because of the nature of the work itself.

Understand your business context. Your company has a specific set of users, a specific revenue model, specific regulatory requirements, and a specific competitive landscape. The decision to build feature A before feature B, to optimize for mobile users over desktop users, or to prioritize performance over feature completeness depends on understanding this context deeply. AI does not know your business. It cannot attend your strategy meetings, understand your investors' priorities, or grasp why your CEO rejected the last product proposal. These constraints shape every engineering decision you make.

Make architectural trade-offs. Should you use a relational database or a document store? Should you build a monolith or split into services? Should you invest in a robust caching layer or keep things simple? These decisions depend on your team size, your budget, your growth projections, your hire-ability constraints, and a dozen other factors that vary wildly between organizations. There is no universally correct answer. AI can list the pros and cons of each option, but the judgment to pick the right one for your specific situation is yours.

Maintain a codebase over years. AI can generate code, but it cannot own a codebase. It does not remember the conversation you had six months ago about why that workaround exists. It does not know that the payment service is fragile because the vendor's API changed three times last year. It does not understand that the intern who wrote the notification system left and nobody else understands it. Institutional knowledge, the accumulated understanding of why a system is the way it is, lives in people's heads. AI has no mechanism for carrying this context across time.

Navigate organizational dynamics. The best technical solution is often not the one that gets built. Budget constraints, team politics, executive preferences, regulatory requirements, and legacy commitments all shape what is possible. Engineering in a real organization means building the best solution that is actually achievable given the constraints. AI does not model organizational dynamics. It does not know that the VP of Engineering hates microservices, that the compliance team will block any solution that stores data outside the EU, or that the team just shipped a major release and does not have capacity for another large project for two months.

Take responsibility. When a system fails and users are affected, someone is accountable. That someone is a human engineer. AI tools do not page into incidents, do not explain outages to customers, and do not stand behind the decisions they made. Responsibility requires agency and accountability, which are fundamentally human qualities.

If AI is handling more of the code generation, what should you spend your time learning instead? These are the skills we emphasize in the McTaba Labs marathon because they are the ones that gain value as AI tools improve.

System design and architecture. Understanding how to structure applications for scalability, reliability, and maintainability. This includes database design, API design, service boundaries, caching strategies, and the ability to reason about distributed systems. AI can suggest architecture patterns, but choosing the right one for your context requires experience and judgment. This is the skill that separates junior developers from seniors, and it is not going away.

Debugging and diagnostic reasoning. The ability to systematically identify the root cause of a problem in a complex system. This requires building mental models of how systems work, forming hypotheses about what might be failing, and testing those hypotheses methodically. It is a skill that develops through practice (through the experience of debugging hundreds of issues over years). AI can help you debug specific errors, but the diagnostic reasoning process itself is something you need to develop.

Code review and quality judgment. Reading code and evaluating whether it is good. Not just "does it work?" but "is it maintainable, secure, performant, and consistent with our codebase conventions?" As AI generates more code, the ability to review that code critically becomes more valuable, not less. Someone has to be the quality gate, and that someone needs the judgment to distinguish between code that is correct and code that is good.

Communication and collaboration. Writing clear documentation, participating effectively in code reviews, explaining technical decisions to non-technical stakeholders, mentoring junior developers, and working productively in a team. These are human skills that AI does not touch. In our experience at McTaba Labs, the developers who advance fastest in their careers are not the ones who write the most code. They are the ones who communicate most clearly and collaborate most effectively.

Domain knowledge. Understanding the specific domain you work in: fintech, healthcare, logistics, education, e-commerce. An AI tool knows generic programming patterns, but it does not understand why M-Pesa callbacks need specific idempotency handling, why healthcare data has HIPAA constraints, or why your logistics app needs to handle unreliable GPS data in rural areas. Domain expertise combined with engineering skill is the most defensible position you can build.

Notice a pattern: every skill on this list involves judgment, context, and the ability to make decisions under uncertainty. These are exactly the areas where AI is weakest and humans are strongest. Lean into them.

Here is the blunt career advice: if your plan is to skip learning software engineering and rely entirely on prompting AI tools, you are building on sand.

Consider what happens as AI tools improve. Every improvement in AI makes prompting easier, which means the bar for "being good at prompting" drops. Today, writing a detailed, well-structured prompt produces noticeably better results than a vague one. In a year, the models will probably handle vague prompts just as well. The skill you invested in becomes less differentiating with every model update.

Meanwhile, the engineering skills (system design, debugging, security, architecture) become more valuable as AI handles more of the routine coding. Companies still need people who can make architectural decisions, debug production systems, ensure security, and take responsibility for the software. They need fewer people to write boilerplate CRUD endpoints, but they need more people who can evaluate whether the AI-generated code is actually correct and safe for production.

The job market reflects this. In Nairobi, Lagos, and internationally, companies are not hiring "prompt engineers" at the rates they were in 2023. They are hiring software engineers who can use AI tools effectively. The distinction matters: the job title has "engineer" in it because the engineering skills are what they are paying for. The AI proficiency is expected on top of that foundation, not instead of it.

At McTaba Labs, we teach both. Our cohort members learn to use AI tools fluently (Cursor, Claude Code, Copilot). But they also build real projects from the ground up, debug complex systems, design databases, implement authentication, and ship to production. The AI skills make them more productive. The engineering skills make them employable. You need both, and neither can substitute for the other.

If you are early in your career and deciding where to invest your learning time, invest in the fundamentals: data structures, algorithms, system design, databases, networking, and security. Then learn AI tools on top of that foundation. You will be far more valuable than someone who skipped the fundamentals and went straight to prompting.

None of this is an argument against learning to prompt well. Effective prompting is a genuine force multiplier for developers who have engineering fundamentals. The point is that prompting is a tool in the toolkit, not the toolkit itself.

Here is how experienced engineers use prompting effectively in their daily work:

Exploration and prototyping. When evaluating a new technology, library, or approach, prompt AI to generate a quick prototype. This is dramatically faster than reading documentation from scratch. But treat the prototype as a starting point, not a production-ready solution. Use it to understand the technology, then rebuild with proper engineering practices.

Generating boilerplate and repetitive code. Config files, TypeScript interfaces, test scaffolding, migration files. This is the kind of code where the pattern is clear and the implementation is just typing. Prompt AI to handle it, review the output, and move on. Your time is better spent on the parts that require judgment.

Learning and explaining. Use AI as a tutor. "Explain how PostgreSQL indexes work under the hood." "What are the trade-offs between JWT and session-based auth?" "Walk me through this unfamiliar codebase." The prompting skill here is knowing what questions to ask, and that requires enough engineering knowledge to know what you do not know.

Code review augmentation. After writing code (or reviewing AI-generated code), prompt a model to review it: "Look for security vulnerabilities, performance issues, and maintainability problems." This gives you a second pair of eyes. But you still need the engineering judgment to evaluate whether the AI's review feedback is valid. AI reviews sometimes flag non-issues and miss real problems.

Context engineering. The most advanced form of prompting is context engineering: structuring the information you provide to AI so that it produces better, more relevant output. This is a genuinely valuable skill that requires understanding both the AI tool and your codebase deeply. It is the intersection of prompting skill and engineering knowledge, and it is one of the highest-leverage skills a developer can have in 2026.

The common thread: in every case, the prompting skill amplifies engineering ability. Without the engineering foundation, prompting produces output that looks right but may be wrong in ways you cannot detect. With the foundation, prompting makes you significantly more productive and helps you build better software. The foundation is non-negotiable.