DEV Community: Instancian

Vectors in AI: A Bridge Between Code and Business

Instancian — Thu, 14 Aug 2025 18:58:34 +0000

Vectors in AI: A Bridge Between Code and Business

Note from the series “About AI for Yourself and Others”

Whether you’re shaping a digital strategy, integrating AI into your workflow, or just curious about what makes an assistant respond intelligently — understanding one simple idea can change the way you think about AI.

That idea is the vector — a compact way AI represents meaning in words, documents, questions, even emotions.

Knowing how vectors work will help you:

Find information without exact keywords
Train AI on your company’s internal knowledge
Automate processes in HR, customer support, and beyond

Let’s see why vectors are at the heart of modern AI — and why they matter for your business.

Example: Vectors in HR — From Filtering to Team Building

In HR, AI has moved far beyond scanning resumes — now it can help you build stronger, more aligned teams. With vector representations, we can work with people in smarter ways — from building stronger teams to checking cultural fit and mapping career growth.

Here’s how it works:

📄 Resumes as vectors — AI transforms each resume into a set of numbers capturing the candidate’s skills, experience, and professional style. For example, someone with extensive project management and team motivation experience will have higher values on those dimensions.
🧾 Job descriptions as vectors — Each job description is also converted into a vector, reflecting tasks, goals, and company culture.
🤖 Semantic matching — AI compares resume and job vectors to see how well they align in meaning and context, not just by shared keywords.

What this gives to HR and business:

⚡ Faster team assembly for projects, using past roles and shared values as a guide.
🧠 Better candidate discovery, even if resumes lack the “right” keywords.
🧭 Cultural fit insights — AI can estimate a candidate’s communication style, preferences, and certain soft skills by analyzing the choice of words and phrasing in their resume.

The Resume of the Future

Not long ago, candidates were advised to keep resumes short and scannable — because recruiters often spent just 6–8 seconds deciding whether to read further or move on.

Today, we’re moving toward rich, detailed project histories — and that’s a good thing.

With vector analysis, AI can go far beyond job titles. It can understand:

📂 Projects a candidate worked on
🏷️ Roles they played in each project
🛠️ Problem-solving approaches they used
📈 Skill growth over time

This means format matters less — AI focuses on the meaning of someone’s experience, even if it’s not in the usual one-page format.

Technical Basics: What Is a Vector?

If you strip away all the AI buzzwords, a vector is simply a way to represent meaning as numbers.

It’s a list of coordinates that describes something — like text, an image, or a question — in a space with hundreds or even thousands of dimensions.

Example: the word “leadership”
After processing by an AI model, it becomes a vector like this:
[0.134, -0.278, 0.045, 0.892, -0.116, 0.003, 0.721, -0.443, 0.056, ...]

You can think of a vector as a GPS coordinate in a city of meanings. Each word, sentence, or document is a location on this map. Words with similar meanings cluster together in neighborhoods, and streets connect related ideas. For example, the word leadership would be located in a “Neighborhood of Leadership,” surrounded by streets and blocks where related words live — management, motivation, and teamwork. Nearby streets connect to other neighborhoods, like “Communication” or “Strategy,” allowing AI to navigate from one concept to another, finding words or ideas that are semantically close, even if the exact words differ.

In short, AI doesn’t look for exact words — it looks for similar meanings, navigating the “city of words” to understand context and relationships.

These vectors don’t appear out of nowhere. They are created by specially trained AI models, most commonly variants of BERT and its successors. The model reads text (or other data) and assigns each word, sentence, or document a position in the “city of meanings” we described. You could also use other models, like Gemma3, but for most business applications this can be overhead — BERT-based models or their lighter variants usually provide a good balance between quality and efficiency.

Models That Create Vectors

Model	Year	Developer	Notes
RoBERTa	2019	Facebook	Trained on more data than BERT
ALBERT	2019	Google	Smaller size, similar accuracy
DistilBERT	2019	HuggingFace	Faster and lighter, good quality
E5	2022	Microsoft	Made for search and RAG tasks
OpenAI Ada v2/v3	2022–24	OpenAI	Works well with large vector databases
InstructorXL	2023	HuggingFace/Alibaba	Adapts to specific tasks

How It Works in a Business App (5 Steps)

Text → Model → Vector

A document or query is transformed into a vector by an AI model. This vector captures the semantic meaning of the text in numerical form.
Save in Database

