DEV Community: Mykola Mizhigurskiy

100+ API Endpoints and Almost Zero Integration Bugs. Sharing the Framework.

Mykola Mizhigurskiy — Tue, 18 Aug 2026 14:19:48 +0000

Like most developers, I spent quite a long time suffering from integration issues that inevitably appear in any reasonably serious project: the backend changes a field, adds a new one, changes its format — and the frontend finds out only after something breaks.

So, some time ago, I decided I had had enough and built my own API contract testing framework for the project I was working on. In practice, the result turned out even better than I expected: after fully implementing it, the number of integration issues between the frontend and backend dropped to almost zero.

In this article, I want to share this framework with you: how I designed it, what problems I wanted to solve, how I organized schemas and contracts, and why it eventually became much more than just a collection of API tests.

The stack in my case is fairly standard for a modern frontend project: JavaScript, TypeScript, React, and Zod. But the idea itself is not tied to any particular library — Zod is simply a very convenient tool for implementing it.

Before building anything, I defined the primary goal of the framework: automatically validate real API responses and guarantee that the backend returns exactly what the frontend expects.

That means catching changes in field types and formats, missing required fields, newly introduced unexpected fields, validation rule violations, and changes to stable response structures.

And that is where the entire framework architecture begins.

QA Engineer vs. Software Developer

Before we begin, I want to address what I believe is a fairly common misconception about API contract testing: that it should be done by developers rather than QA engineers.

This framework can be implemented and successfully used by both a QA engineer and a software developer. Its basic implementation does not require deep knowledge of the application architecture: a QA engineer can describe API contracts, build validation schemas, and use them to automatically validate API responses. In this form, the framework already fully performs its primary task — detecting contract violations between the backend and its consumer.

However, when a software developer integrates this framework directly into the application architecture, the same resources can provide significantly more value. Properly designed schemas effectively become a single source of truth for several parts of the application:

TypeScript types;
contract tests;
runtime validation;
form validation;
rules and constraints for individual fields;
frontend elements that depend on those constraints, such as validation errors or character counters;
API documentation.

So instead of independently describing the same structure in types, tests, forms, UI, and documentation, we define it once and reuse it everywhere it is needed.

That is why, for QA, this framework can be a powerful API contract testing tool, while for a developer it can also become part of the application architecture itself.

Framework Organization

src/api/
  ├── endpoints  # Resources required for API interaction
  |   └── users  # Business-entity folder grouping related endpoints
  |       └── getProductById/  # Named endpoint folder
  |           ├── getProductById.api.ts  # Bare reusable API function
  |           ├── getProductById.hook.ts  # UI-ready hook
  |           └── getProductById.schemas.ts  # Validation schemas and types
  └── schemas  # Business-entity definitions
      ├── common.schemas.ts  # Schemas and types reused across business entities
      └── product.schemas.ts  # Schemas and types for a specific business entity

Pay attention to how the files inside each endpoint are organized. There are two reasons for this.

The first is that I build this framework as an AI-native architecture and try to make it as predictable and convenient for AI agents as possible. The more clearly responsibilities are separated and the more stable the naming patterns are, the easier it is for an agent to understand the structure, locate the correct file, and extend the existing implementation consistently.

The second reason is separation of concerns. I intentionally split the implementation into several suffix files, each with one clearly defined responsibility:

*.api.ts — a minimal function responsible for interacting with the API. It does not depend on React and contains only the logic required to make a request and receive a response. Because of this, it can be used independently in React hooks, contract tests, server-side code, or any other consumer.
*.hook.ts — the React layer on top of the API function. This is where loading and error states, caching, state management, transformations, and other UI-specific logic can live.
*.schemas.ts — the contract of a specific endpoint: Zod schemas for runtime validation and the TypeScript types associated with them.

This separation is particularly important for contract tests. A test does not need to initialize React or pull UI-specific logic along with it just to validate an API. It can call a function from *.api.ts directly and validate the response using a schema from *.schemas.ts.

Naming Conventions

I personally consider semantics one of the most underrated parts of software development, and I take it very seriously. A good name should immediately tell you what entity you are looking at, what role it performs, and where it is used, even before you open the file.

This becomes especially important in AI-native repositories: consistent naming allows AI to infer relationships between entities more accurately, anticipate their purpose, and find the right context. That is why naming conventions in this framework are not cosmetic — they are part of the architecture.

Endpoints

For endpoints, I use a simple rule:

<operation><entity><qualifier?>

The operation comes first, followed by the business entity, and then, when necessary, an additional qualifier describing the request.

For example:

getProductById
createProduct
modifyProduct
deleteProduct
getUserProduct

The same naming is used for the endpoint folder and its related files:

getProductById/
  ├── getProductById.api.ts
  ├── getProductById.hook.ts
  └── getProductById.schemas.ts

This way, all parts of a particular API request can easily be found using the same name.

Schemas & Types

For schemas and types, I use a separate set of standard suffixes describing the role of the data in a particular request:

QueryParams
RequestPayload
ResponsePayload

If the entity is a Zod schema, I simply add Schema to the name.

For example:

GetProductById_QueryParams
CreateProduct_RequestPayload
GetProductById_ResponsePayload
GetProductById_ResponsePayloadSchema

As a result, the name itself describes the structure:

<endpoint>_<data role><Schema?>

So when you see GetProductById_ResponsePayloadSchema, you immediately know three things:

which endpoint it belongs to;
which part of the API contract it describes;
that you are looking at a runtime schema rather than a TypeScript type.

Getting Started

Common Schemas

Let us start with the simplest file — common.schemas.ts.

Its purpose is to store small but reusable schemas that appear across many business entities. These are not standalone application models, but rather building blocks: IDs, timestamps, tracker fields, UUIDs, emails, and other standardized primitives.

For example, a minimal common.schemas.ts might look like this:

import { z } from 'zod'

// Unified ID type used across the application
export const Id_Schema = z.string().uuid()

// Unified set of fields used to track entity creation and modification
export const Tracker_Schema = z.object({
  createdOn: z.string().datetime(),
  modifiedOn: z.string().datetime(),
})

These schemas are not duplicated in every business entity. Instead, they are reused through extend() or directly as individual fields.

This allows us to change a rule in one place and automatically propagate it throughout the application.

Business Entity

Now let us move to product.schemas.ts — the file describing the Product business entity. For schemas like this, I use a simple naming rule: the entity name plus the Schema suffix — in our case, Product_Schema.

