Beyond prompts: Stop guessing, start guiding AI

Beyond Prompts — AI-Generated Visual by Gemini

Table of contents · The Difference Between Prompting and Guiding · Context Is Everything · One AI Shouldn’t Do Everything · References

We’ve all been there, You ask an LLM to help you refactor a class or add a new feature, and it responds with a confident 200-line hallucinations that ignores your architecture entirely. It’s brilliant, yet somehow…kind of an idiot ?

The problem isn’t the model. The problem is that we’re treating a reasoning engine like a simple Google search bar. If you want results that actually save you time instead of creating more work, you have to stop prompting and start guiding.

Welcome to the era of Agentic AI !

The Difference Between Prompting and Guiding:

Most developers still use AI like they’re texting a genie.

“Make this cleaner.”

“Optimise this.”

“Refactor my architecture.”

Then they act surprised when the model returns a beautifully formatted disaster that somehow violates every design decision made since the beginning of the project.

AI is extremely capable. But it is also extremely literal. Ambiguous prompts create ambiguous code. If your request is vague, the AI model fills in the blanks itself. And trust me, it will fill them in. Confidently.

Let me show you what I mean in action

Bad example:

Figure 1. AI prompt- bad prompt example.

I asked for a file with a few things and it went on to create 6. It guessed what I might want instead of asking.

Now watch what a guided prompt should look like:

Figure 2. AI prompt- guided prompt example.

I gave it specifics and constrains to follow , demanded analysis and to ask before going into action. See how the agent responded below.

Figure 3. AI prompt- analysis driven AI response.

Same model, completely different outcome. One prompt asks agent to guess, the other gives it a job.

The quality jump becomes obvious the moment you assign the agent an actual role and suddenly the answers stop sounding like StackOverflow snippets from 2015 from that random guy who refused to clarify his answer.

Context Is Everything

Here’s the uncomfortable truth:

Most AI agent hallucinations in software development are self inflicted.

We hand the model a few random files, zero architecture context, no business logic explanation, and somehow expect it to understand a couple years old codebase better than the team maintaining it.

AI cannot respect architecture it cannot see.

If your app has:

• feature modules
• layered architecture
• shared contracts
• internal conventions
• custom patterns

then those things need to become part of the context. Otherwise, the agentstarts improvising. Agent improvisation in production code is… an experience.

Cue the drum roll : Instruction files.

Many teams now maintain dedicated markdown files that explain:

• project structure
• architectural rules
• naming conventions
• forbidden patterns
• dependency boundaries
• coding standards

Think of it as onboarding documentation for your AI agents.

But the really good instruction files go beyond technical rules. They define behavioural principles. (Anthropic, The 4 Ds of AI Fluency: Behavioral Indicators, 2026)

Karpathy-Inspired (github — andrej karpathy 2025) Claude Code Guidelines are a perfect example:

• Think Before Coding Wrong assumptions, hidden confusion, missing tradeoffs.
• Simplicity First Avoid overengineering and bloated abstractions.
• Surgical Changes Don’t touch unrelated code just because you discovered free will.
• Goal Driven Execution Define success criteria first. Prefer verifiable outcomes over “looks correct to me.”

This is where the interaction starts feeling less like autocomplete and more like collaboration.

I will add a few photos below to show how the instruction files would look like and to actually use them you just ask your Agent to add them to the custom instructions file. This is Android studio + github copilot integration but the idea is the same across Claude, Curser or whichever you would like to use.

Figure 4. github copilot instruction settings setup

Figure 5. github copilot instruction settings setup

Figure 6. github copilot instruction settings setup

Figure 7. github copilot instruction settings example

Figure 8. github copilot instruction settings example

Once the model consistently understands your ecosystem, the interaction changes completely. You stop re-explaining the same rules every conversation. The agent stops creating two extra files for a 2 line change. It stops restructuring half the project because you said refactor this file. And most importantly, it stops putting random things everywhere like a 3 year old child discovering Lego bricks for the first time.

One AI Model Shouldn’t Do Everything

One of the biggest mindset shifts in modern AI workflows is realising that one assistant should not handle every responsibility.