The vector is stored alongside the original text — for example, in PostgreSQL using pgvector.
User Query → Vector

When a user asks a question, the query is also transformed into a vector by the same model, ensuring that both documents and queries are in the same semantic space.
Compare Vectors

The system compares the query vector with stored vectors to find the closest matches:
- Using SQL — e.g., ORDER BY embedding <-> query_vector LIMIT 5 in PostgreSQL with pgvector. This returns the nearest vectors based on numerical similarity.
- Using RAG (Retrieval-Augmented Generation) — an AI assistant first retrieves the most relevant documents via vector similarity, then generates answers based on them.
Return Result

The system delivers the most relevant matches to the user — for example, a list of similar documents, products, or candidates.
If connected to an AI assistant, these results can be used as context to generate a detailed, personalized answer.

This approach allows AI to retrieve documents or generate answers based on meaning, not just exact keyword matches. Advanced topics like indexing, normalization, and fine-tuning can improve efficiency and accuracy, but these five steps cover the core idea.

HR is a familiar use case for vector-based AI — and yes, perhaps a bit overused. Still, it offers a clear starting point. In future articles, we’ll move beyond the resume and dive into more original, business-critical applications: semantic email processing, the design of executive assistants with real accountability, and the improvement of workflows.

Want to build your own semantic assistant? Let’s explore it together in the next article.

Programmer’s Demons — and How to Defeat Them

Instancian — Thu, 31 Jul 2025 12:58:44 +0000

Introduction: Thought Patterns That Interfere With Architectural Decisions

When working in system architecture without external guidance, decision-making depends entirely on your ability to stay clear-minded and focused. Yet clarity is constantly challenged. Certain thought patterns — recurring, subtle, and often embedded in team culture — can undermine productive action.

They don’t announce themselves. Instead, they show up as familiar hesitations, internal arguments, or inherited habits:

“What if we need this later?” — defers important clean-up decisions and feeds technical debt.
“Abstraction for abstraction’s sake” — adds complexity without increasing clarity or value.
“We must do it the right way” — slows momentum under the weight of imagined ideals.

This article is a practical snapshot of recurring thought patterns encountered by architects working in high-autonomy environments. In such contexts, clarity isn’t pre-approved — it’s earned through thoughtful, independent decision-making. Identifying these patterns helps build stronger judgment, reduce friction, and support more confident architectural choices.

Demon 1: “What if we need it later?”

The main supplier of useless layers, DI wrappers, and microservices.

What it says:

“Make it flexible now. Otherwise, we’ll rewrite everything later.”
“What if we scale to millions of requests?”
“What if we have 7 teams next year?”

🛡️ How to fight it:

Ask: “What do we need this month?”
Motto: “When ‘later’ comes — we’ll build it. For now — go straight.”

Demon 2: Abstraction for abstraction’s sake

“Add an interface, just in case the class changes.”

What it says:

“You can’t call a class directly — abstract it.”
“Add a layer on top of the layer, just in case.”

🛡️ How to fight it:

Practice: “Use interfaces only when there are real alternatives.”
Principle: “Keep it simple until it hurts.”

Demon 3: “This is how enterprise does it”

“If Google does it — we must too.”

What it says:

“Clean Architecture is the only way.”
“Without CQRS, DI, EventBus — you’re not a real architect.”

🛡️ How to fight it:

Realize: “Their scale ≠ your scale.”
Practice: “Write for your reality, not for a mythical industry.”

Demon 4: “Let’s make it perfect — then release”

The guardian of eternal refactoring and dead MVPs.

What it says:

“Just a bit more — then it’ll be perfect.”
“It’s embarrassing to show it like this.”
“We need to rethink the architecture…”

🛡️ How to fight it:

Test: “Can you show this to a user tomorrow?”
Motto: “Done > Perfect”

Demon 5: “We must do it right, no mistakes”

The source of decision paralysis.

🧟 What it says:

“What if this is the wrong approach?”
“If it’s not SOLID, they’ll laugh.”
“Check 4 more options before choosing.”

🎯 How to fight it:

Mindset: “Decisions are not sacred — you can change them.”
Phrase: “Wrong is okay. Useless is not.”
Clarification: You always have the right to make a mistake. The real issue is repeating the same mistake three times.

Practices of Liberation

1. Morning Focus Protocol

Before diving into code — remind yourself why you’re doing this.

Why am I writing this? (Who is it for? What problem does it solve?)
What can I do simply today?
Where can I stop overthinking?