There is one fundamentally important point here: we describe the entity as the frontend sees it, not as it exists internally on the backend. The same entity can have different representations on the two sides of an API.

For example, the backend model of a product might contain a stock property with the exact number of units remaining in the warehouse. The store owners probably do not want to expose that information publicly, so instead of stock: 12345, the frontend might receive only inStock: true.

That frontend representation is what our contract should describe.

import { z } from 'zod'
import { Id_Schema, Tracker_Schema } from './common.schemas'

// Product business-entity schema for runtime validation.
// Extends the shared tracker fields.
export const Product_Schema = Tracker_Schema.extend({
  id: Id_Schema,
  name: z.string(),
  description: z.string().min(5).max(500),
  inStock: z.boolean(),
})

// Product type automatically inferred from the runtime validation schema.
export type Product = z.infer<typeof Product_Schema>

// Generic Response Schema for endpoints that return the same object shape.
export const Product_GenericResponseSchema = Product_Schema

An important detail here is that we do not define the Product type separately. It is automatically inferred from the same Zod schema through z.infer.

As a result, Product_Schema becomes both a runtime representation of the contract and the source of compile-time typing. If we change the structure or validation rules of Product_Schema, the TypeScript Product type changes with it.

Runtime validation and typing remain synchronized by design.

Also note Product_GenericResponseSchema. In real-world APIs, several endpoints often return the same representation of an entity.

Instead of describing that shape again in every endpoint-specific file, I suggest defining it at the higher business-entity level and reusing it from there.

One more important clarification about Product_Schema: a business-level schema should contain every field that may appear for this entity across any endpoint.

This is not an endpoint-specific contract. It is an entity-specific contract — effectively a single source of truth for all fields of the entity and their validation rules.

Individual endpoints then build their own contracts on top of this base schema using pick, omit, extend, or reusable subschemas.

API Contract

Once we have a canonical business entity, it is time to describe the contract of a specific endpoint. For this example, let us use createProduct.schemas.ts.

Suppose the get, create, and update endpoints all return Product in the same representation. In that case, there is no reason to redefine the schema every time.

We simply import the prepared Product_GenericResponseSchema from product.schemas.ts and use it as the basis for CreateProduct_ResponsePayloadSchema.

import { z } from 'zod'
import {
  Product_GenericResponseSchema,
  type Product,
} from '@/api/schemas/'

// Runtime validation schema for the Create Product response payload.
export const CreateProduct_ResponsePayloadSchema =
  Product_GenericResponseSchema

export type CreateProduct_ResponsePayload = z.infer<
  typeof CreateProduct_ResponsePayloadSchema
>

// Request payload type for Create Product.
// A Zod schema is intentionally not created because it is not used.
export type CreateProduct_RequestPayload = Pick<
  Product,
  'name' | 'description'
>

There is another important principle here: do not create a Zod schema just because you can.

If some data never goes through runtime validation and the schema is not used anywhere, it only creates additional code and another entity that must be maintained.

That is why a Zod schema makes sense for ResponsePayload, which we are going to validate in contract tests. But if compile-time typing is enough for RequestPayload, we can simply derive the required type from the existing Product type using Pick.

This way, even endpoint-specific contracts continue to derive from the same source of truth instead of creating parallel descriptions of the same structure.

Contract Tests

Once the business entities and endpoint contracts have been described, the tests themselves become almost boring.

All you need to do is call the API, receive the response, and validate it against the appropriate Zod schema.

import { getProductById_API } from '@/api/endpoints'
import { GetProductById_ResponsePayloadSchema } from '@/api/schemas'

describe('API contracts', () => {
  describe('Products', () => {
    it('GET product by ID', async () => {
      const data = await getProductById_API(12345)

      expect(() => {
        GetProductById_ResponsePayloadSchema.parse(data)
      }).not.toThrow()
    })
  })
})

All the complexity is already contained in properly designed schemas, so adding another check usually takes only a few lines of code.

Important Clarification: These Are Not API Unit Tests

It is important to understand the purpose of contract testing correctly.

We are not trying to test the API itself or verify all of its business logic. This is not the place for edge cases, attempts to “break” an endpoint, or checks of how the backend behaves when given invalid data.

Our task is much simpler: make a valid request, receive a successful response, and verify that it matches the contract our application relies on.

So keep contract tests as simple as possible:

call the API;
make sure the request succeeds;
validate the response against the appropriate schema.

Do not turn contract tests into a duplicate of the backend unit test suite — you do have one, right?

There is only one thing we care about here:

Does the API return what its consumer expects?

Pro Tips

#1. Array Validation

Keep in mind that Zod successfully validates an empty array even when a specific schema is defined for its elements:

z.array(Product_Schema)

For [], validation passes successfully because there is simply no element to which Product_Schema can be applied.

So if your test is supposed to validate not only the presence of an array but also the shape of its elements, make sure your test data contains at least one item.

For example:

expect(data.length).toBeGreaterThanOrEqual(1)

Otherwise, you risk getting a false positive: the test is green, but the structure of the objects inside the array has never actually been validated.

#2. Catching New Fields

In contract tests, it is important to detect not only missing or invalid fields, but also new unexpected fields appearing in the response.

That is why schemas should be validated in strict mode. Otherwise, the backend may add a new field and your test will never notice it.

There are two ways to solve this.

The first is to explicitly enable strict validation in every Zod object schema:

const Product_Schema = z
  .object({
    id: Id_Schema,
    name: z.string(),
  })
  .strict()

The second option, which I personally prefer, is to create a dedicated utility for contract tests.

It recursively traverses the entire provided Zod schema and applies strict behavior to all object schemas, including objects nested inside arrays, other objects, unions, and so on.

This keeps the schemas themselves universal while centralizing strict behavior exactly where it is needed — in contract tests.

#3. Show the Received Value

Another small detail that has a surprisingly large impact on debugging: the validation error should show the actual value that failed validation.

A message such as “the field does not match the expected format” is often not enough, especially when tests operate on large responses or deeply nested structures.

I recommend configuring error reporting so that, along with the field path and the reason for the failure, it also prints the value that triggered the error.

Instead of something abstract like:

Invalid format at products[3].id

it is much more useful to get something like:

Invalid format at products[3].id
Received: "abc-123"

It may seem like a small detail, but in practice it significantly reduces the time required to investigate failing tests.

#4. Stable Data

Sometimes an API contains endpoints that return stable data — values that are not expected to change regularly.

A typical example is a list of statuses for a business entity.

In this case, it can be useful not only to validate the general response shape but also to explicitly lock down the expected set of values using literals.