Coding, architecture review, debugging, security analysis, and refactoring are completely different tasks. Yet most people throw all of them into the same conversation and end up with bugs, missing files or overcomplicated tasks.

Instead, developers are starting to build specialised agents with focused responsibilities. One agent writes code. Another reviews architecture. Another focuses purely on performance or security.

Suddenly the workflow becomes less chatbot and more engineering pipeline.

For example, a coding focused agent can be given the full picture of the system — the entire application structure, how modules relate to each other, the architectural documentation, and the project conventions it is expected to follow.

On the other hand, a review focused agent operates in a much tighter scope. It doesn’t need the whole world loaded into context. It gets the changed files, the pull request context, the review instructions, and the architectural expectations it should validate against.

The difference is intentional. You’re not trying to build a single omniscient agent that does everything at once. You’re splitting responsibility based on focus. And this matters more than people think, because most AI agents still don’t truly understand Git history or repository wide context in a reliable way. If you don’t control what they see, they will confidently assume what they don’t know and that’s where subtle but expensive mistakes start creeping in. (GitHub, About custom agents — github docs, 2025)

Below are snippets of a custom Code review Agent.

Figure 9. github copilot custom agent example

Figure 10. github copilot custom agent example

This is also where skills start becoming powerful.

Skills are essentially reusable behaviors or workflows that the agent can consistently apply across different tasks, whether that’s reviewing code with a critical eye for architectural violations, debugging crashes by tracing likely root causes instead of guessing, validating architecture decisions against predefined project boundaries, or analyzing performance issues by focusing on real bottlenecks instead of surface level optimizations. (GitHub, About agent skills — github docs, 2025)

Instead of re-teaching the agent every session, you’re essentially building repeatable systems around expertise.

Figure 11. Agent skills visual (Varnaa, 2026)

Want to take this to the next step ?

There are tools like NotebookLM. These are specifically made to understand and simplify documentation files or web links. It’s great because it doesn’t make up things outside of the info provided by the docs.

So, instead of trying to send 500 lines to your agent try using NotebookLM first to simplify the info and then give that revised smaller chunk to your Agent. I promise you will see the difference.

Photo with the most common notebooks out in the market below:

Figure 12. Beyond Prompts — AI-Generated Visual by Gemini

The developers getting the best results from AI are not the ones asking smarter questions. They’re the ones designing better systems around the AI itself.

Roles, Context, Constraints, Instructions, Specialized agents. That is what turns AI from an entertaining autocomplete machine into an actual development partner.

These are the patterns that have consistently worked best for me , I’m curious what your setup looks like. Are you still relying on raw prompts, or have you started building systems around how you use AI?

References

Claude. (no date). Tutorials. [online] Available at: https://claude.com/resources/tutorials (Accessed 05 May 2026).

Claude. (2026). The 4 Ds of AI Fluency: Behavioral Indicators. Available at: https://claude.com/resources/tutorials/the-4-ds-of-ai-fluency-behavioral-indicators (Accessed 05 May 2026).

Andrej-Karpathy-skills/readme.zh.md at main — multica-ai/Andrej-Karpathy-Skills (2025) Available at: https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md (Accessed 05 May 2026).

GitHub. (no date). GitHub Copilot Documentation. Available at: https://docs.github.com/en/copilot (Accessed 05 May 2026).

GitHub. (no date). About agent skills in Copilot. Available at: https://docs.github.com/en/copilot/concepts/agents/about-agent-skills (Accessed 05 May 2026).

GitHub. (no date). About custom agents in Copilot Cloud. [online] Available at: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-custom-agents (Accessed 05 May 2026).

Varnaa, Swetha. (2026). Agent Skills: What They Are and Why They Matter. Available at: https://www.linkedin.com/pulse/agent-skills-what-why-matter-swetha-varnaa-fxowf/ (Accessed 05 May 2026).

Note: This article speaks only to my personal views/experiences, is not published on behalf of Deloitte LLP and associated firms and does not constitute professional or legal advice. All product names, logos, and brands are the property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.