DEV Community: Nick

Part 6: Engine Internals - The Execution Pipeline

Nick — Mon, 15 Jun 2026 08:01:00 +0000

We have seen how you design a workflow and how the domain model keeps it strictly type-safe. Today, we are peeling back the most complex layer of Vyshyvanka: The Execution Pipeline. This is where the graph you drew in the browser becomes a series of actual operations executing on the server.

From Graph to Execution

When you hit 'Run', the engine doesn't just start running nodes randomly. It first performs a topological sort on your directed graph using BuildExecutionLevels. This groups nodes into execution levels - nodes at the same level have no dependencies on each other and can run in parallel, while each level depends only on previous levels.

If Node B needs the output of Node A, the topological sort guarantees Node A finishes first. If there's a circular dependency in your graph, our validator catches it before it ever hits the engine.

The Life Cycle of an Execution

Every run is an immutable record that transitions through a strict state machine:

Pending ──→ Running ──→ Completed
  │            │
  │            ├──→ Failed
  │            │
  └──→ Cancelled ←──┘

Pending: The trigger has fired, and we have initialized the execution context.
Running: We start processing the sorted levels of nodes.
Terminal States: Once a workflow hits Completed, Failed, or Cancelled, that's it. No further transitions allowed.

We don't allow mutable state transitions back from a terminal state. This ensures that every execution record is an audit-ready snapshot that you can trust.

The Pipeline at Work

The pipeline itself is fully asynchronous. We leverage .NET's async/await throughout the entire chain, passing a CancellationToken into every method. If a user cancels a workflow or the server initiates a graceful shutdown, every single node in the pipeline receives that signal and halts immediately.

Here is a simplified view of the core execution loop:

public async Task<ExecutionResult> ExecuteAsync(
    Workflow workflow,
    IExecutionContext context,
    CancellationToken cancellationToken = default)
{
    var executionLevels = BuildExecutionLevels(workflow);
    var maxParallelism = GetEffectiveMaxParallelism(workflow.Settings.MaxDegreeOfParallelism);

    foreach (var level in executionLevels)
    {
        cancellationToken.ThrowIfCancellationRequested();

        var levelResults = await ExecuteLevelWithThrottlingAsync(
            workflow, level, context, nodeResults, maxParallelism, cancellationToken);

        // Check StopOnFirstError policy
        if (workflow.Settings.ErrorHandling == ErrorHandlingMode.StopOnFirstError)
        {
            var failedResult = levelResults.FirstOrDefault(r => !r.Success);
            if (failedResult is not null) return BuildResult(/* ... */);
        }
    }
    // ...
}

Inside the pipeline, each node goes through several stages:

Input Gathering: We collect outputs from upstream nodes via connection mapping. Multi-input nodes receive a merged JSON object keyed by target port name.
Expression Evaluation: All {{ nodes.someNode.data }} expressions in the node configuration are resolved in real-time from the execution context before the node runs.
Node Execution: We invoke ExecuteAsync on the node instance. Since all nodes inherit from our base classes (BaseTriggerNode, BaseActionNode, BaseLogicNode), the engine handles them uniformly regardless of what they actually do.
Output Storage: Successful node outputs are stored in the context, ready for downstream nodes to reference.

Parallel Branch Execution

Nodes at the same execution level run in parallel, throttled by a SemaphoreSlim:

private async Task<NodeExecutionResult[]> ExecuteLevelWithThrottlingAsync(
    Workflow workflow, List<string> level, IExecutionContext context,
    ConcurrentBag<NodeExecutionResult> nodeResults, int maxParallelism,
    CancellationToken cancellationToken)
{
    using var semaphore = new SemaphoreSlim(maxParallelism, maxParallelism);

    var tasks = level.Select(async nodeId =>
    {
        await semaphore.WaitAsync(cancellationToken);
        try { return await ExecuteNodeInWorkflowAsync(workflow, nodeId, context, nodeResults, cancellationToken); }
        finally { semaphore.Release(); }
    }).ToList();

    return await Task.WhenAll(tasks);
}

The default max parallelism is Environment.ProcessorCount * 2, but you can configure it per workflow.

Handling Failure

What happens when a node fails? The engine supports two error handling modes:

StopOnFirstError: Stops the entire workflow immediately when any node fails.
ContinueOnError: Marks the failed node and continues executing independent branches. Dependent nodes on the failed branch are skipped.

Because we have that immutable execution record, you can see exactly which node caused the issue, what data it received, and the error message — all structured in the NodeExecutionResult list.

Plugin Node Isolation

Plugin nodes (from external assemblies) are executed through IPluginHost.ExecuteNodeInIsolationAsync, which adds an additional timeout layer:

private async Task<NodeOutput> ExecuteNodeInstanceAsync(
    INode nodeInstance, NodeInput input, IExecutionContext context, TimeSpan timeout)
{
    if (_pluginHost is not null && _pluginHost.IsPluginNode(nodeInstance.Type))
        return await _pluginHost.ExecuteNodeInIsolationAsync(nodeInstance, input, context, timeout);

    return await nodeInstance.ExecuteAsync(input, context);
}

This ensures that a misbehaving plugin cannot hang the entire engine.

Why Asynchronous?

We chose async-first because workflow engines are inherently I/O bound. You are constantly waiting for databases, external APIs, and file systems. By using async/await everywhere, we ensure that while one workflow waits for a response, the thread is returned to the pool to serve other workflows. This is how a single engine instance can manage hundreds of concurrent executions without thread pool starvation.

In the next part, we will discuss Part 7: Expression Language Syntax - How dynamic data flows between your nodes. Stay tuned!

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

Part 5: Designing the Designer - Building a Blazor WASM Experience

Nick — Fri, 12 Jun 2026 08:00:00 +0000

In our last deep dive, we talked about the logic and data structures that drive Vyshyvanka. But software isn't just about clean backends; it's about how the user interacts with those systems. Today, we're stepping into the browser to talk about the Vyshyvanka Designer - our Blazor WebAssembly canvas.

Why Blazor WebAssembly?