For example:

const ProductStatus_Schema = z.enum([
  'Pending',
  'In Progress',
  'Done',
])

At first glance, this may look like unnecessary overhead. In practice, however, it can be extremely useful — especially when frontend behavior depends directly on specific statuses.

For example, different statuses may display different UI, enable different actions, or trigger different business logic.

In such a case, introducing a new status or renaming an existing one is no longer just a data change. It is a contract change that can potentially affect the frontend.

If you cannot be completely sure that the backend team will always notify you about such changes in time, contract tests can serve as an additional safety net.

Bonuses

At the beginning of the article, I mentioned that a software developer can get much more from this framework than contract tests alone.

Since the Zod schemas have already become our single source of truth, we can reuse them directly in application code.

Here are a few practical examples.

#1. API Typing

Since TypeScript types are automatically inferred from our Zod schemas, the same types can be used directly in the API layer:

export const getProductByIdApi = async (
  id: string,
): Promise<GetProductById_ResponsePayload> => {
  return api.get(`/products/${id}`)
}

This means API typing and API validation are based on the same source of truth.

Change the schema, and the type used by the application code changes with it.

#2. Runtime Validation of Local Storage Data

Suppose a user is creating a product and we store a draft of the form in localStorage.

After the page reloads, we want to restore it — but before putting the data back into the form, we want to make sure it still conforms to our contract.

const rawDraft = localStorage.getItem('productDraft')

if (rawDraft) {
  try {
    const parsedDraft = JSON.parse(rawDraft)
    const result = ProductDraft_Schema.safeParse(parsedDraft)

    if (result.success) {
      form.reset(result.data)
    }
  } catch {
    // Invalid JSON — ignore the stored draft
  }
}

This gives the data from localStorage two validation layers: first, we ensure it is valid JSON; then Zod checks its structure and values before it is allowed back into the form.

#3. Form Validation

The same Zod schemas can be integrated directly with popular form libraries.

For example, React Hook Form provides a Zod resolver:

const form = useForm({
  resolver: zodResolver(Product_Schema),
})

As a result, rules such as:

description: z.string().min(5).max(500)

do not need to be described again in the form.

The schema that defines the API contract and TypeScript type also defines the form validation rules.

#4. Using Schema Constraints in the UI

A Zod schema contains not only information about the field type, but also its rules:

description: z.string().min(5).max(500)

If the UI displays a character counter:

127 / 500

there is no reason to hardcode 500 separately inside the React component.

We can get it directly from the schema:

const maxLength = Product_Schema.shape.description.maxLength

and use that value directly in the UI:

<CharacterCounter
  current={description.length}
  max={maxLength}
/>

This means 500 exists in exactly one place — Product_Schema.

Form validation, runtime validation, and the UI all use the same rule.

#5. Third-Party Service Integration

But why are we talking only about the classic frontend ↔ backend integration?

Let us look at this framework from another angle.

Suppose your application integrates with a third-party API. Your code directly depends on the responses returned by an external service, but you have neither a direct communication channel with its team nor any guarantee that you will receive timely notifications about API changes.

In this scenario, contract testing can become even more valuable.

Your tests effectively turn into an early-warning system: if the external service changes the response structure, removes a field, adds a new one, or changes its format, you can find out automatically — before that change turns into a problem for your users.

In other words, the same framework that helps reduce communication and integration issues in an internal frontend ↔ backend setup can, in the case of a third-party API, partially compensate for the complete absence of that communication.

#6. AI Compatibility

I put a lot of effort into standardization, structural consistency, and semantics while designing this framework.

And this is where we get to reap the benefits.

The more predictable the repository architecture is, the easier it is for AI to understand its patterns and extend them correctly.

If the framework is implemented consistently, AI no longer has to decide every time where to create files, how to name schemas, how to group endpoints, or how to structure contract tests.

The repository already contains a pattern that the agent only needs to recognize and reproduce.

In practice, this means that when a new API module appears, I can simply give the AI a link to the Swagger specification.

From there, it can parse the API specification, identify business entities and endpoints, and generate the module according to the existing structure: schemas, types, abstractions, and contract tests.

And yes, this has been tested in practice.

Implementing a new API module with around 10 endpoints, including testing, takes about 16 minutes.

So standardization here improves more than developer experience.

It makes the repository genuinely AI-native: instead of repeatedly explaining to an agent how another module should be implemented, we give it an architecture where the correct implementation pattern is already encoded in the structure and semantics of the code.

Conclusion

A few numbers.

While working with a large API containing more than 100 endpoints, this framework allowed me to reduce structural integration bugs to almost zero, cut the reaction time to API changes to within a single day, and catch around 100 integration issues in just three months — without requiring additional communication with the backend team.

I consider that a fairly strong result.

At this point, the framework solves one of the classic problems of software development quite well: the constant need to stay synchronized with API changes and detect situations where the actual contract starts diverging from what the application expects.

Overall, I am happy with the result.

The framework solves all the core problems I originally designed it for, requires relatively little additional code, and provides significantly more value than API validation alone.

I would be very interested to hear your thoughts.

Do you use anything similar in your projects?

Where do you think this approach works well — and where do you think it starts to break down?

I Tested Two AI Context Architectures: Context Discovery vs Prompt Engine. Here’s What I Learned.

Mykola Mizhigurskiy — Tue, 11 Aug 2026 18:51:23 +0000

For the last few months, I have been building my own AI framework for software development. It contains instructions for different engineering activities: implementing features, refactoring, writing tests, debugging, working with APIs, reviewing code, and many smaller tasks. As the framework grew beyond 100,000 characters of instructions, one problem became increasingly important: how do I give an AI agent exactly the instructions it needs without loading the entire framework into its context?

While working on this problem, I ended up testing two different architectures: Agent-Driven Context Discovery and a Prompt Engine with Context Compilation. Both allow you to keep instructions modular and load only what is relevant to the current task. The major difference is who is responsible for assembling that context.

Agent-Driven Context Discovery leaves this responsibility to the agent. You give it an entry point, usually a base instruction file, and that file references other instructions. The agent reads those files, follows their references, and gradually discovers the context required for the task.

Prompt Engine with Context Compilation moves most of this work into deterministic code. The agent still selects the type of activity it is about to perform, but once that decision is made, the Prompt Engine deterministically resolves the required instructions and compiles them into a ready-to-use context. The agent no longer has to manually discover and retrieve every instruction.

Shared Foundation: Intent Router / Playbook