🧭 Shift from “engineer of engineering” to “creator of meaning.”

2. Task Mirror

Before adding a layer — ask:

Does this abstraction solve a real pain — or a hypothetical one?
Am I complicating out of fear or necessity?
Can I solve this right now in a simpler way?

📌 Put this in your IDE as a snippet or sticky note.

3. Release Pressure from Perfectionism

“Code doesn’t need to last forever. It needs to work now — clearly and usefully.”

⛔ Not Needed	✅ Enough for Today
Perfect	Useful
Architecturally fancy	Architecturally clear

🧭 Designing for eternity is a trap. In fast-moving environments — where frameworks shift, APIs deprecate, and teams evolve — even well-crafted code can become legacy within 2–3 years. Your product doesn’t need to last forever. It needs to be clear today, useful tomorrow, and replaceable when the world moves on.

4. Log of Useful Traces

At the end of the day — not “what I did,” but “what became useful.”

Examples:

Simplified generator template — less confusion
Added examples to README — easier to use
Removed extra DI layer — easier to read

🧠 Why it's useful to log what became useful: You’re training your brain to notice value — not just effort. By shifting focus from “what I did” to “what helped,” you build mental patterns that prioritize clarity, contribution, and self-trust. This reduces stress in high-pressure situations. You’re not just working — you’re learning. Not just how to deliver outcomes, but how to shape your way of being. Each log is proof that progress can be simple, even when circumstances aren’t.

I’m a .NET Developer, and I Want to Be Free from Frameworks.

Instancian — Thu, 24 Jul 2025 12:30:45 +0000

So Why Use a Framework at All?

I’m a .NET developer, and I have a dream. A dream to be free from frameworks.
I don’t want to depend on massive ecosystems where rendering a simple button requires installing 100 megabytes of dependencies and reading through dozens of pages of documentation. I want a simple implementation.

I don’t want a component that brings along a hundred others — just to show a button with an icon.
I don’t want to waste time resolving version conflicts and dependency hell when I could be working on logic and UI meaning.

And if I just need to refresh a component on the page — like in an SPA — that shouldn’t require restructuring the entire application. There’s no reason to subscribe to global state, register routes, or adhere to complex patterns. It’s just a reload, nothing more.

What works well on the server shouldn’t be forced into the client. We shouldn’t wrap everything in JavaScript just to compensate for it later with server-side JavaScript. It introduces unnecessary complexity and raises the entry barrier for developers.

In this vision, I have a partner — AI.
It doesn’t get tired. It doesn’t argue. And it truly understands HTML, CSS, and JavaScript. This is its native territory. It knows structure, style, behavior. It doesn’t need frameworks. It needs clear instructions — and it knows how to produce them.

It can generate interfaces, styles, animations. Confidently, reliably, fast. Its knowledge of this domain is deep and powerful.
And then I asked myself: if both AI and I understand these technologies well — why do we need a framework at all?
Why learn to wrap a simple idea in 10 layers of abstraction, when we can just write exactly what we mean?

What I Want Instead

We’ve accepted complexity as the cost of expressiveness — and for a time, that trade-off made sense. Before AI, we needed frameworks to structure our ideas, compensate for limitations, and unify practices across projects.

But today, we stand at a turning point.

That’s how Instancium TagKit Core was born.
It’s not a framework. It’s a rendering protocol.
It doesn’t require global state. It doesn’t ask for magical subscriptions. It doesn’t build a universe around your component.
It simply brings HTML to life.
You control the markup. It activates it.
Need SSR? Great. Need interactivity? Add JS where it’s needed — and only there. No excess. Each component remains isolated, clean, and understandable.

Instancium TagKit Core is built on simple principles:

Markup comes first. A component is HTML, CSS, and logic — not a framework structure.
Components don’t take over the app. They do only what they’re meant to.
Rendering is transparent and controlled.
AI can create, edit, and test such components — no magic, no ceremony, and no stumbling over framework version mismatches.

It’s an architecture where both humans and AI can work together.
Not as an experiment — but for productivity. To spend less time fighting the system, and more time creating value.
Instancium doesn’t compete with frameworks. It simply shows that there’s another way.

Right now, this idea is expressed as an open beta. But behind it is a philosophy and an engineering mindset. And it has every chance to become a new approach to building component-based user interfaces.

Follow the progress, join the discussion, and check out the repository:
https://github.com/Instancium/Instancium.TagKit