When we decided to build a visual workflow designer, we had a few options: React, Vue, or maybe a native desktop app. We chose Blazor WebAssembly for a few critical reasons:

Shared Logic: By staying within the .NET ecosystem, we can share domain models and validation logic between our Engine and the Designer. When we update a node definition in the Core, the Designer understands those changes instantly without rewriting types in TypeScript.
Performance: Blazor WASM gives us the performance of a compiled language inside the browser, which is crucial when you're dragging and dropping dozens of nodes or panning around a large workflow.
Developer Velocity: Our team works best in C#. Having a single language for both our ASP.NET Core API and our frontend allows us to move fast without the context switching of a JavaScript-heavy stack.

The Designer Architecture

The Designer isn't one big component; it's a system of decomposed services designed to keep the UI snappy and maintainable:

WorkflowStore: The single source of truth. It holds your workflow data, node definitions, and the 'dirty' flag that tells the UI when you have unsaved changes.
WorkflowEditService: This is the brains of the operation. Whenever you drag a node, add a connection, or delete a step, the EditService handles the business logic. It doesn't worry about rendering; it just worries about state.
WorkflowValidationService: We run validation in the browser as you edit. If you try to connect an 'Object' output to a 'Boolean' input, the UI turns red before you even let go of your mouse.
CanvasStateService: Handles the 'feel' of the application. Panning, zooming, node selection, and undo/redo stacks are managed here.

Communicating with the Engine

We made a hard architectural choice early on: The Designer communicates exclusively via HTTP.

There are no direct WebSocket connections or shared memory paths to the Engine. By forcing all interaction through the WorkflowApiClient, we ensure the Designer remains a pure client. This means we can treat the entire Designer as a standalone application that could be hosted anywhere. It doesn't care if the engine is running on your machine, in a Docker container, or in the cloud—as long as it can hit the API, it works.

Component Design Rules

To keep our UI code clean, we enforce strict rules:

No @code blocks in .razor files: All logic lives in Name.razor.cs partial classes.
Injection over @inject: We use [Inject] attributes in our code-behind to keep the markup clean and the dependencies explicit.
One Component, Three Files: Every visual piece follows a Name.razor, Name.razor.cs, and Name.razor.css pattern. It keeps our styles isolated and our logic readable.

The Goal: Real-Time Clarity

The goal of the Designer isn't just to look good; it's to provide real-time clarity. You should know exactly what your workflow is doing at every moment. By integrating our validation service directly into the canvas, we turn the design phase into an active conversation between you and the system.

Building a visual editor in Blazor was an adventure, but the results—a type-safe, performant, and deeply integrated experience—made it all worth it.

In the next part, we'll look at the execution engine internals: The Pipeline. We'll explain how we resolve the graph, manage node execution order, and handle the state machine from 'Pending' to 'Completed'. Stay tuned!

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

Part 4: The Domain Model - Understanding Workflows, Nodes, and Connections

Nick — Thu, 11 Jun 2026 08:00:00 +0000

In our last deep dive, we looked at how Vyshyvanka is put together under the hood. Today, we're zooming in on what actually makes the engine tick: the Domain Model. At the end of the day, Vyshyvanka isn't just a collection of services; it's a system designed to manage a directed graph of operations that we call a Workflow.

The Workflow: A Directed Graph

At its heart, a workflow is a directed graph where nodes represent operations and connections represent the flow of data.

Exactly One Trigger: Every workflow needs a starting point. Whether it's a webhook, a timer, or a manual button press, we enforce that there is exactly one trigger node.
Ownership: Every workflow is owned by a single user, ensuring that permissions and access are managed consistently across the board.

Nodes: The Atomic Operations

Nodes are the building blocks of your automation. We categorize them based on their behavior, which dictates their base class in our engine:

Trigger Nodes: These start the workflow. They have no incoming connections because they define the entry point. Examples include our WebhookTrigger or ScheduleTrigger.
Action Nodes: These do the actual work. Think of them as your worker bees - sending an email, querying a database, or calling an external HTTP API.
Logic Nodes: These are the brains. They allow you to branch execution (If/Switch), create loops, or merge data streams.

When you implement a new node in Vyshyvanka, you simply inherit from the appropriate base class, override the ExecuteAsync method, and register it in the NodeRegistry. The engine takes care of the rest.

Connections and Type Safety

One of the most common sources of bugs in automation platforms is passing incompatible data between steps. We fixed that with a robust Port Type system.

A connection is valid if:

The source port type equals the target port type.
Either port is an 'Any' type, which acts as a wildcard.

Our supported types include Object, Array, String, Number, and Boolean. By enforcing this at the designer level, we ensure that by the time a workflow hits the engine, it's guaranteed to be syntactically and logically sound.

Execution: The Immutable Record

When a workflow runs, we create an Execution record. This is an immutable snapshot of that specific run. Why immutable? Because transparency matters. Once an execution is marked as 'Completed', 'Failed', or 'Cancelled', it is final. You can trace back exactly what data was passed to each node, what the result was, and how the state machine transitioned.

This transition logic is rigid:
Pending -> Running -> (Completed | Failed | Cancelled)

Terminal states are final, and that is a promise the engine keeps. This prevents any accidental state mutations or 'zombie' executions that haunt other automation systems.

Validation Rules

Before a workflow can even be executed, it must pass a battery of checks:

No circular dependencies.
Every node must be reachable from the trigger.
Required properties must be set.
All connections must satisfy port compatibility.

This pre-execution validation means that when you hit 'Run', you can be confident that the workflow isn't going to fail because of a simple wiring mistake.

Why This Matters

By building a strict, type-safe domain model, we've turned what is usually a fragile scripting process into a robust software engineering task. You aren't just "writing a script"; you are defining a formal model that the system understands and can verify.

In the next part, we'll look at the front end of this equation: The Designer. We'll explain how we built a Blazor WebAssembly canvas that allows you to drag, drop, and wire up these nodes in real time. Stay tuned!

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

Part 3: Architecture Deep-Dive - A Modular Approach with .NET 10

Nick — Wed, 10 Jun 2026 08:00:00 +0000