Both architectures still need a mechanism that connects a task with the appropriate instructions. I call mine a playbook.

The playbook is essentially an intent router. It describes the types of activities the framework supports and maps those activities to the instruction sets they require. Implementing functionality, refactoring code, writing tests, debugging, and reviewing code are examples of activities that can have different instruction dependencies.

With Context Discovery, this routing can live inside the instruction graph itself. The base instruction tells the agent where to go, and the agent follows the appropriate path.

With my Prompt Engine, I use an MCP tool called getInstructions. It accepts typed activities and uses them to programmatically determine which instructions should be compiled. The agent therefore makes one high-level decision — what am I about to do? — while deterministic code handles the low-level question — which exact instructions does that activity require?

Approach 1: Agent-Driven Context Discovery

This was the first architecture I implemented. I split my framework into many small instruction files and created references between them. The agent received a base instruction as its entry point and was expected to follow those references whenever additional instructions were required.

Conceptually, it looked something like this:

Task → Base Instructions → Agent → Referenced Instructions → More Instructions → Work

I liked this approach initially because it was extremely easy to build. The instruction system remained modular, individual files could be reused, and adding a new rule usually meant adding or updating a reference. There was no separate infrastructure responsible for assembling prompts because the agent itself effectively acted as the resolver.

After using this architecture for some time, however, I started noticing several problems.

Problem 1: Reasoning Overhead

Every time the agent encounters a reference, it has to understand why that instruction exists, decide whether it should follow it, retrieve the file, process it, and potentially repeat the process. These are small decisions, but they are still decisions made by the model instead of deterministic operations performed by software.

I increasingly disliked spending the agent's reasoning capacity on this kind of plumbing. I want the model thinking about architecture, requirements, edge cases, and implementation decisions. Resolving an instruction dependency does not require intelligence if I can already express that dependency in code.

Problem 2: Reliability

I repeatedly saw agents skip files even when another instruction explicitly told them to read those files. It did not happen every time, but it happened often enough that I could not consider instruction delivery deterministic.

This creates an unpleasant failure mode. Your agent may produce perfectly reasonable code while silently missing one of the rules it was supposed to follow. The problem is not that the model misunderstood an instruction — it never loaded that instruction in the first place.

Problem 3: Tool Usage

Reading each instruction file requires a tool call. With more than 100,000 characters distributed across many files, the agent could make a surprising number of calls just to prepare itself for the actual task.

I repeatedly hit Copilot’s maximum tool-call limit while the agent was navigating instruction files. When that happened, Copilot stopped before the actual task was completed. That was a strong signal that I needed a different architecture.

Problem 4: Inefficient Context Usage

Another problem is that routing instructions remain in the agent's context long after they have served their purpose. Instructions such as "read this file," "for this activity, also read that file," or "if this condition applies, load these additional instructions" are useful during context discovery, but provide little value once the agent starts working on the actual task. From that point on, they simply consume space in the context window.

This problem also has the potential to grow over time. If the agent occasionally fails to load the right files for certain activities, the natural response is to make the routing instructions more explicit: add explanations, introduce more specific terminology, describe additional conditions, or repeat important references. That may improve routing reliability, but it also increases the amount of temporary information that remains in the context throughout the task.

In other words, the more effort you put into making agent-driven context discovery reliable, the more context you may end up spending on instructions that become useless immediately after discovery is complete.

Approach 2: Prompt Engine with Context Compilation

My second implementation moved instruction resolution out of the agent and into code.

The framework still contains dozens of small, reusable instruction files. The difference is that the agent no longer needs to navigate them one by one. A script resolves the dependencies, collects the required files, and returns the complete instruction set in a single operation.

The architecture now looks closer to this:

Task → Activity → Prompt Engine → Compiled Context → Agent → Work

The change may sound small, but the practical improvement was substantial. Once the agent selects an activity, the rest of the process is deterministic. If activity X requires instructions A, B, C, and D, the Prompt Engine delivers all four. There is no intermediate step where the agent can forget to open C or decide that D is unnecessary.

Context delivery also became much faster. Instead of making a sequence of tool calls, reading files one by one, and reasoning about what to retrieve next, the agent makes a single request. The Prompt Engine resolves the instruction graph programmatically and returns the compiled context in a single operation. This removes both the latency of repeated tool calls and the reasoning overhead involved in navigating the instruction structure.

Another important improvement was eliminating a practical limitation I repeatedly hit with Copilot: the maximum number of tool calls available to the agent. With Context Discovery, the agent regularly exhausted this limit while navigating and reading instruction files, which caused Copilot to stop before the task was completed. After moving instruction resolution into the Prompt Engine, instruction delivery requires only one tool call, so this failure mode effectively disappeared from my workflow.

In practice, I got three immediate benefits: the required instructions started reaching the context reliably, context assembly became much faster, and instruction discovery stopped consuming the agent's limited tool calls. Combined, these changes produced a very noticeable improvement in the overall speed and reliability of my workflow.

Problem 1: Your Prompt Engine Becomes a Mini-Product

The first downside is additional infrastructure. In my case, the Prompt Engine requires a custom MCP server that exposes the tools the agent uses to request its instructions. Once you introduce this layer, you effectively have another small software product living inside your repository.

Like any other software, it needs maintenance. You need to keep the implementation clean, handle edge cases, and ideally cover its critical behavior with automated tests. As the instruction system evolves, the Prompt Engine has to evolve with it.

This is simply the price of moving from a lightweight instruction structure to a more sophisticated architecture. You gain more deterministic and reliable context delivery, but you also introduce another component that you are responsible for maintaining.

Problem 2: You Can Accidentally Create Two Sources of Truth

Another challenge is instruction representation. The format that is convenient for programmatic processing is not necessarily the format that is convenient for a human. For example, the Prompt Engine may work better with structured JSON, while I would much rather read, write, review, and maintain the same instructions as Markdown.

The obvious solution is to keep both representations, but that immediately creates another problem: they can drift apart. If JSON says one thing and Markdown says another, you effectively have two sources of truth and can no longer be certain which representation describes the actual behavior of the system.

A better architecture needs one canonical source and a deterministic way to generate the other representation from it. Ideally, the two formats should also remain structurally similar enough that you can debug the agent-facing JSON while reading the human-friendly Markdown. Otherwise, the convenience of having two representations can quickly turn into another maintenance problem.

Problem 3: Compiled Instructions Can Pollute the Context

