vi3ecoding Team
By Massimo Di Chiara, founder of Vi3ecoding — 11+ years in web, 100+ client projects shipped.
Two builders sit down with the same AI tools. Same Lovable account. Same ChatGPT. Same Supabase.
One ships a product that feels designed. The other ships something that feels like a demo.
The difference isn't the prompt. It's the context.
Context engineering is the actual job of an AI builder in 2026. Prompt engineering is the duct tape we no longer need.
Related reading from vi3ecoding:
- The Four Layers of Context Every AI Agent Needs
- Context Files for Lovable Projects
- What Is Vibe Coding, Really?
I didn't believe that two years ago. I do now. After shipping enough real client projects — foodla.eu being the most public one, where Lovable and Supabase carried an entire restaurant platform — I've stopped thinking of myself as a prompt writer. I think of myself as a context engineer who occasionally types prompts.
Here's what that actually means.
What is context engineering, in one sentence
Context engineering is the practice of giving an AI everything it needs to make a good decision before you ask it to do anything.
Not a clever prompt. Not a magic phrase. A pile of structured, relevant, up-to-date information that turns a generic model into something that behaves like a senior teammate on your project.
Why prompt engineering had to die
In 2023, "prompt engineer" was a job title on LinkedIn. In 2026, it's a punchline. The reason is simple: prompt engineering was always a workaround for weak models.
We needed magic phrases — "think step by step", "you are an expert", "let's reason carefully" — because the models couldn't reliably do those things without being nudged. Prompts were duct tape. The duct tape worked, and it created a whole industry of people selling prompt packs as if they were intellectual property.
Then two things changed:
- Models got dramatically better at inferring intent.
- Tools got dramatically better at carrying context across turns.
A 2026 model with rich context produces better output from a 5-word prompt than a 2023 model produced from a 500-word prompt. The leverage moved. A perfect prompt against missing context produces confident garbage. A boring prompt against rich context produces something you can ship.
The mental model I use: AI as a brilliant new hire
Imagine hiring a senior developer on Monday morning.
You don't hand them a one-line ticket and expect a feature by lunch. You walk them through the product. You show them the codebase. You explain the customer. You share the design system. You tell them what shipped last week and what's planned for next quarter.
That walk-through is context engineering. Everything I do with AI tools is the same walk-through, just written down once and reused forever.
The 4 layers of context I write for every project
I keep these as plain markdown files in every repo. The AI reads them before doing anything.
- Product context — what the product is, who it's for, what problem it solves, what success looks like.
- Technical context — stack, conventions, folder structure, naming rules, the boring stuff that makes code feel consistent.
- Design context — colors, typography, spacing, voice and tone, the brand rules a designer would tape to their monitor.
- Decision context — what we tried, what we rejected, and why. This is the layer most people skip — and it's the one that stops the AI from re-proposing dead ideas.
If any of these are missing, the AI fills the gap with averages. Averages are why so many AI-built apps look like the same app.
A real example: the foodla.eu rebuild
When I rebuilt parts of foodla.eu, I spent the first ~30 minutes not writing a single line of code. I wrote context.
- One page describing the restaurant onboarding flow.
- One page describing the data model and Supabase RLS rules.
- One page describing the visual language — the rounded corners, the spacing, the "warm but practical" tone.
- One page listing things we had already tried and rejected (a complex tag system, a public reviews module, etc.).
After that, the actual building took about 10 hours instead of the 40 it would have taken without that setup. Not because the AI got smarter. Because the AI finally had the same information a teammate would have had.
Prompt engineering vs context engineering — the honest comparison
Prompt engineering: "You are a senior React developer. Write a sign-up form using best practices."
Context engineering: "Here is our auth flow doc. Here is our component library. Here is the design system. Here is what we tried last month and why it didn't work. Now build the sign-up form."
Same goal. Wildly different output. The second one is how I work now.
Take any AI builder and run the same feature request twice — once with no context files, once with a clean product.md, stack.md, design.md and decisions.md. The second output isn't 20% better. It's a different category of output. That gap is the entire value of context engineering.
What most builders get wrong
They treat context like documentation — something you write once, leave in a folder, and forget.
Context isn't documentation. Documentation is for humans who can skim. Context is for AI tools that read it literally, every time. That means:
- Keep it short. Long context dilutes the important parts.
- Keep it current. Stale context is worse than no context.
- Keep it specific. "We prefer clean code" is useless. "We use kebab-case file names and named exports" is gold.
If your context file reads like a corporate handbook, it's already broken.
Why this is uncomfortable for some people
Prompt engineering had a vibe to it. It felt clever. It felt like a wizardry you could charge for.
Context engineering feels like writing a brief. Like product work. Like — gasp — documentation. It's less sexy. It's also harder to fake. You can't ship a "10 best context files" listicle the same way you could ship a prompt pack. Real context is project-specific.
How context engineering changes the way you hire and work
If you run a small studio like Vi3ecoding, this is the bigger shift: the most valuable person on the team isn't the fastest typer. It's the person who can extract a customer's real intent, structure it, and hand it to the AI in a form the AI can act on.
That's a product skill. A strategy skill. An editor's skill. It's not a coding skill in the traditional sense — and that's exactly why classic developers often underrate it, and why product-minded people often overperform with these tools.
When I look at someone's portfolio now, I don't care which model they used or which IDE. I care whether their projects look like they had a teammate, or like they had a stranger. Stranger-output means weak context. Teammate-output means strong context.
So — what's the skill that separates good AI builders from great ones?
It's not the model you use. It's not the IDE. It's not your stack.
It's how much context you give the AI before you ask it to do anything.
Prompt engineering got you a demo. Context engineering gets you a product. The fastest typers stopped winning. The clearest thinkers started.