In the last part, we talked about why we built Vyshyvanka. Today, we're going to talk about how. Software architecture is often the difference between a project that scales and one that becomes a tangled web of technical debt after six months. For Vyshyvanka, we knew from day one that modularity wasn't an option - it was a requirement.

The Dependency Rule

If there's one rule we follow, it's the Dependency Rule: Dependencies flow strictly downward.

Vyshyvanka.Core is our heartbeat. It's pure C#, containing only domain models, interfaces, and contracts. It has zero dependencies on anything else. This makes our core logic incredibly easy to test and reason about - if it compiles, it's logically sound.
Vyshyvanka.Engine depends only on Core. It's where the magic happens: execution pipelines, persistence, and auth.
Vyshyvanka.Api and Vyshyvanka.Designer sit at the top. They consume Core and Engine to provide the REST endpoints and the interactive Blazor WebAssembly UI, respectively.

By ensuring our core domain logic doesn't know the API or UI even exist, we've created a system where we can swap out a UI framework or change how an API handles serialization without touching the workflow engine itself.

The Modular Structure

Here is how we organized the solution to keep things clean:

src/Vyshyvanka.Core/: Domain layer. This is where our entities, interfaces, and enums live. If you want to know what a 'Node' or a 'Workflow' looks like at its simplest level, this is where you go.
src/Vyshyvanka.Engine/: This is the engine room. It houses the execution logic, persistence strategies (EF Core), and the plugin loading subsystem. It's robust, tested, and entirely infrastructure-agnostic.
src/Vyshyvanka.Api/: Our ASP.NET Core REST API. It handles authorization, request/response DTOs, and middleware. It acts as the gatekeeper, ensuring that every request is valid and authenticated before hitting the engine.
src/Vyshyvanka.Designer/: Our Blazor WebAssembly frontend. This is a complete SPA. It communicates with the backend exclusively through HTTP, keeping it decoupled from the engine's internal state.

Why This Matters for You

Why go through the effort of splitting a project into 6+ distinct projects?

Testability: Because Core and Engine are so decoupled, we can write unit tests that execute complex workflows in milliseconds, without spinning up an API or a database.
Parallel Development: A team could theoretically work on the UI components and the plugin engine at the same time without fighting over file changes.
Resilience: If the API layer has a bug in its serialization logic, it's contained to the API. It can't accidentally corrupt your workflow engine state.

Keeping it Clean

We use Directory.Packages.props to manage dependencies across the entire solution, which prevents version drift and keeps our build times fast. Furthermore, we enforce these boundaries with code reviews and clear documentation in our structure.md.

Building a workflow engine is complex, but keeping the architecture simple is the key to maintaining it. By forcing dependencies downward, we've built a foundation that allows us to add new integrations, new triggers, and new logic nodes without ever fearing that we're breaking the core system.

In the next part, we'll look at the Domain Model - the actual building blocks of every workflow you'll ever create in Vyshyvanka. We'll break down what makes a Node a Node, and how we handle connections that span different execution states. Stay tuned!

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

Part 2: The Core Philosophy - Why Build Another Workflow Engine?

Nick — Tue, 09 Jun 2026 08:00:00 +0000

We live in a golden age of automation. From Zapier to n8n, there are incredible tools out there to help us glue our services together. So, why on earth am I building another one?

It comes down to a few things: control, performance, and the .NET ecosystem.

The SaaS Bottleneck

Most automation platforms are built as black-box SaaS products. They're fantastic for quick wins, but as you scale, you hit a wall. You lose visibility into how the engine processes your workflows, you're stuck with the vendor's plugin release cycle, and you're often limited by their infrastructure constraints. When your workflow fails, you're stuck looking at a generic "Execution Failed" log without being able to step into the code to see why.

The .NET Advantage

Vyshyvanka is different. It's built for the .NET 10 developer who wants to own the entire stack. By building on modern .NET, we get access to features that other platforms struggle to match:

Performance: .NET 10 brings incredible improvements in throughput and memory management. Vyshyvanka uses this to handle thousands of concurrent workflow executions without breaking a sweat.
Type Safety: Workflow inputs and outputs are statically typed. No more guessing what the output of a "DatabaseQuery" node looks like—it's a C# object, fully documented by the compiler.
Tooling: We're leveraging the .NET ecosystem's world-class tooling. You can write your custom nodes in your favorite IDE (Rider, VS Code, VS), run unit tests on them using xUnit, and deploy them with standard CI/CD pipelines.

Why Vyshyvanka?

This isn't about reinventing the wheel - it's about giving developers a steering wheel they can actually modify.

Own the Stack: Run the engine inside your own infrastructure. You control the data, the security, and the scaling. No more worrying about data egress fees or black-box limitations.
Customize Deeply: Need a custom integration? You don't need to wait for a vendor to support it. Just write a new node class in C# and drop it into the plugin folder. It's registered, validated, and ready to go instantly.
The Developer Experience (DX): We've prioritized the developer experience. From source-generated serializers to bUnit testing for Blazor components, every part of Vyshyvanka is built to make building workflows feel like building a standard .NET application.

This is a platform for people who care about how their systems work and want the power of modern software engineering at their fingertips.

In the next part, we'll dive deep into our modular architecture and explain how we structured the project to ensure that everything remains maintainable as it grows. Stay tuned!

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

Part 1: Introduction to Vyshyvanka - Workflow Automation for the Modern .NET Era

Nick — Mon, 08 Jun 2026 08:00:00 +0000

Hey friends! If you 've spent any time working in the .NET ecosystem, you know the feeling: you've got a dozen different background tasks, scheduled jobs, and webhook listeners, each living in their own silo. Managing them all gets messy fast.

That's why I'm excited to introduce you to Vyshyvanka.

Vyshyvanka is a workflow automation platform built from the ground up for .NET 10. Instead of writing boilerplate code every time you need to connect two services, you build workflows visually in our Blazor WebAssembly designer. Then, the engine handles the execution, state management, and persistence for you.

In this 15-part series, we're going to pull back the curtain on the entire architecture, from the execution engine internals to our plugin system that lets you build custom nodes for whatever infrastructure you're running.