A Prompt Engine can also make context usage worse if the routing rules are not strict enough. Imagine that the current session already contains the instructions for API engineering, but the agent does not clearly understand that those instructions should not be requested again. It may call the instruction tool a second time and inject another full copy of the same compiled context into the conversation.

If your instruction sets are large, this can become surprisingly expensive. Instead of optimizing context usage, you may end up filling the context window with repeated copies of the same material. The more often the agent re-requests instructions, the faster this duplication compounds.

My recommendation is to add a hard guardrail at the infrastructure level.

Track which instruction sets have already been delivered during the current session, and if the agent requests the same one again, do not return the full instruction set.

Return a short message saying that the instruction is already present in the current context and should be reused.

I also make this failure mode explicit. If the agent believes the required instruction is actually missing despite the guardrail, it should treat that as a critical inconsistency, stop, and report the problem to the user rather than silently requesting or reconstructing the same context again.

This is one of those cases where a small deterministic safeguard can prevent a large amount of unnecessary context duplication.

Note: There Is Still One Non-Deterministic Step

This architecture does not make everything deterministic. The agent still needs to select the correct activity when it calls getInstructions, and that selection is an LLM decision.

For this reason, I think the tool interface should be strongly typed and the playbook should be designed carefully. Activity names and descriptions need to be clear enough that the model can reliably map real tasks to them. Otherwise, you simply move the failure point from instruction discovery to activity classification.

I would also recommend watching this routing closely when introducing such a system. Check which activities the agent selects for real tasks and adjust the playbook when you find ambiguous cases. In my framework, my subjective estimate is that incorrect activity selection happens in less than 1% of cases, possibly even below 0.5%, so this has not been a significant practical problem for me.

What I Learned

After working with both architectures, Prompt Engine with Context Compilation wins for me by a large margin.

The difference is not really about prompts or files. It is about deciding which responsibilities belong to an LLM and which belong to traditional software.

An LLM is excellent at understanding intent, interpreting ambiguous requirements, reasoning about code, and making decisions where the answer cannot be reduced to a simple algorithm. A script is excellent at following predefined dependencies, assembling files, validating inputs, and producing the same result every time.

Context Discovery asks the LLM to do some of both. A Prompt Engine lets me draw the boundary more deliberately.

The Core Takeaway: Whenever something can be reliably handled by deterministic software, move it out of the agent's reasoning loop.

That experiment eventually contributed to a broader principle I now use in my Semi-Automatic AI-Native Flow with a Human in the Loop.

For me, this is becoming one of the more interesting questions in AI-native development. We spend a lot of time asking how much more responsibility we can give to AI agents.

Maybe we should spend just as much time asking how much responsibility we can take away from them.

What edge cases did I miss here? How are you managing large instruction sets or context windows in your own AI frameworks? Let me know in the comments!

Microsoft GH-300: GitHub Copilot | Tips & Tricks

Mykola Mizhigurskiy — Mon, 10 Aug 2026 19:10:40 +0000

Today I passed the GitHub Copilot GH-300 exam and decided to write down my impressions right away while they are still fresh. First of all, this article is not so much a “how to pass” guide as a place where people who are currently preparing for the exam can ask questions to someone who literally took it today. If anything from my experience helps you prepare better, or at least understand what to expect, then this article has already served its purpose.

The gap between preparation materials and the actual exam questions

The first thing that genuinely surprised me was how different the information in the recommended preparation materials can be from what you actually see on the exam. A few times, my completely honest reaction was: “Where did this even come from?” Subjectively, I managed to answer some of those questions not because I had memorized the materials well, but because by the time I took the exam I had already been using Copilot quite intensively in real-world development. Sometimes practical experience helped, sometimes it was a general understanding of engineering processes, and sometimes it was simply common sense.

So I would not recommend treating the official materials as a complete map of the exam. They are useful and they provide the basic structure of the topics, but they are not enough to make you confident about every question. If you already use Copilot at work, that is a serious advantage, because part of the exam tests not only whether you know the wording from the documentation, but also whether you understand how the product behaves in common scenarios.

Copilot = Microsoft

Another thing worth keeping in mind: Copilot is GitHub, GitHub is Microsoft, and Microsoft also means Windows and PowerShell. If, like many developers, you have spent years working on macOS and barely touching the Windows ecosystem, some questions may come as an unpleasant surprise. For example, you may need at least a basic understanding of how something is installed or configured through PowerShell. I barely looked at things like that during my preparation because I relied too heavily on the recommended resources and hardly read any additional documentation. If I were preparing again, I would definitely close that gap.

Do questions from the preparation materials appear on the exam?

A separate story is my attempt to “outsmart the system.” During preparation, I collected all the questions I came across in the learning modules and the practice exam, put them into Anki, and simply memorized them. I thought it would be a decent safety net: even if the questions were not repeated word for word, at least I would have the relevant facts firmly memorized. In practice, my subjective impression is that I did not see a single question repeated exactly on the real exam, and only one or two vaguely resembled something I had learned this way. So I would not recommend memorizing the correct answers; it is much more useful to use those questions as a way to check whether you actually understand the topic.

Question formats

Another mistake in my expectations about the GH-300 was assuming that the exam would mostly follow the classic format: one question, four answers, one correct choice. In reality, there are more formats. Some questions require you to choose two correct answers out of four or three out of five, some ask you to match items between two columns, and some require you to arrange several steps in the correct order. Personally, I found the last type to be one of the trickiest because it is no longer enough to “roughly remember the correct answer” — you need to understand the process itself.

Statistically, you can feel the difference too. In a standard multiple-choice question with four options, you at least have a 25% chance of guessing correctly if you know absolutely nothing. But when you need to choose several items from a set and then put them in the correct order, the number of possible combinations grows very quickly. That is why I would pay particular attention to how GitHub Copilot handles basic workflows: authentication, starting a new session, resuming a previous one, working with context, and common interaction scenarios. It is important not only to know that a feature exists, but to understand what happens step by step.

A final gift :)

And finally, here is a small semi-joking life hack that I came up with for myself while preparing. Use this entirely at your own risk.

If you are looking at a question where you have absolutely no idea which answer is correct and you are going to guess anyway, take a closer look at the longest option. In the practice materials, I repeatedly noticed a pattern: the correct answer is often written in a complete, careful way with all the necessary qualifications, while the incorrect options sometimes look as if, after writing the correct one, the author got a little tired of coming up with alternatives.

If you don’t know which answer to choose, choose the longest one.

