Artificial intelligence has quickly become an indispensable part of modern software development. Today, it's perfectly normal to ask an AI assistant to generate boilerplate code, explain an unfamiliar framework, suggest a refactoring strategy, or write unit tests. What felt experimental just two years ago has become part of many developers' daily workflow.
Yet there's an interesting contradiction.
The more experienced the development team and the larger the project, the more cautious developers tend to be about relying on AI.
While coding assistants can produce impressive results in a clean demo or a greenfield application, they often struggle once they're dropped into an enterprise codebase that has evolved over many years. Suddenly, the same AI that built a prototype in minutes starts suggesting architectural shortcuts, forgetting decisions made earlier in the conversation, or modifying parts of the system it shouldn't touch.
Why does that happen?
According to Uladzislau Kavalenka, .NET Developer, the answer has less to do with the capabilities of today's language models and more to do with how we use them. During an internal LeverX masterclass on AI-assisted development, he explored an idea that is becoming increasingly relevant across the industry: the future isn't about writing increasingly sophisticated prompts. It's about engineering the entire workflow around AI.
That shift from prompt engineering to context engineering is changing how experienced software engineers approach AI.
When generative AI first entered software development, prompt engineering became something of a superpower. Developers experimented with different prompt templates, assigned the model specific roles, and discovered techniques that produced noticeably better code. Entire communities emerged around sharing prompts, and every new model release seemed to bring another round of advice on how to "talk" to AI more effectively.
Those techniques still matter. A well-structured request will almost always outperform a vague one.
But after the initial excitement settled, many engineering teams ran into the same limitation: no matter how carefully a prompt was written, AI still lacked the context needed to make consistently good decisions.
Imagine joining a new project on your first day. You're asked to add a feature to a payment module that has been evolving for five years. Before writing any code, you'd probably spend hours reading documentation, understanding the architecture, exploring the repository, and asking teammates why certain design decisions were made. Only after building that mental model would you feel comfortable implementing a change.
An AI assistant starts every conversation in exactly that same position – but with one major disadvantage. It has no institutional knowledge unless developers deliberately provide it.
This is where context engineering comes into play. Rather than asking, "How can I write a better prompt?", context engineering asks a different question: How can I create an environment where AI always has access to the information it actually needs?
That subtle change in perspective has profound implications. Instead of treating AI as a clever autocomplete tool, developers begin designing systems that supply architecture, documentation, coding standards, project conventions, and historical decisions exactly when they're needed. With this approach, the goal is to reduce the amount of guessing AI has to do.
One principle remains true regardless of which AI model or coding assistant you use: garbage in, garbage out. The quality of an AI's output is directly tied to the quality of the context it receives.
The difference between experimenting with AI on a personal project and using it in a mature enterprise application often becomes obvious after just a few tasks.
Suppose you ask an AI assistant to modify part of a payment system.
The model doesn't immediately know where the relevant business logic lives, so it starts exploring the repository. It opens controllers, services, utility classes, configuration files, helper methods, interfaces, and database models, gradually trying to understand how everything fits together. Some of those files are highly relevant, but many are not.
The problem is that every file consumes part of the model's available context.
Eventually, the context window fills up.
To keep working, the AI begins compressing earlier information. Details from the beginning of the conversation become less precise. Architectural constraints disappear. Sometimes the assistant even reopens files it has already analyzed because it no longer "remembers" reading them.
Most developers have encountered this situation without necessarily knowing why it happens. The AI suddenly feels inconsistent. It proposes solutions that contradict earlier decisions or forgets requirements that seemed perfectly clear just a few minutes before. This isn't necessarily a flaw in the model but rather a natural consequence of working with limited context.
Ironically, many developers respond by writing even longer prompts. Unfortunately, that often makes the problem worse. Longer prompts consume even more context, leaving less room for the codebase itself.
The answer? Provide better structured information.
One of the most practical recommendations from the masterclass challenged a common assumption about AI adoption.
Many teams begin by creating one enormous instruction file containing everything the model should know about the project: coding conventions, architecture, naming standards, testing requirements, deployment procedures, business rules, technology choices, and countless project-specific notes.
Initially, this seems logical. If AI has more information, surely it will make better decisions. In reality, the opposite often happens.
Oversized instruction files become encyclopedias that the model must process before every task. Valuable context is spent reading documentation that may have little relevance to the work at hand. Rather than reducing ambiguity, these documents often introduce additional noise.
A more sustainable approach is to think of the main instruction file – whether it's called AGENTS.md, CLAUDE.md, or something similar – not as a knowledge base but as a router.
Instead of storing every project detail in one place, it simply tells the AI where to find the right information. Frontend standards live in one specification. Backend architecture in another. Database conventions have their own document. Testing guidelines are loaded only when tests are required.
| Category | File Path | What is Inside | When to Read (Trigger) |
| Frontend & UI | .specs/frontend-rules.md | Rules for React/Angular components, TypeScript strictness, state management, and communicating with the .NET Web API. | IF the task involves creating client-side pages, UI components, frontend routing, or modifying styles. |
| Backend & API | .specs/backend-rules.md | ASP.NET Core Web API conventions, Dependency Injection setup, Middleware pipeline, MediatR/CQRS patterns, and C# coding standards. | IF you are creating new API controllers/ endpoints, writing business logic, or modifying background services. |
| Data Access | specs/database-rules.md | Entity Framework Core configurations, LINQ query optimization, migration rules, Repository pattern constraints, and SQL Server conventions. | IF you are modifying database entities, adding EF Core migrations, writing LINQ queries, or configuring DbContext. |
| Testing | .specs/testing-rules.md | xUnit test structure (Arrange-Act-Assert), mocking with Moq/NSubstitute, FluentAssertions, and `WebApplicationFactory` for integration tests. | IF the user asks to "cover code with tests," "write a test," or if you need to verify an API endpoint's behavior. |
Ironically, this mirrors the way experienced engineers work. Senior developers don't memorize every architectural decision across a large application. They know where to find the information they need, when they need it. Organizing project knowledge in the same way helps AI navigate the codebase more efficiently while significantly reducing unnecessary context.
AI is changing not only how we write code but also how we think about documentation.
For years, developers have debated how much documentation a project should contain. Too little makes onboarding difficult. Too much becomes impossible to maintain. AI introduces another dimension to that discussion.
Documentation is no longer written exclusively for humans. Increasingly, it's becoming part of the interface between developers and AI systems. However, that doesn't mean documenting every implementation detail – we’d argue for the opposite.
Modern language models are already surprisingly good at understanding code. Copying implementation logic into markdown files often creates more problems than it solves. As the code evolves, documentation falls behind, gradually losing credibility until both developers and AI stop trusting it.
Instead, documentation should focus on something the source code cannot explain on its own: why.
Those are the kinds of decisions that help both people and AI understand a system.
Maintaining that documentation requires discipline. Whenever an architectural decision changes, the corresponding documentation should evolve alongside it. Otherwise, even the best AI assistant may confidently follow outdated guidance.
One of the biggest differences between an experienced developer and a freshly initialized AI model is memory.
Engineers naturally accumulate lessons over time. After solving the same problem twice, they rarely repeat the same mistake. Most AI assistants, however, forget everything as soon as a conversation ends. That's where concepts like memory banks and feedback loops become valuable.
Rather than treating every interaction as completely independent, teams can preserve important knowledge between sessions. Architectural decisions, recurring pitfalls, preferred implementation patterns, and lessons learned during previous tasks become part of the project's collective memory.
When a new task begins, the AI can consult that knowledge before generating code.
This doesn't mean storing every detail indefinitely. Quite the opposite. Effective memory should remain concise and focused on high-level decisions rather than implementation details.
Another practical technique discussed during the masterclass involves creating session summaries for long-running tasks. As conversations become larger, AI inevitably loses some context. Instead of continuing indefinitely, developers can periodically summarize the current state, review the summary manually, and begin a fresh conversation using that condensed context.
The workflow feels surprisingly similar to how engineering teams already operate. Long projects are broken into milestones, decisions are documented, knowledge is shared, and AI simply becomes another participant in that process.
Perhaps the most significant mindset shift discussed during the internal LeverX session concerns the role of prompts themselves.
Many developers still think of AI as something that responds to instructions. Increasingly, however, experienced teams are thinking in terms of workflows.
Consider the seemingly routine task of adding a new API endpoint. An experienced engineer knows this rarely involves just writing a controller. Depending on the project, the work might also include updating the database schema, applying validation rules, modifying service layers, implementing authorization, generating integration tests, and verifying that the feature behaves correctly.
Rather than describing this sequence every time, developers can encapsulate the entire process into a reusable skill.
The next time someone asks the AI to create an endpoint, the workflow is already defined. The model knows which project documentation to consult, which standards to follow, and which verification steps must happen before the work is considered complete.
This approach fundamentally changes the developer's role. Instead of repeatedly explaining the same engineering process, they design it once and allow AI to execute it consistently.
It's the difference between giving directions every day and building a well-signposted road.
Context is only one part of the equation. Sometimes an AI assistant also needs access to information that exists outside the repository. For example, project requirements might live in Jira. Technical documentation may be stored in Confluence. User interface designs could be maintained in Figma. Logs may need to be retrieved from monitoring systems.
Technologies such as the Model Context Protocol (MCP) make these integrations possible by allowing AI agents to interact with external tools as part of their workflow. Instead of asking developers to manually collect information from multiple systems, the agent can retrieve the relevant context directly.
Of course, additional capabilities also introduce additional responsibility. Connecting every available tool isn't necessarily the right answer. Each integration increases the amount of information AI must process and expands the potential surface for mistakes.
The principle remains the same: provide exactly the context the task requires, and no more.
Toward the end of the masterclass, Uladzislau introduced another concept that has started gaining traction across the AI community: harness engineering. The idea is refreshingly simple.
The quality of AI-assisted development depends less on which model you subscribe to and more on the engineering system surrounding that model. That system includes specifications, documentation, memory, reusable workflows, testing, validation, automation, and project architecture.
In other words, the competitive advantage is not AI on its own but the environment you've built around it.
This perspective also explains why two teams using the same coding assistant can achieve dramatically different results. One team treats AI as a chatbot. The other treats it as a carefully integrated part of its engineering process.
Every major technological shift has changed what software engineers spend their time doing. For example, high-level programming languages reduced the amount of machine code they needed to write. Frameworks automated repetitive tasks while making architecture even more important.
AI appears to be following the same trajectory. As coding assistants become more capable, the value of simply producing code continues to decrease. At the same time, the importance of designing systems, documenting decisions, structuring knowledge, and building reliable engineering processes continues to grow.
Ironically, AI is making software engineering less about typing code and more about engineering itself.
Developers who understand architecture, decomposition, testing, documentation, and system design are increasingly the ones who can get the most out of AI because they know how software should be built in the first place.
The AI landscape is evolving at an extraordinary pace. New models, tools, and frameworks appear almost every month, making it tempting to focus on whatever has just been released. Yet the most valuable lessons from the LeverX masterclass weren't about any particular model or coding assistant. They were about engineering principles:
Those ideas existed long before AI entered software development, and they remain just as relevant today. The difference is that they’re now helping AI become a more reliable engineering partner as well.
At LeverX, conversations like this are a regular part of engineering life. Internal masterclasses give specialists an opportunity to share practical experience, challenge established approaches, and explore how emerging technologies are reshaping software development. By sharing these insights beyond our own teams, we hope to contribute to the wider conversation about building software that is not only faster, but also better.