Whether you're a developer looking to streamline your internal tools or an enthusiast wanting to see how a modern .NET platform is constructed, there's something here for you.

Let's get building!

Treat Your AI Agent Is a Mid-Level Developer With Amnesia

Nick — Fri, 05 Jun 2026 07:00:00 +0000

In the previous articles, I argued that AI is just the next abstraction layer, and that the key skill it demands is clear technical communication — the same skill that makes great tech leads and architects. But that’s still abstract. Let me make it concrete.

Because here’s the thing: we already have a well-established workflow for communicating technical intent to other humans. And AI agent workflows are not just similar to it — they’re a direct mirror.

This Is Not a Coincidence

We, humans, do not do this because of AI. We designed AI so it can understand our usual steps. The agent workflow mirrors the human team workflow because that’s what we trained it on. That’s what we optimized it for.

Let me show you what I mean.

The Human Team Workflow

How do we actually do things in a position of, say, a Tech Lead or Team Lead? Let’s trace the typical workflow:

Step 1: Grooming a business request. Who is involved? Product owner, a lead (tech lead or team lead), probably a developer who will be designated to implement this thing or a knowledge keeper for specific functionality. Those people basically create a design document without implementation specifics — a high-level description of what needs to be done and why.

Step 2: Technical decomposition. The lead and a developer break the design into technical tasks — what components to change, what APIs to create, what data models to adjust.

Step 3: Task scheduling. A project manager organizes the work into sprints, sets priorities, estimates timelines.

Step 4: Code review. After development iterations, another developer or the lead examines changes. At this point, the examiner does not implement anything directly — they only look at the final result and evaluate it. Is it good? What needs to be changed? Does it match the original intent?

The AI Agent Workflow

Now look at how modern AI coding tools work:

Step 1: Design document. You describe what you want — the context, the goal, the constraints. This is your “grooming” phase. You’re the product owner and the tech lead in one person.

Step 2: Planning/decomposition. The AI (or you, together with AI) breaks the task into steps — what files to change, what to create, in what order.

Step 3: Execution. The AI works through the plan, implementing step by step.

Step 4: Review. You look at the result. You don’t implement — you evaluate. Does it match your intent? What needs to change?

Same workflow. Same roles. Same sequence. The only difference is that steps 2 and 3 are now done by an AI instead of a human developer.

The Amnesia Problem

But there’s one critical difference between a human teammate and an AI agent: memory.

A human developer on your team remembers your project. They know the architecture. They remember that weird edge case from three months ago. They know that “the payments service” actually means two services because of that legacy split nobody documented.

An AI agent knows nothing. Every conversation starts from zero. It’s a competent developer — but one with complete amnesia about your specific project.

This changes everything about how you should communicate with it:

They’re competent but don’t remember your project specifics
They need clear context for each task
They can do great work if you explain what you want precisely
They will make assumptions if you leave gaps — and those assumptions might be wrong

The RAG Trap

So here’s where many teams go wrong. They think: “If the problem is amnesia, let’s give it all the memory. RAG, vector databases, persistent context, the entire codebase indexed and searchable.”

And yes — it helps. But it has the same drawbacks as increasing the context window: more information means more potential confusion. Greater knowledge — greater sorrow.

You can give an AI agent access to your entire codebase, all your documentation, all your Jira tickets. But if your prompt is vague and poorly structured — it will hallucinate confidently in ten different directions. More context without better communication is just more noise.

Think about it from the human analogy. If you dump a 500-page wiki on a new developer and say “figure it out” — they won’t. They’ll drown. But if you give them a clear task description, point them to the three relevant files, and explain the constraints — they’ll deliver.

Same with AI.

The Practical Framework

Here’s what actually works. Start treating your AI interactions like you’re onboarding a new team member for every task:

Context first. Before the task, provide the relevant context. Not everything — just what’s needed. Architecture of the specific component. The relevant data models. The constraints that aren’t obvious from the code.
Clear intent. State what you want to achieve, not just what you want to change. “Add a retry mechanism to the payment service because transactions sometimes fail due to network timeouts, and we need at most 3 retries with exponential backoff” is infinitely better than “add retries to payments.”
Constraints explicitly. What should it NOT do? What patterns should it follow? What’s the testing strategy? Don’t assume the AI will infer these from context — it might, but it might not.
Review like a tech lead. When you review the output, don’t just check if it works. Check if it matches your intent. Check if it follows your patterns. Check if it handles the edge cases you care about. This is exactly what you’d do in a code review with a human developer.

Store the Repeating, Vary the Specific

One more practical tip. Start storing common things in markdown files — steering files, documentation, architecture decisions. That way you retain only repeating information as persistent context, and variables — the specifics of each task — will be added as you explain your current goal.

This is not different from onboarding a new team member. You give them docs, you give them context, and then you give them a task. The better your docs and the clearer your task description — the better the result.

The things that don’t change between tasks — your coding standards, your architecture patterns, your testing philosophy — those go into persistent documentation. The things that are unique to each task — the specific requirement, the specific constraints, the specific acceptance criteria — those you communicate fresh each time.

The Developer of the Future

In the end, I want to emphasize this: developers of the future will need not only knowledge of how to develop, but also a skill in explaining what exactly they want from an AI agent.

The irony is beautiful. We spent decades building abstraction layers to avoid explaining things to machines in their language. And now the machines finally learned our language. The developers who will thrive are not the ones who memorize every API — they’re the ones who can explain what they need as clearly as a good tech lead explains a task to their team.

This way you really unlock the full potential of AI agent as a tool in your hands. Not by fighting it. Not by fearing it. By talking to it the way you’d talk to a skilled colleague who just joined your team today.

The Bosses Are Coding Again. Here’s Why That Should Worry You

Nick — Thu, 04 Jun 2026 07:00:00 +0000

In my previous article, I argued that AI is just the next abstraction layer — the same pattern we’ve seen a dozen times in software history. Each layer demands a new skill. So what does the AI layer demand?

