Welcome to the second episode of my “Magic Lamp” series. The whole point of the series is to share my experience with agentic coding - what I’ve learned, what worked for me, and why I think that, in a certain setup, the productivity and efficiency are out of this world.

In the first episode, I went through the overall context of my experiment - how I worked, under what conditions, and how representative that was of typical development work.

Now it’s time to get into the first portion of my learnings - I’d like to cover a proper MINDSET of working with agents: what kind of tasks I delegate to them, how I frame my expectations, how my interactions with coding agents look alike, etc. I call it a MINDSET of AGENTS’ SHEPHERD.Don’t expect any technicalities (just yet) - but these basics are far more important than I initially thought.

Before we start

But before we dive into details, a bunch of disclaimers:

1. I don’t claim this is the only/best way to work with agents - that's what has worked (& still works) FOR ME. That’s what I evolved towards in my journey.
2. I use several different agent harnesses (at least 2-3 in parallel, but the list changes)) with various models (again, at least 3-4 families of models) - but I’ve tried to keep my recommendations model/vendor-agnostic. Fortunately it’s not that hard: the same tricks work surprisingly similarly across different agents. However …
3. … paradoxically, the whole ecosystem moves so fast that some good practices get outdated literally after one week … I’ve tried to avoid that kind of recommendation (that I find rather temporal/ephemeral) - we’ll see in time how I did in that department …

The mindset

OK, w/o further ado, let’s talk about how you should approach working with coding agents …

FIRST of all …

Agents are not faster keyboards - to use agents, you need to interact on a higher abstraction level than you did when you were writing code. That means you don’t decide how to name the class or how many functions the business logic should be spread across (not mentioning going down to asking for specific statements like while, for or if). Initially, I thought I’d define rules, conventions, and practices for agents to follow, but in practice - even those are defined by agents (who are driven by me).

Anyway, to keep it from getting more complex than necessary - you need to switch from IMPERATIVE mode to DECLARATIVE mode. Instead of telling agents what to do (which is actually VERY detrimental - more on that later), you tell them what you EXPECT (as an outcome).

As a SECOND point, I’d suggest …

Building software with agents is much more about balance and resource management than programming ever was:

• You need to balance token spending (there are never enough of them, limits are applied on a few levels, and many variables affect usage velocity: model, effort, context, orchestration, parallelism, safety limits, etc.)
• You don’t manage just tokens, but also agent orchestration/rotation - burning tokens into code takes time, so it’s up to you to decide how many topics (with how many agents) you juggle at the same time; that’s a lot of context switching, a lot of prompt preparation, and some smart choreography to avoid expensive merges.
• With the agentic speed of code generation, potential entropy (if not managed well) can accelerate just as fast. That’s why you need to find a sweet spot between new features, comprehensive check-ups, adversarial inspections, and thorough audits. That’s harder than it seems, especially because agents, if out of the leash, will always find something worth doing (which can degenerate into an endless loop of fixing things back and forth ...) - the judgment on where the borderline between not-enough and enough is should be yours.

OK, but what does that all mean in practice? Say goodbye to the state of flow and embrace the manager-alike routine - continuous context-switching, making code changes asynchronously, fewer touches where you can make an impact (but with a higher causal power), etc. What is more - the traditional 8 hours long shift make less sense. What's becoming essential instead:

1. knowing how to plan agents' overnight work - manage a proper work rhythm
2. unblocking agents when the human intervention is needed
3. early detection of situation when things go awry (so you don't waste tokens/limits/time)

That’s what the everyday life of the agents’ shepherd looks like.

About point THREE then …Working with agents requires initial, very deliberate time investment. You need to TEACH (yes, seriously) agents your drill:

• your communication style
• standards you follow
• principles/core values/tenets you appreciate
• your typical workflow/routine

Counter-intuitively, don’t spend much time on describing all that pre-factum (initially). Start driving the conversations like you’d tutor a junior developer, be consistent, use the same naming (come up with names if needed - e.g., minor check-up, major check-up, thorough check-up). After a few occurrences, you should observe:

• agents following the same naming
• agents reminding you about the element of your routine (”how about a major check-up?”)
• agents “spontaneously” turning parts of your routine into skills/scripts

Agents adapt very quickly (Claude Code excels in that) - if you give them a chance (that’s why I mentioned above that imperative micro-management is detrimental).

What really, really helps here is providing the reasoning (to the agent) in a structured way - what’s the EFFECT you expect, how would you tell if it’s met (EXAMPLES), WHY are you asking for that (what’s the intention/reason), etc. If you follow simple patterns like that, you’ll see that agents will start suggesting moves coherent with your prior reasoning.

So, explain yourself (to the machine).

When it comes to point FOUR:

Detailed, full-blown specs are in fact very ineffective. Mostly because they usually fail to express the chain of thought designer/modeller went through to create the spec. And how individual “taste” drove all the micro decisions made while writing the spec. That’s why, in the end, leaving spec creation to agents is a much better idea … Of course, to make it happen, you need to run a proper solutioning conversation with them …

I typically start with the problem: how does it manifest (symptoms - e.g., what can’t be done, what’s ineffective/slow, etc.), whom does it affect, what (second-order) effects does it cause, etc. The agent has to clearly understand how to detect/measure symptoms (or that they are gone) and how to tell objectively that the problem is solved. I frequently ask it to replicate the issue/face the limitation (to make sure it gets it) as well.

The following discussion sometimes takes a lot of time & has many round-trips. I ask agents about opinions/recommendations. I add assumptions and constraints. I specify the success criteria and describe the quality bar level. I ask open questions (to check agents’ judgement/”taste”). I provide examples, but also ask for samples of work (before going all in). I am critical, but also ask agents to be critical (“what negative effects may that cause?”, “in what circumstances it won’t be sufficient?”, “is it coherent with the patterns and good practices we agreed upon?”) - if I coached agents well before, their responses are not sycophantic, but surprisingly constructive. The agent isn't afraid to say the design isn't coherent as long as it understands what it should be coherent with.

To keep agents on their toes, I sometimes intentionally ask for things they should reject/correct. And when I challenge their recommendations, I always justify, preferably with a reference to a rule/guideline/tenet or a principle we’ve set up before (”why do you think it is necessary at this point?”, “don’t you see any simpler way to achieve that?”, "are you certain it matches all the principles we've agreed upon?", etc.).

Point FIVE is all about …

Collaborating with agents is a lot like working with people, but more intense, more packed, and with far more diverging “threads” to follow & control. Agents have a measurable & controllable cognitive load. They don’t lose motivation on repetitive, tedious tasks. Contrary to the early versions, some mechanisms prevent them from “chasing the rabbit” indefinitely, and they also got much less literal - they can make assumptions, draw conclusions (from the prompt, but also context), detect and follow patterns. They are also very consistent if you provide enough assistance (e.g., sampled inspections).

Struggling with misunderstandings of differences between agent and human can bog down an unskillful shepherd. Still, if you embrace the drill and understand those practical differences, it can also provide a tremendous boost, e.g.:

1. LLM agents don't mind being interrupted - agents do not suffer from the context switch. You don’t have to “park” or “bundle” the questions - as long as you know how to manage “loose threads” …
2. … and the easiest way to do that is by introducing a backlog abstraction to the agents - don’t ask them for a single, isolated task, but keep the living, constantly shuffling backlog of topics (in the memory, in the file, in any simple tool you fancy - agents can adapt). I groom the backlog with my agents all the time, asking for recommendations, putting some items in the deliberate “freezer” (with clear exit criteria), and grouping/splitting them according to the needs. If you’re consistent and logical (to agents), it helps them build “judgment” about what could be valuable to you and what isn't.
3. If you’re truly declarative and you explain your intentions (to agents), you’ll benefit from mimicry/abstraction copying - agents will start reverse-engineering your patterns, behaviors, and rules - even the ones you don’t define explicitly. And then asking an agent: “do it just like you did feature XYZ” or “this new functionality should work conceptually like ABC” works like a charm.

OK, that's enough for part 2. Stay tuned for the following posts where I’m going to describe:

• How my current setup looks?
• How I optimize agent flows (and what the " valves " are to fiddle with)?
• Why do I think that slop is a skill issue?
• Where agentic coding won’t work?
• What has surprised me most while working with agents?
• Reviews/inspection/validation - how to make agent programming safe & stable?
• What elements of traditional software delivery drill got obsolete?
• And much, much more