I do not know how consistently this works on the real exam, and I definitely would not recommend using it as a substitute for knowledge. But if you are already in a situation where you have to guess anyway, at least you will have some kind of heuristic. I saw this pattern often enough in the practice questions to notice it.

If I had to start preparing again today, I would spend less time memorizing ready-made answers and more time on three things:

actually working with Copilot
reading additional documentation
understanding the product workflow.

The learning path and the demo exam are useful, but I would treat them as a map of the topics rather than a simulation of the actual exam.

So,

if you are preparing for the GH-300 right now, leave your questions in the comments.

While my impressions are still as fresh as possible, I will try to answer everything I can.

Chasing Tokens: I Renamed My Entire Repository — Here’s What Happened

Mykola Mizhigurskiy — Mon, 10 Aug 2026 15:11:14 +0000

After optimizing my CI logs for AI agents, I found myself looking for tokens everywhere.

Then I had another idea.

Many of my files and directories used kebab-case.

My assumption was simple: if - increases token count, then switching everything to camelCase might reduce the amount of context an AI agent has to process.

So instead of guessing, I measured it.

I wrote a script to tokenize my entire repository before and after renaming every kebab-case path to camelCase.

Repository before: 376,553 tokens
Repository after: 376,204 tokens

Total reduction: 349 tokens.

Honestly? That was much smaller than I expected.

At first glance, this looks like a classic micro-optimization. But I don't think the story ends there.

Why File Paths Matter More Than You Think

Unlike source code, file and directory names have a very different lifecycle during an AI coding session.

An agent doesn't read them just once. They appear repeatedly in:

imports and exports
directory listings
search results
git diffs
stack traces
test output
formatter and linter logs
tool responses from the IDE

In other words, file paths are part of the agent's working context over and over again.

So while the repository itself became only 349 tokens smaller, the cumulative savings across a long coding session could be noticeably larger because those same paths are processed repeatedly.

I haven't measured that part yet, so I won't claim any specific numbers.

Conclusion

This experiment reminded me of something more important:

Measure first. Optimize second.

Some optimizations that sound brilliant turn out to be negligible. Others—like reducing unnecessary tool output—have a much larger impact than you'd expect.

AI-assisted development is creating a whole new class of performance optimizations. The only way to know which ones matter is to measure them.

What micro-optimizations have you tested for your AI coding agents? Did they actually move the needle, or did the data surprise you? Let me know in the comments!

💥 Easy way to save your AI coding agent a surprising amount of context.

Mykola Mizhigurskiy — Mon, 10 Aug 2026 15:07:28 +0000

One thing clicked for me only after working with AI agents for a while.

Like many teams, I have a set of mandatory checks that must pass before code is committed:

Prettier
ESLint
Type checking
Unit tests

I also have a rule for my coding agent: whenever it makes executable code changes, it automatically runs all of these checks before moving on.

Sounds obvious, right?

The problem was that all of these tools were configured for humans, not for AI.
For example:

Prettier printed every file it checked - even when nothing changed.
The type checker produced verbose success output.
The test runner listed every executed test file.
ESLint printed a lot of informational output even when everything passed.

Then it hit me:

Every line of that output becomes part of the agent's working context.
Those hundreds of log lines aren't free. They consume context, increase token usage, and make it harder for the model to focus on information that actually matters.

Fixing the Noise

So I changed the defaults:

Prettier runs silently unless there's a formatting issue.
ESLint only reports warnings and errors.
Tests use a dot reporter and print detailed output only for failures.
Successful checks produce only a short summary.

The result?

Exactly the same safety guarantees, but with dramatically less noise.

For humans, verbose logs are mostly harmless. For AI agents, they're context pollution.

And context isn't free. Every unnecessary token is one that could have been spent reasoning about your code instead.

Sometimes the best optimization isn't a faster model—it's simply giving the model less irrelevant information to read.

Appendix: For those who prefer numbers over opinions

I rolled the repository back and measured the raw output with a tokenizer:

Prettier output: ~15,000 tokens
Test runner output: ~35,000 tokens

After enabling silent output and compact reporting:

Prettier: ~500 tokens
Test runner: ~1,500 tokens

That is roughly 48,000 tokens removed from a single validation cycle—without removing a single check or weakening the pipeline.

Same guarantees. Far less context pollution.

What configuration tweaks have you made to keep your AI coding agents focused? Let me know in the comments!

AI Melting Your Brain? Here’s the Fix.

Mykola Mizhigurskiy — Mon, 10 Aug 2026 15:03:18 +0000

A few weeks ago, I came across a post from a developer who had spent six months working with five or six Claude Code terminals open at once. His description of the experience was funny, but also uncomfortably familiar: most of the time, he was simply waiting for agents to finish and pressing Enter.

His conclusion was blunt: “Claude Code is melting my brain.”

I’ve been seeing variations of this concern more and more often. Developers who use AI heavily start wondering whether they are becoming less sharp because the machine is doing too much of the actual coding. At the same time, another term has started appearing in discussions around AI-assisted development: comprehension debt.

I think that term captures the problem remarkably well.

Technical debt appears when a codebase accumulates decisions that will have to be dealt with later. Comprehension debt appears when the codebase evolves faster than the people responsible for it can maintain a mental model of what is happening inside it. The software keeps moving forward, but your understanding of it falls further and further behind.

Eventually, you can end up in a strange position: you are responsible for a system that you technically own, but no longer fully understand.

These look like two different problems:

AI making developers “dumber”
AI creating comprehension debt

... but I suspect they are mostly the same problem viewed from two angles. And, more importantly, I think they have the same solution.

The problem is not AI. The problem is you going full auto.

There is a peculiar productivity competition happening in software engineering right now. Every week I see another impressive number: hundreds of thousands of lines generated, thousands of commits, dozens of agents running in parallel, or thousands of pull requests produced by AI-assisted development pipelines.

Uber, for example, has publicly discussed an internal AI coding system producing roughly 1,800 pull requests per week (1 PR each 80 seconds).

That is certainly an impressive throughput number. But whenever I see metrics like this, I find myself asking a slightly uncomfortable question:

What exactly are we optimizing?

A pull request is a unit of software delivery. It is not a unit of product value.

A software product is, at some level, encoded business logic. Its purpose is to solve problems: make something easier for a user, automate a process, reduce costs, create revenue, satisfy a regulatory requirement, improve reliability, or enable some new capability.

So the interesting question is not how quickly an organization can manufacture changes to a repository. The interesting question is how quickly it can discover, validate and deliver meaningful changes to the product.