I think the answer is hiding in plain sight. And some very powerful people just demonstrated it.

Something Interesting Happened Recently

Mark Zuckerberg started coding again after a 20-year break. According to multiple reports, he moved his desk to Meta’s AI lab, spends 5 to 10 hours a week writing code, and is “coding all day long” alongside the Meta Superintelligence Labs team. The man who built Facebook in a dorm room and then spent two decades managing tens of thousands of people — is shipping diffs again.

Garry Tan, CEO of Y Combinator, returned to coding after 15 years using AI tools like Claude Code. He described himself as “addicted” to it, sleeping four hours a night because he couldn’t stop building things.

Sergey Brin, Google’s co-founder who stepped back from day-to-day operations years ago, came out of retirement to code on Gemini. He’s reportedly assembling an elite “coding strike team” and is directly involved in hands-on development.

And there’s a quote from The New Stack that captures this perfectly: executives are building with AI because they were “tired of explaining it to somebody who was supposed to build it for me.”

Why is this happening? These people haven’t written production code in over a decade. What changed?

The Career Ladder Was Always About Communication

Let’s take a step back. The most common career paths for a developer are either the strict technical way — from developer to tech lead, then architect — or the management way — team lead, then head of engineering, CTO.

In both ways you start from doing things yourself and gradually move to teaching — or better to say, guiding — others how to do it. Or strictly overseeing the whole process. You stop writing code and start writing explanations. You stop implementing and start reviewing. You stop building and start describing what needs to be built.

A senior architect doesn’t write code. They write ADRs, design documents, system diagrams. They explain to teams what to build and why. A CTO doesn’t push commits. They articulate technical vision so clearly that hundreds of engineers can execute on it independently.

The higher you go — the more your job becomes pure communication of technical intent.

Sound familiar?

My Theory: The Explanation Bottleneck Is Gone

My theory is simple. People who know how to explain to others what and how they exactly want to do — can now skip the extra step of explanation and do things directly. Faster. Without the telephone game of requirements passing through three layers of interpretation.

Think about it. A CTO who spent years learning to articulate technical vision clearly, who mastered the art of describing systems and behaviors — that person now has a tool that actually understands those descriptions and turns them into working code. The skill they developed for managing people turned out to be the exact skill needed for managing AI.

The bottleneck was never their inability to code. It was the cost of translating their vision through other people. AI removed that cost.

That’s why Zuckerberg is coding again. Not because he suddenly remembered C++ syntax. But because he spent 20 years perfecting the skill of explaining what he wants — and now there’s a tool that listens.

Why This Should Concern Mid-Level Developers

Here’s the uncomfortable part. If the key skill for working with AI is the ability to articulate technical intent clearly and precisely — then the people who are best at it are not junior developers. They’re not even senior developers who spent their careers heads-down in code.

They’re the people who spent years learning to communicate technical ideas to other humans. Tech leads. Architects. Engineering managers. The people who already climbed the ladder.

This doesn’t mean mid-level developers are doomed. It means the skill you need to develop is not “learn more frameworks” or “memorize more APIs.” It’s the skill of clear technical communication. The ability to describe what you want, why you want it, what constraints exist, and what “done” looks like.

This is not “prompt engineering” as some buzzword. This is the same skill that makes great tech leads, great architects, great CTOs — the ability to articulate technical intent clearly and precisely.

The Skill That Compounds

Here’s the good news. Unlike memorizing API signatures or framework quirks — communication skill compounds. It doesn’t deprecate with the next major version release. It doesn’t become obsolete when a new framework appears.

A developer who can clearly explain a system’s architecture, articulate trade-offs, and describe desired behavior precisely — that developer will be effective with whatever AI tool comes next. Because the tools will only get better at understanding us. The bottleneck will always be our ability to express what we mean.

What This Means Practically

If you’re a developer reading this and thinking “okay, but what do I actually do?” — I have a concrete answer for that. In the next article, I’ll break down exactly how AI agent workflows mirror the workflows we already use in human teams, and how you can leverage that understanding to work with AI dramatically more effectively.

Spoiler: if you’ve ever written a good Jira ticket, you’re already halfway there.

AI Is Not Killing Developers. It’s Doing What We Always Did to Ourselves

Nick — Wed, 03 Jun 2026 16:31:26 +0000

AI is considered as a threat for developers. Not existential — nobody thinks Skynet is coming for your VS Code. But as a “tool” that makes developers less knowledgeable about the tricks of software development. Less aware of how this or that function works under the hood. Less capable of choosing the right approach in a particular case.

And honestly? I’ve heard this song before.

We’ve Been Here Before. Many Times.

If you look at the path of programming languages evolution — you’ll see the same pattern repeating over and over. We moved from writing raw machine code to assembler. From assembler to procedural programming. From procedural to OOP. Then came additional layers of abstraction — frameworks, libraries, package managers. Each layer made the previous one less visible, less understood by the average developer.

And now so few people can debug real assembler code. And what? Is this a failure?

Really, I do not know how a for loop works on the assembler level — I’m a child of high abstraction level languages. Java, C#, Python — they really discourage you from knowing how it works under the hood. Just build and ship. Use good practices and you will be golden. Nobody asks you to understand memory allocation to write a REST API. Nobody expects you to know CPU pipeline optimization to build a mobile app.

The Pattern Is Always the Same

Every generation of developers lost something and gained something.

We lost the ability to write optimal assembler — we gained the ability to ship products in weeks instead of years. We lost manual memory management — we gained garbage collectors and the ability to focus on business logic. We lost hand-crafted SQL queries — we gained ORMs and the ability to switch databases without rewriting half the codebase.

Each time, the old guard said: “These new developers don’t understand the fundamentals.” Each time, the new generation built things the old guard couldn’t have imagined — because they weren’t spending their cognitive budget on problems that were already solved.

So What Did We Actually Lose?

Let’s be honest about what each abstraction layer took from us:

Assembler -> C: We lost fine-grained control over registers and memory layout. We gained portability and readability.

C -> Java/C#: We lost manual memory management and pointer arithmetic. We gained safety, productivity, and massive ecosystems.