Imagine someone tells you that their AI workflow can generate a thousand PRs in a relatively short period of time. Fine. Now ask them a different question: can you name the next important feature your product needs—right now?

And I don’t mean something sitting in the backlog already. I mean a genuinely new requirement. Something that has been validated rather than hallucinated by AI. Something supported by customer feedback, user behavior, business analysis, stakeholder needs, market research or other evidence that suggests building it will actually create value.

That is much harder. And definitely not possible at the rate of 1 feature per 80 seconds.

The reason is simple: once implementation becomes extremely fast, implementation stops being the primary bottleneck. Product discovery does not suddenly become a hundred times faster because your coding agent did. Neither do requirements analysis, UX research, architectural reasoning, stakeholder alignment or understanding what customers actually need.

At some point, enough is enough.

There is a finite amount of meaningful change that a product can discover, validate, absorb and maintain. Once AI gives us effectively abundant implementation capacity, maximizing the amount of code produced becomes a strange goal in itself.

And this is where I think full-auto development becomes dangerous. Not necessarily because AI writes bad code, but because execution can begin moving faster than understanding.

That is where comprehension debt starts accumulating.

My approach: Semi-Automatic AI-Native Development

The workflow I use has a deliberately cumbersome name: Semi-Automatic AI-Native Development with Human in the Loop.

I described the broader workflow in another article, so I won’t repeat the whole thing here. The important part for this discussion is the human in the loop.

I almost never use AI in full-auto mode for meaningful development work. I use it aggressively, but I try to be very deliberate about which part of engineering I delegate.

For me, AI is an extremely fast electronic typewriter, an implementation engine, a research assistant, a second opinion and a tool for validating assumptions. What I do not want it to become is a replacement for engineering judgment.

Before I ask an agent to implement something, I try to define the system it is going to operate inside as precisely as the task justifies. Depending on the feature, that means thinking through types, validation rules, business requirements, functional behavior, file structure, data flow, relationships between modules, API contracts, architectural boundaries and test expectations.

And one thing I care about particularly strongly is semantics.

What does this entity actually represent? Who owns this state? Where does this transformation belong? What responsibility does this module have? What does this abstraction mean in terms of the domain? Which concepts are genuinely different, and which are merely different names for the same thing?

Those questions are not formatting preferences. They are architecture.

Once those constraints are clear, AI can do what it is extraordinarily good at: execute quickly inside them.

Recently I came across a post from Robert "Uncle Bob" Martin that described a surprisingly similar philosophy.

His approach is more extreme than mine. He says he does not read the code generated by his agents; instead, he surrounds those agents with extensive constraints: unit tests, Gherkin tests, QA procedures, quality metrics, mutation testing, coverage and many other forms of automated verification.

I do still read AI-generated code. But the underlying idea resonates with me: the engineer’s job increasingly becomes designing the environment in which automated implementation is allowed to happen.

You create the constraints. You define the architecture. You specify the semantics. Then you let the machine move quickly inside that system.

Why I still review the code

When people argue that developers should review AI-generated code, the usual explanation is safety: AI can hallucinate, misunderstand a requirement, introduce a security problem or simply produce incorrect code.

All of that is true. But for me, there is another reason that is at least as important.

The generated code is feedback on the architecture I designed.

Before implementation begins, an architecture is partly a hypothesis. I believe these responsibilities belong in these modules. I believe this abstraction is sufficiently general. I believe this data flow is clean. I believe this type model represents the domain correctly. I believe these boundaries will continue to make sense when the next requirement arrives.

Then the AI implements the feature at high speed, and that hypothesis collides with reality.

Perhaps the abstraction turns out to be awkward. Perhaps data starts leaking across boundaries that were supposed to be clean. Perhaps a type requires exceptions everywhere. Perhaps two concepts that looked independent are much more tightly coupled than expected. Perhaps the agent repeatedly struggles with one particular part of the design.

Those are not merely implementation problems. They are signals.

When I review the result, I am not only checking whether the agent wrote acceptable code. I am checking whether my model of the system survived implementation.

That creates an extraordinarily powerful learning loop.

AI can make you learn faster, not slower

This is the part of AI-assisted development that I think gets far less attention than it deserves.

Without AI, much of a developer’s working day is consumed by execution. You design something, then spend hours or days typing it into existence. You write boilerplate. You perform repetitive refactorings. You search through documentation. You implement the twentieth variation of a pattern you already understand.

AI can compress a huge percentage of that execution time.

If you keep yourself inside the reasoning loop, the time you save does not have to disappear. It can be reinvested into the parts of software engineering where the real intellectual work happens: architecture, modeling, semantics, constraints, trade-offs and validation.

My workflow increasingly looks like this:

Design → constrain → let AI execute → inspect the result → learn → adjust the design.

Then another requirement arrives and the loop starts again.

The interesting part is the speed. Suppose I design an architectural approach and implementing enough of it to discover its weaknesses would traditionally take several weeks. With an agent, I may get that feedback in hours. Sometimes much faster.

That means AI does not merely accelerate implementation. Used this way, it accelerates the architecture-feedback loop.

You make a design decision. Reality tests it almost immediately. You learn. Then you make another design decision.

Do that repeatedly and something interesting happens: instead of spending most of your time exercising your ability to type code, you spend much more of it exercising your ability to design systems.

That is almost the opposite of “AI melting your brain.”

It is closer to deliberate practice for software architecture, with an implementation engine attached.

Of course, this only works if you actually stay in the loop. If you delegate the decisions, delegate the implementation, accept the output and move directly to the next prompt, the mechanism reverses. AI keeps learning about your codebase while you gradually stop doing so.

That is comprehension debt.

I probably won’t generate 1,800 PRs a week. That’s fine.

A semi-automatic workflow with deliberate human involvement is obviously slower than telling a swarm of agents to modify a repository as quickly as possible.

That does not bother me.

I want to produce exactly as much code as meaningful product development requires. If AI makes me capable of implementing useful changes faster than a product organization can discover and validate those changes, I have already won. More implementation throughput beyond that point has rapidly diminishing value.

The objective of software engineering is not to maximize the amount of software produced. It is to solve useful problems with software.

AI gives us an extraordinary opportunity to remove a large amount of mechanical work from that process. I think the mistake would be to remove ourselves from the intellectual work at the same time.

So yes, review the code. It may contain bugs. It may contain security issues. It may misunderstand your requirements. Those are all perfectly good reasons.

But review it for another reason too.