Raw code -> Frameworks: We lost understanding of HTTP parsing, socket management, thread pools. We gained the ability to build a working web app in a day.

Manual deployment -> CI/CD: We lost the ritual of careful manual releases. We gained the ability to deploy 50 times a day with confidence.

Notice something? Each “loss” was actually a deliberate trade. We chose to forget things that were no longer worth remembering at the level of daily work. Not because they were unimportant — but because someone already solved them well enough.

AI Is Just the Next Row in This Table

AI is not doing anything new to us. It’s doing what we always did to ourselves — adding another abstraction layer. The difference is that this layer abstracts not just technical complexity, but the act of writing code itself.

And yes, that feels different. More personal. More threatening. Because previous abstractions still required you to type code — just at a higher level. AI sometimes removes even that step.

But the trade is the same: you lose something (the muscle memory of writing every line yourself), you gain something (the ability to build and iterate at a speed that was previously impossible for a single person).

The Question That Actually Matters

The question is not whether AI makes us “worse” developers. Every abstraction layer made us “worse” at the layer below. That’s the point.

The real question is: what new skill does this layer demand from us?

When we moved from assembler to C, the new skill was structured thinking and algorithm design. When we moved to OOP, it was system design and architecture. When frameworks arrived, it was choosing the right tool and understanding trade-offs.

What does the AI layer demand? I have a theory about that — but that’s a topic for the next article.

POCking AI

Nick — Tue, 25 Nov 2025 10:37:15 +0000

This article reflects my personal experience over 8 months of intensive AI-assisted development across multiple projects. Your mileage may vary, but the principles should translate across languages and frameworks.

I was presenting this topic at Moldova DevCon 2025 and i want to share the whole story.

This is my journey in pair software development with AI. This is not an advertisement or promo for any of products and any services i'm going to talk about. This is a personal opinion. I'll talk about some challenges and gains that i've encountered during these coding sessions.

Why I Started This Journey?

Eight months ago, I was that developer who rolled his eyes at AI coding tools. "Just fancy autocomplete," I thought. "Real developers don't need assistance." Basically, I didn't want to pay for stuff that I don't believe will be useful for me. Then we just decided to give it a try. We have PCI DSS certification, so we can't just go with any AI. We need something more or less self hosted. Nobody wants to support this kind of infrastructure, so we decided to give a go to Amazon Q Developer. At that time I had an overwhelming amount of reviews and more coming.

More out of desperation than curiosity, I installed an Amazon Q Developer. Not because I believed in it, but because I was running out of time and options. What happened next wasn't magical or revolutionary - it was just... as i expected. Reviews of changes without understanding of context or domain give no result. Almost all reviews was "Looks good for me". But the ability of AI assistant to use glab console tool to get changes and that assistant understand how to use it by it owh - was impressive at least. That brought me to research or better to say learn how to use it properly. Small things at first. The AI would suggest a method name that was better than what I was about to type. It would catch a null reference before I did. It would generate test cases I hadn't thought of.

But the real moment came when I get Kiro from Amazon into my hands. Spec flow approach made me excited as 8 year old on birthday. I would describe a problem, and the AI would suggest an approach. It would create a design document then I would refine the idea, and it would design technical documentation. We were actually having a conversation about code. Then, when everything looks fine - generate a step-by-step implementation list. That's when I knew something fundamental had changed in how software gets built.

This is not about AI replacing developers. This is about developers and AI working together in ways that make both more effective. And yes, there are pitfalls, frustrations, and moments when you want to throw your laptop out the window. But there are also moments of genuine partnership that I never expected to experience with code.

Fail Fast

Fail fast, also sometimes termed fail often or fail cheap, is a business management concept and theory of organizational psychology that argues businesses should encourage employees to use a trial-and-error process to quickly determine and assess the long-term viability of a product or strategy and move on, cutting losses rather than continuing to invest in a doomed approach. - Wikipedia.

This concept also known to developers. We try to quit from function execution as soon as result is obvious. At grooming or decomposition stage, when we just thinking how it should work and do not have practical experience, to estimate outcome of new architecture or functionality. Fail fast approach can help iterate quickly and test theories before we invest huge amount of time into it. At this point AI code assistants, especially agents with support of tools, can provide huge help.

Testing a theory that we have in our mind can be quick and dirty. We do not need a clean code or onion layered architecture to get the proof of concept. We need to have it working and we need it now.

Recently, I wanted to test if a new caching strategy would improve our API response times. Instead of spending days implementing a full solution, I asked the AI agent to create a quick prototype with cache integration. In 30 minutes, I had a working proof of concept that clearly showed the performance benefits. This validated the approach before committing to a full implementation.

The Fear Of A Blank Page

The fear of a blank page is a common experience for many writers and artists. This anxiety often stems from the pressure to create something perfect right from the start. It can lead to procrastination and self-doubt, making it difficult to begin any creative work.

I have one. I often thinks about new pet project and what i should do and then... i just do not want to write huge amount of code just to get started. This is especially true for web projects or some kind of API hosts. I need to configure logging the way i like, metrics, health checks, authorization and authentication etc. This process makes me already tired and i don't want to do it. I've tried to use some templates, but languages and frameworks changes so fast, that this approach is not viable for me either.

AI code agents can help overcome this fear or better to say, in my case, procrastination. They can create starter project with all i like and require faster. Meanwhile i'll keep thinking how i want tho do main logic of application.

What used to take me 2-3 hours of boilerplate setup now takes 15-20 minutes. The AI can scaffold a complete web project with structured logging, health checks endpoints, authentication setup, containerization configuration, and basic database operations. While the AI handles the infrastructure, I can focus on the business logic that actually matters.

What to Choose?

There is a few options right now. IDE integrated agents or separate console agents. In terms of what to choose - matter of taste. I've used both and i prefer IDE integrated, because i can see what they are doing and review code during generation. While AI generating one part of project - i can review another.

It's hard to find IDE that does not have AI integration of some kind.

My favorite is Amazon Kiro and VS Code Copilot. I have separate window with ongoing monolog of AI agent, a window with files showing diff to me. If i spotted that things goes wrong - i can stop process, correct my prompt and restart earlier.

I found that, it is a much better experience, if you use versioning tools with your project. First of all this gives you peace of mind when code generation running. You will not loose anything that was pushed to repo. Second, you can revert safely and fully then iterate again.

Always work with a clean git state before starting AI sessions. Commit your working changes first.

Context

This is fight between give as much as possible and receive what you expected. When you give all you have to LLM - it has to much of freedom and does not understand how to deliver what you want. This is usual problem between software developers and product owners and/or business owner. People can not understand each other and we think that our train of thoughts can be processed be LLM as we expecting. This not a case so far. Maybe in future we will get AGI and it will do even better that promt it has, but not now. Not yet. We still need to give some context and set some boundaries.

On my experience, big code base is too much for an agent for now. I can not get meaningful results from LLM on one of our monorepo project with 250K+ LOC, with custom nuget packages and dependencies. It's out of agent capabilities. But when i start a new project from scratch - i constantly get an acceptable results. Yes, i still have to polish it, but it is usable.

So, modern AI agents support rule sets to provide some constrains. This is very useful to keep DRY principle.

Context Strategy:

Small focused sessions: Work on one feature/component at a time
Clear boundaries: Define what files/folders the AI should focus on
Progressive disclosure: Start with high-level architecture, then drill down
Rule sets help: Use modern language features, follow established patterns, include documentation, use validation libraries, follow company naming conventions

When AI Gets It Wrong: Debugging Together

AI isn't perfect. It makes mistakes, especially with complex business logic, framework-specific edge cases, security considerations, and performance optimizations.

AI generated a database query that looked correct but had performance issues. It was fetching data in a loop instead of using proper joins, creating multiple database calls when one would suffice. After explaining the performance problem, AI corrected the approach to use a single optimized query with proper relationships included.

This is how i usually approach debugging with AI:

Describe the unexpected behavior clearly
Share error messages and stack traces
Explain the expected vs. actual behavior
Let AI propose solutions, then review together

And remember, AI does not learn new things. All changes that are made during debug session should be stored somewhere. It can be a separate md file that next time you need to add to context or much better way - update general documentation about project.

Code Quality and Maintainability

AI a very good at following rules, especially those related to code quality and maintainability. Specifying rules and guidelines helps AI generate code that is consistent, readable, and maintainable.

What AI does well:

Consistent naming conventions. Following naming conventions helps to improve code readability and maintainability and agents usually do this by themselves. They trained on large codebases and many projects follows same conventions.
Proper exception handling patterns. But sometimes they over-engineer solutions, leading to unnecessary complexity. Creating custom exception even if it's not necessary. This can lead to confusion and unnecessary complexity.
Comprehensive documentation. AI does great at writing documentation on existing code, especially if this code was written by AI during the same session.
Following established patterns in the codebase. If you provide examples how to do it, AI will follow them religiously. This is very useful if you have some specific preferences in file location, tests arrangement and other rules.

What needs human review:

Business logic correctness. This is an "Achilles' heel" of AI-generated code. While AI can generate code that follows patterns and conventions, it may not always understand the business logic correctly.
Security implications. Generated code may not always be secure. Some times it may be vulnerable to common attacks.
Performance considerations. Nova days many developers does not think about performance optimization. It's easier to add more memory and CPU resources than to optimize code. LLM's usually have a hard time with this also.
Architectural decisions. Decide when to use what pattern or how to structure dependencies is a very hard task for AI. It's better to let humans make these decisions.

Testing and AI: A Complex Relationship

AI excels at generating unit tests but struggles with integration testing nuances. Mocking classes and services is no brainer for AI, but integration testing requires understanding of the system's architecture and dependencies. AI can help with setting up mocks and stubs, but it's important to ensure that the tests cover all possible scenarios and edge cases.

Strengths:

Comprehensive test coverage for public methods
Edge case identification
Mock setup and teardown
Test data generation

AI generated test follows standard patterns with proper arrangement, action, and assertion phases. It includes validation for edge cases like invalid inputs and expected exception handling. The test structure is clean and follows naming conventions consistently.

Limitations:

Doesn't understand complex business workflows
Struggles with database integration tests
Can't validate UI behavior
integration tests are difficult for AI to generate

The Economics of AI Development

Let's talk about the elephant in the room: the cost. When you hear "AI," you might think of massive, expensive infrastructure projects. The reality of AI-assisted development is far more down-to-earth. For an individual developer or a small team, the monthly subscription for a top-tier AI assistant is often less than the cost of a few hours of a developer's time. When you factor in the productivity gains—less time spent on boilerplate, faster debugging, and quicker prototyping—the return on investment becomes obvious very quickly. It's not an extravagant expense; it's a force multiplier.

However, the real cost isn't always measured in money. The biggest concern, and a valid one, is data security. Sending your proprietary source code to a third-party server is a non-starter for any organization with serious security or compliance obligations, like the PCI DSS certification we have. This is where you need to be selective. You can't just use any free or consumer-grade tool. The solution is to opt for enterprise-grade services like GitHub Copilot for Business or Amazon Q Developer, which offer commitments around data privacy, ensuring your code isn't used for training their public models and is kept confidential. The cost is slightly higher, but it's the necessary price for secure and responsible AI adoption.

Team Dynamics: Introducing AI to Your Development Process

Bringing an AI assistant into a development team isn't just a technical change; it's a cultural one. You can't just send out a memo and expect everyone to embrace it. Here’s how to do it right:

Start with a Pilot Group: Find a few enthusiastic developers who are open to experimenting. Let them be the pioneers. Their successes and learnings will become the best internal marketing you could ask for.
Establish Clear Guidelines: Don't let it be a free-for-all. Create a simple "How-To" guide: how to write effective prompts, what tasks it's best for (and what it's bad at), and most importantly, what not to share with the AI (e.g., API keys, customer data, security vulnerabilities).
Reframe it as Pair Programming: Encourage the team to think of the AI as a junior pair programmer. It’s fast and knows the syntax, but it lacks domain context and needs senior oversight. This framing helps manage expectations and reduces the fear of replacement.
Evolve Your Code Reviews: AI-generated code still needs human review. The focus of code reviews will shift from catching syntax errors to validating business logic, architectural alignment, and potential security holes. The question is no longer "Does it work?" but "Is it the right solution?"
Create a Feedback Loop: Set up a dedicated chat channel where team members can share wins, funny failures, and effective prompts. This builds a collaborative learning culture and helps everyone get better at using the tool together.
Address the fear head-on: AI isn't here to take jobs, it's here to take away the tedious, repetitive parts of the job, freeing up developers to focus on the complex, creative problem-solving that humans do best.

Actionable Takeaways

If you're going to start your own journey with an AI coding partner, here are the key takeaways from my experience:

Start with a Clean Slate: Always commit your changes to version control before starting a session with an AI agent. It's your ultimate undo button and safety net.
Be the Architect, Let AI Be the Builder: You define the "what" and the "why." Let the AI handle the "how" for the boilerplate and routine code. Your primary role is to provide direction and review the output.
Master the Art of Context: Don't dump your entire codebase on the AI. Give it focused, relevant information for the task at hand. Treat it like a junior developer you're onboarding to a specific feature.
Trust No One: AI makes mistakes. Your expertise is the final quality gate. Review every significant piece of generated code for correctness, security, and performance.
Use AI to "Fail Faster": Got a new idea? Use the AI to build a quick and dirty proof-of-concept. You can validate an approach in minutes or hours, not days.
Document Your Debugging Sessions: When you and the AI solve a problem, update your project's documentation. This becomes part of the context for future sessions, effectively "teaching" the AI your project's nuances.
Introduce It Collaboratively: When bringing AI to your team, do it thoughtfully. Start small, provide guidelines, and foster a culture of shared learning.

Conclusion

AI in software development isn't about replacement—it's about amplification. It amplifies your productivity, your ability to explore ideas quickly, and your capacity to handle complex projects. But it also amplifies your mistakes if you don't maintain critical thinking and code review discipline.

The future belongs to developers who can effectively collaborate with AI while maintaining their core engineering skills. Start experimenting now, but remember: the goal isn't to write less code, it's to solve more problems.

Final Advice: Treat AI as the best junior developer you've ever worked with — extremely capable, incredibly fast and with amnesia. Needs guidance, context, and oversight. With that mindset, you'll build a productive partnership that enhances rather than replaces your capabilities.

The Dangling If-Else Problem: A Common Pitfall in Programming

Nick — Fri, 15 Mar 2024 09:17:02 +0000

One common pitfall that programmers often fall into when working with conditional statements in C# is known as the "dangling if-else problem". This issue arises when an if-else statement is not structured properly, leading to unexpected or unintended behavior in the program.

The dangling if-else problem can occur when there are multiple if-else statements nested within each other, and the conditions are not properly defined or the logic is not correctly implemented. This can result in the code executing in ways that are not intended by the programmer, leading to bugs or errors in the program.

To illustrate this issue, let's take a look at a simple example:

int num = 5;

if (num < 10)
    Console.WriteLine("Number is less than 10");
else 
    if (num < 5)
        Console.WriteLine("Number is less than 5");
    else
        Console.WriteLine("Number is equal to or greater than 5");

In this code snippet, the intent is to print out a message based on the value of the variable num. However, due to the improper nesting of the if-else statements, the program will actually print out "Number is less than 10" even if num is equal to or greater than 5. This is because the second if statement (num < 5) is nested within the else block of the first if statement, causing it to be skipped over.

To avoid the dangling if-else problem, it is important to carefully structure your if-else statements and ensure that the conditions are properly defined. One way to avoid this issue is to use braces {} to explicitly define the blocks of code within the if-else statements, like this:

int num = 5;

if (num < 10)
{
    Console.WriteLine("Number is less than 10");
}
else 
{
    if (num < 5)
    {
        Console.WriteLine("Number is less than 5");
    }
    else
    {
        Console.WriteLine("Number is equal to or greater than 5");
    }
}

By using braces to clearly define the blocks of code within each if-else statement, you can prevent the dangling if-else problem and ensure that your program behaves as expected. Remember to always test your code thoroughly and pay attention to the structure of your conditional statements to avoid running into unexpected issues.

What is DateTime Manipulation in C#?

Nick — Thu, 14 Mar 2024 10:39:09 +0000

DateTime manipulation in C# refers to the ability to perform various operations on date and time values, such as adding or subtracting time, extracting specific components of a date, formatting dates in different ways, and comparing different dates.

One of the most common tasks when working with dates and times is to manipulate them in some way. C# provides a DateTime struct that represents a specific point in time and allows us to perform various operations on dates and times.

Here are some common examples of date and time manipulation in C#:

Adding or subtracting time:

DateTime currentDate = DateTime.Now;
DateTime futureDate = currentDate.AddDays(7); // Add 7 days to the current date
DateTime pastDate = currentDate.AddMonths(-1); // Subtract 1 month from the current date

Extracting components of a date:

DateTime currentDate = DateTime.Now;
int day = currentDate.Day; // Get the day of the month
int month = currentDate.Month; // Get the month
int year = currentDate.Year; // Get the year

Formatting dates:

DateTime currentDate = DateTime.Now;
string formattedDate = currentDate.ToString("MM/dd/yyyy"); // Format the date as "MM/dd/yyyy"
string formattedTime = currentDate.ToString("hh:mm:ss tt"); // Format the time as "hh:mm:ss tt"

Comparing dates:

DateTime date1 = new DateTime(2022, 12, 31);
DateTime date2 = DateTime.Now;

if (date1 < date2)
{
    Console.WriteLine("Date1 is before Date2");
}
else if (date1 > date2)
{
    Console.WriteLine("Date1 is after Date2");
}
else
{
    Console.WriteLine("Date1 and Date2 are equal");
}

DateTime manipulation is an essential skill for any C# developer working with date and time values. By understanding how to manipulate dates and times effectively, you can perform a wide range of tasks and create more dynamic and flexible applications.