Review it because it tells you whether your architecture was right.
Review it because it forces you to maintain a mental model of the system you are responsible for.
Review it because every implementation is an experiment, and every experiment gives you feedback.

And if AI can run those experiments dramatically faster than before, perhaps the technology that supposedly makes developers stop thinking can—used correctly—make us learn faster than we ever could before.

There is one line from Uncle Bob’s recent posts that summarizes the responsibility better than anything I could add:

That is the point.

You are not the engineer because you typed every line of code. You are not the engineer because you can explain every keystroke that created the repository. And you are certainly not the engineer because your AI generated more pull requests than somebody else’s.

You are the engineer because you are accountable for the system that comes out the other side.

What do you think?

How are you managing the balance between AI speed and system comprehension in your codebase? Do you use a human-in-the-loop workflow, or have you experimented with full-auto agents? Let me know in the comments below!

Stop asking AI to do a linter’s job.

Mykola Mizhigurskiy — Mon, 10 Aug 2026 14:56:28 +0000

I have developed a workflow that I call:

A semi-automated, AI-native development flow with a human in the loop.

It may sound like a collection of AI buzzwords, but each part represents a very practical principle.

1. Semi-automated

If a task can be performed reliably by a simple script, it should not be delegated to AI.

Want consistently formatted code? Configure Prettier.
Want custom naming conventions, import restrictions, or architectural constraints? Configure ESLint or write a custom rule.
Want consistent formatting across different editors? Add an EditorConfig file.

Do not make AI spend context and reasoning capacity checking indentation, semicolons, or naming conventions. Deterministic problems should have deterministic solutions.

Here is a less obvious example.

I have written several thousand unit tests for my current project. As a perfectionist and former QA engineer, I care about how elements are selected in tests.

Whenever possible, tests should use accessible selectors first, such as roles and accessible names. A test ID should only be used as a fallback.

Initially, I treated this as something AI should remember, while I would catch mistakes during code review.

But I noticed that I was correcting the same issue far too often.

So I asked myself:

Why am I repeatedly reviewing something that can be checked automatically?
I wrote a custom lint rule.

A few lines of code solved the problem permanently.

Now the linter knows the required selector priority and reports violations automatically.

The best part is that AI fixes these issues in virtually every case.

Why?

Because running the project’s validation procedures is mandatory in my workflow. Even when AI makes a mistake, it runs the linter, receives a precise error message, and corrects the code.

That is what “semi-automated” means to me:

AI handles tasks that require reasoning.
Scripts handle tasks that require consistency.

2. AI-native

A repository can be structured primarily for human convenience, or it can be structured so that both humans and AI can navigate it efficiently.

An AI-native repository treats context as a limited engineering resource.

Some developers are familiar with code golf: solving a problem using the fewest possible characters.

AI-native development is not exactly code golf, but the underlying constraint is similar:

Every token has a cost.

This does not mean compressing the code until it becomes unreadable. It means finding a balance between readability, consistency, and context efficiency.

Project standardization plays a major role here.

One component should not use a completely different structure, style, or paradigm from another component without a good reason.

Reusable abstractions should be clearly defined and used consistently.

This allows AI to find an existing implementation, understand it as the project standard, and use it as a reliable reference.

Another important principle is what I call context segregation.

A feature should be divided into meaningful files so that AI can load only the context required for the current task.

For example, a test implementation may have:

the test file itself
fixtures
mocks
setup utilities

Sometimes the setup is larger than the actual test suite.

When I only need AI to inspect test names or understand what behavior is covered, there is no reason to feed the entire setup into its context.

I use colocated suffix files for this purpose. A larger feature can have several supporting files placed next to it, with clear suffixes describing their roles.

Depending on the task, I can provide AI with exactly the files it needs—and nothing else.

And please, use barrel exports where they make architectural sense.

There is no reason to repeatedly feed AI long absolute import paths when a stable public module API can expose the same components with fewer tokens and less coupling.

3. Human in the loop

The internet currently seems obsessed with fully autonomous pipelines where an agent writes code around the clock without human participation.

Maybe I am old-fashioned, but I am highly skeptical of that approach.

I could list many examples of what AI misunderstands, what must be reviewed, and where autonomous implementations fail.

But there is one issue that matters more than all the others:

If you remove yourself from the process, you stop LEARNING.

You are no longer collecting feedback.
You are no longer examining what AI understands and what it misunderstands.
You do not see which instructions work, which create confusion, where AI is fast, where it struggles, or where an additional tool could eliminate an entire category of mistakes.

Most importantly, you lose the data required to improve your own development framework.

Here is my favorite example.

At one point, I created what I believed was the perfect AI development process.

I reviewed every instruction repeatedly. I refined every detail. I was convinced that the framework was exceptionally well designed.

Then I used it in production.

Within two months, the process went through five generations of fundamental changes—not counting dozens of smaller improvements.

Why?

Because real-world usage generated feedback.

I observed what failed, what created unnecessary work, what AI interpreted incorrectly, and what could be automated more effectively.

No matter how good your prompt, instruction set, agent configuration, or MCP setup appears, you do not have objective evidence that it works until you observe it under real production conditions.

That is why my workflow keeps a human in the loop.

Not merely to approve AI-generated code.

But to learn from every iteration and continuously improve the system producing that code.

A New AI Paradigm: The Billion-Dollar Blind Spot

Mykola Mizhigurskiy — Wed, 21 May 2025 11:55:36 +0000

A New AI Paradigm: The Billion-Dollar Blind Spot

Modern AI systems are excellent at detecting toxicity, abuse, radicalization.

But there's a blind spot — and it's costing us billions:

They can't detect brilliance.

Every day, millions of users interact with AI. Among them,

1 in 10,000 may hold a breakthrough idea.
1 in 100,000 may be modeling the future of society, science, or intelligence.

But all of that signal vanishes.

No system is designed to surface it.

Enter SVITLO

SVITLO (Signal of Visionary Ideas Through Latent Observation) is a protocol that proposes a new direction:

➡️ Not just detecting threats

➡️ But detecting insight

➡️ Surface-level agnostic, cognition-focused

It doesn't require new infrastructure.

It builds on existing analytics pipelines and reorients them from defense to discovery.

What if your model could say:

“This interaction shows signs of exceptional thought. Would you like to be seen?”

Use Cases

Identifying overlooked talent
Spotting founder-level thinkers
Building archives of visionary insight
Enhancing alignment, recruitment, and impact

📖 Full manifesto on GitHub:

🔗 SVITLO manifest

Feedback, forks, and discussion welcome.