It’s nice to know that some of my readers have Kobo devices. In addition to my Kindle Paperwhite Gen 7, I also have a Kobo Clara HD. I love my Clara because it’s so easy to upload EPUBs on it.

I’m currently reading The Last Coyote by Michael Connelly. After watching the entire seasons of Bosch, Bosch Legacy, and Ballard, I started reading the books from the beginning. I know Connelly also has the Lincoln Lawyer series and some standalone stories, maybe I’ll read them.

But I do want to read all the Bosch and Ballard ones. I’m quite surprised how different the books are compared to the TV shows. Still, I’m entertained and I can’t stop reading them.

So, what books are you reading right now? Let me know and I might check them out.

#books #Ballard #Bosch #Kindle #Kobo #reading

Spurs vs. Celtics.

My game of choice tonight comes from the NBA, it will feature the Boston Celtics vs. my San Antonio Spurs. With its scheduled start time of 7:00 PM Central Time, this is as late a game as I dare watch during the work week. (No, I don't work anymore, but the wife does. And I need to be up early to fix her coffee and help her leave on time.) So it'll be necessary to have my night prayers caught up by game's end so I can turn in right away.

And the adventure continues.

Jeg har to tatoveringer. Den ene er på leggen. Det hender jeg glemmer den litt, for jeg ser den sjelden, men jeg vet den er der. Den dukket opp på en heisatur til Rhodos for tre år siden. I LOVE BEERSKIS, står det. Jeg elsker ølski. Det hender folk tror det skal være whiskey, men nei, det er ølski, stå på ski og drikke øl.

Den andre fikk jeg på min første guttetur ever, til Ayia Napa. En kompis tok og tatoverte inn bursdagen sin på håndleddet, og da måtte jeg gjøre det og. 02.03.1993 på det venstre håndleddet, på innsiden, rett over pulsåra.

Det var for femten år siden. Jeg var 18 år. I dag fyller jeg 33.

🩵 Take your meds 🩵 You are enough 🩵 You are a good in this world 🩵 You are worth it 🩵 Treat yourself 🩵 You matter 🩵 It's gonna be okay 🩵 Your feelings are valid 🩵 There is so much to love about you 🩵 Get some rest

Ray Bradbury's 1957 book Dandelion Wine is a tale of small town Midwestern America through the eyes of a 12-year old boy. I picked it up after re-reading the more well-known Something Wicked This Way Comes, which comes after Dandelion Wine in the trilogy.

Yesterday, I read through the chapter on the 'Happiness Machine' that Leo Auffmann sets out to make. The idea hits him like a bolt of lightning, and he becomes obsessed on creating a machine that will bring people happiness. Interestingly, his wife (and others) don't see the need for such a device. After a frightening encounter with one of their children and the machine, Leo's wife Lena wants to try it out. Leo and the children hear her crying from outside the machine. Puzzled by the experience, here is Leo and Lena's conversation when she comes out:

“Oh, it's the saddest thing in the world!” she wailed. “I feel awful, terrible.” She climbed out through the door “First, there was Paris...”
“What's wrong with Paris?”
“I never even thought of being in Paris in my life. But now you got me thinking: Paris! So suddenly I want to be in Paris and I know I'm not!”
“It's almost as good, this machine.”
“No. Sitting in there, I knew. I thought, it's not real!”
“Stop crying, Mama.”
She looked at him with great dark wet eyes. “You had me dancing. We haven't danced in twenty years.”
“I'll take you dancing tomorrow night!”
“No, no! It's not important, it shouldn't be important. But your machine says it's important! So I believe! It'll be all right, Leo, after I cry some more.”
“What else?”
“What else? The machine says,'You're young.' I'm not. It lies, that Sadness Machine!”
“Sad in what way?”
His wife was quieter now. “Leo, the mistake you made is you forgot some hour, some day, we all got to climb out of that thing and go back to dirty dishes and the beds not made. While you're in that thing, sure, a sunset lasts forever almost, the air smells good, the temperature is fine. All the things you want to last, last. But outside, the children wait on lunch, the clothes need buttons. And then let's be frank, Leo, how long can you look at a sunset? Who wants a sunset to last? Who wants perfect temperature? Who wants air smelling good always? So after awhile, who would notice? Better, for a minute or two, a sunset. After that, let's have something else. People are like that, Leo. How could you forget?”
“Did I?”
“Sunsets we always liked because they only happen once and go away.”
“But Lena, that's sad.”
“No, if the sunset stayed and we got bored, that would be a real sadness. So two things you did you should never have. You made quick things go slow and stay around. You brought things faraway to our backyard where they don't belong, where they just tell you, 'No, you'll never travel, Lena Auffmann, Paris you'll never see! Rome you'll never visit.' But I always knew that, so why tell me?”

While reading this, I couldn't help but think, 'Bradbury prophesied smart phones and social media perfectly!' Lena's experience is the same as legions of others who report dissatisfaction and sadness with their own lives after being drawn in to the fake world of social media. The most poignant observation is, “It's not important, it shouldn't be important. But your machine says it's important! So I believe!”

Online (we don't see the term 'virtual reality' used often any longer) the relationships there aren't real. The experiences aren't real. The only thing seemingly real is the disappointment people face when they look at the reality of their lives against the false creations of Facebook, Instagram, Twitter, and the like. While not as dystopian as Fahrenheit 451, Bradbury saw the bleak future that awaited humanity as we traded the real for the imaginary. He was a genius.

In the remainder of the chapter, the Happiness Machine bursts into flame, destroying itself and the Auffmann's garage. In the aftermath, Leo sits on his front porch looking in to his family going out their ordinary, day-to-day lives and has the epiphany, “There it is...the Happiness Machine.”

Brilliant. Thank you, Mr. Bradbury.

#Bradbury #culture #life #reading

Summary

In this post, we argue that the role of a coder now belongs to a coding agent, but that the distinct role of a programmer defines the software engineer's role in interacting with the agent to produce computer programs. At the heart of this are, I think, answers to questions we have about software maintenance and the education of junior engineers.

Coding is Dead

Commentators in the tech industry have recently declared that “coding is dead.” The triggers for this statement are:

• LLMs, whose transformer architecture excels at pattern recognition and translation, have achieved a high success rate on key coding tasks, particularly since the December 2025 model releases.
• The improvements in coding agents have pushed the success rate for the code that an LLM generates above the 80% threshold, where agents can begin the journey toward independently doing work without human review for short tasks and increasingly lengthening.
• A wider understanding of good practices in context engineering—using the file system as memory and aggressively managing context by creating fresh agents—has helped prevent the quality drop that comes from context rot.
• The improvement of techniques to capitalize on agents' relentlessness to get them to iterate toward high-quality outputs via clear acceptance criteria for “done-done,” avoiding low-quality output caused by reward hacking. See How To Ralph.

Of course, all statements like “coding is dead” are hyperbolic, but it would be foolish to refute that in 2026 and beyond: agents will write the majority of code.

If coding is dead or will be dead by the early 2030s, what will software engineers do?

Programming is not Coding

The terms programming and coding can seem interchangeable, but historically, they are not the same. They refer to different activities, but for many years we have performed them together, making the distinction unclear.

Following Yourdon and Constantine in Structured Design, we assert that software engineering has the following roles:

• Analyst: talks to the customer to elicit the requirements for what we want to automate.
• Designer: determines how to meet the requirements and required quality attributes of the software, for example, how we split into modules, how those interoperate, scale, provide transactional integrity, etc.
• Programmer: decides on the design of programs: algorithms, data structures, and design patterns – writes coding specifications. QA of the program.
• Coder: implements the program design and has knowledge of syntax.

In the latter two roles, the original distinction between programmer and coder stems from an era when code was often punched out on cards rather than encoded in a high-level language. A programmer handed the coder a coding specification that defined the program to be written:

“Each component subprogram is coded using the coding specifications. Ideally, this phase would be a simple mechanical translation; actually, detailed coding uncovers inconsistencies that require revisions in the coding specifications (and occasionally in the operational specifications).” Bennington, Herbert; Production of Large Computer Programs.

Once, in larger organizations, different people performed the roles of programmer and coder. The programmer specified what code was needed and handed the resulting coding specification to the coder, who then authored the code that was to be loaded into the computer.

With the introduction of high-level languages, it became easier for developers to perform both the programming and coding roles simultaneously. The compiler did much of the work that the coder had done before, so the program specification could be completed simultaneously with coding. Later, the RAD/agile movements leveraged the ease with which programs could be specified as code was written, speeding up software development by collapsing many steps into a single process and shifting quality left via Test-Driven Development.

It is because of high-level languages and RAD/agile practices that many people use “programming” and “coding” interchangeably. But they are not the same.

Coding or Programming: What is the Difference?

You can reason about this difference easily. Once you learn multiple programming languages, you come to appreciate that all of them have variations of the same concepts: control structures, variables, etc., that only differ by their syntax. By contrast, data structures and algorithms don't depend on specific language syntax. Object-Oriented models of your domain can be developed using CRC cards or UML, without writing code. We think of these concepts as existing outside the syntax and the code, at the level of the program. You can reason about a program in a conversation, or on a whiteboard, without needing to use a specific syntax.

When writing code, you probably used to look up what you needed in documentation or examples and translate it to your domain. These statements were code and reusable as such, once fitted to the logic of your program.

We often overestimate the importance of coding in this merger of roles. It is likely that you spend more of your time as a programmer debating which frameworks and libraries you want to use, and what classes and interfaces form part of your model, than you do over whether you should use a for or while loop.

Knowing what syntax to use in a particular language is the role of a Coder; knowing what the code should do is the role of the Programmer.

Alex Booker has a good description of the difference between coding and programming in his video Coding or Programming: What Is the Difference?

XP: Elaboration, CRC Cards, Programming & Coding

Armed with this understanding, it may be helpful to identify when a developer is in a programmer or coder role. Consider the roles we took in an XP-like software development life cycle (SDLC).

• A team takes a story from the backlog and discusses it with the product owner. They develop acceptance criteria. Engineers perform the analyst role.
• The team makes architecturally significant decisions; these may bubble outside the team. Engineers perform the role of the designer.
  • Skills like Attribute-Driven Design and Large Scale Domain Driven Design are applied here.
  • The team may write an ADR to record architectural decisions.
• The team discusses how to implement the story. They discuss key parts of the domain model, including finding actors, assigning responsibilities to roles, and mapping roles to classes. They talk about the suitability of data structures and algorithms. They perform the role of the programmer.
  • As part of this process, the engineers may explore the space with tools like CRC cards.
  • The team may write an ADR to record architectural decisions.
• Once the team has a design, they break it into tasks. They perform the role of the programmer.
• They take tasks one by one and pair or mob on them.
  • One of the pair uses the keyboard to type code. They are in the coder role.
  • One of the pair, or the rest of the mob, specifies what should be written, watches for errors, correlates with the design, and reviews. They are in the programmer role.

The developer roles are: analyst, designer, programmer, coder.

Notice how the coder role is a relatively small part once we break out programmer from it. Because any team member may switch in and out of roles, we overlook how often we are in the programmer role rather than the coder role (or the analyst or designerrole). This tallies with the observation that coding is a small part of what software engineers do and aligns with the reason: many activities are, in fact, programming rather than coding. Your perception of how little of your job is coding is not incorrect, but you perhaps don't appreciate that analysis, design, and programming are engineering activities.

The Middle Loop

In their book Vibe Coding, Steven Yegge and Gene Kim discuss the Middle Loop, the construction of the context the agent uses when carrying out tasks. We often call this specification-driven development, but it bears less resemblance to older document-heavy approaches to software development, and more to the activities of the classic XP loop, with agents in the coding role.

Whilst this is an evolving practice, we can think about a common loop for working with agents like this:

The Middle Loop

• A developer takes a story from the backlog and discusses it with the product owner. They develop acceptance criteria. Engineers perform the analyst role.
  • The team may use a PRD to record the requirements.
  • The agent may act in a researcher role. The developer may need to make architecturally significant decisions; these may bubble outside the team. The engineer performs the role of the designer.
  • Skills like Attribute-Driven Design and Large Scale Domain Driven Design are applied here.
  • The agent may act in a researcher role.
  • The developer may write an ADR to record architectural decisions.
• The developer decides how to implement the story.
  • As part of this process, the engineer and agent explore the space.
    
  • The agent may act in a researcher role.
  • The developer performs the programmer role, making decisions with discretion and taste. They look at key parts of the domain model, finding actors and responsibilities, assigning responsibilities to roles, and roles to classes.
    • They talk about the suitability of data structures and algorithms.
    • They might use tools like Responsibility Driven Design (RDD).
• Once the developer has a design, the agent breaks it into tasks. The developer reviews the tasks, performing the role of the programmer.

The Inner Loop

• The agent takes tasks one by one.
  • The agent writes the code. They are in the coder role. The developer watches for errors, correlates them with the design, and reviews. They are in the programmer role.

The Inner Loop The Middle Loop

The developer roles are: analyst, designer, programmer. The agent roles: researcher, coder

The loop is fundamentally the same as XP, but the developer no longer performs the coder role and may be assisted by a researcher role:

The researcher role helps us utilize existing knowledge and patterns more efficiently because the programmer can delegate research that they used to do to the agent.

We didn't previously break out this role; it was part of being a programmer, and it is what we were doing when we visited Stack Overflow, documentation, or pulled candidate objects from the requirements based on their responsibilities.

We might still need to do some of this by reading, but the agent can help with heavy lifting, so we add a new role for that. However, decision-making, based on discernment and taste, lies with the programmer role.

The key, though, is that much is familiar from our first loop. Even with an agent's help, many roles still fall to the human-in-the-loop.

High-Level Direction Judgement and Taste

“It’s not perfect, it needs high-level direction, judgement, taste, oversight, iteration and hints and ideas. It works a lot better in some scenarios than others (e.g. especially for tasks that are well-specified and where you can verify/test functionality). The key is to build intuition to decompose the task just right to hand off the parts that work and help out around the edges.” Andrej Karpathy, x.com

Judgement, taste, etc., are the programmer's responsibilities. The agent is good at coding, but it needs help deciding what to write. That is why we still need the programmer role and don't simply delegate that to the agent. Maybe one day it will do that role too, but that day is not today.

Watch the Loop

Why suggest that the programmer/coder split is like pair/mob programming, where one partner watches the other? Because the agent needs to be observed.

“It's important to watch the loop as that is where your personal development and learning will come from. When you see a failure domain, put on your engineering hat and resolve the problem so it never happens again.

In practice this means doing the loop manually via prompting or via automation with a pause that involves having to press CTRL+C to progress onto the next task. This is still ralphing as ralph is about getting the most out how the underlying models work through context engineering and that pattern is GENERIC and can be used for ALL TASKS.” Geoffrey Huntley, Everything is a Ralph Loop

Now, some argue that it is inefficient. Do you need to review the agent's output? It's just coding. Just use a linter and check that it passes the tests.

Watching the loop confirms the theory behind what you are doing. What is the theory? That's the bit you must come away from the development loop with. It is how you will be able to reason about and maintain the software.

Programming as Theory Building

Peter Naur's essay, “Programming as Theory Building” states that the most important part of programming is theory building: “ On the Theory Building View of programming the theory built by the programmers has primacy over such other products as program texts, user documentation, and additional documentation such as specifications.” The theory, the knowledge built up by the programmer in crafting the program, is important for three reasons:

1. The programmer can explain how the program maps to the problem domain: “the programmer must be able to explain, for each part of the program text and for each of its overall structural characteristics, what aspect or activity of the world is matched by it.”
2. The programmer can explain the decisions that led to the choices expressed in the program text and documentation.
3. The programmer is able to understand how to modify the program to support change: “Designing how a modification is best incorporated into an established program depends on the perception of the similarity of the new demand with the operational facilities already built into the program.”

It is the latter point that is key. In large codebases, our ability to maintain a program depends on our possessing the theory of the program. The theory lets you modify the program successfully because you understand how the program's theory should be adjusted to meet the new requirement.

“The point is that the kind of similarity that has to be recognized is accessible to the human beings who possess the theory of the program, although entirely outside the reach of what can be determined by rules, since even the criteria on which to judge it cannot be formulated.”

The risk is that modifications made to a program, without understanding the theory, lead to decay. Most of us have experienced decay when modifications accrete as new additions that don't fit the theory of the remainder of the program. Eventually, the program becomes incoherent, and we are forced to rewrite.

“The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Revival of a program is the rebuilding of its theory by a new programmer team.”

Theory is the key to maintenance. If you don't have the theory, then you will struggle to maintain the software, because you will struggle with the programmer role.

“A very important consequence of the Theory Building View is that program revival, that is, reestablishing the theory of a program merely from the documentation, is strictly impossible.”

Code Reviews and Theory Building

In teams that don't use pair programming, a common compensation is to do code reviews. The purpose of both pair programming and code review extends beyond quality review; it is about sharing the theory of the program.

Often, teams struggle with reviews as flashpoints or have arguments in pairing because they fail to do enough theory-building when they pull the story from the backlog, a process we call elaboration or alignment. A simple way for many teams to improve code reviews is to avoid doing design there but to shift it left into elaboration when the story is pulled from the backlog. This shifts the theory building to an earlier step. The review then just confirms that the code matches the theory. Conflict arises when the theory is unclear during pairing or review.

Pair programming and code reviews spread the theory through the team. Junior developers often don't have the same facility with theory-building that senior developers do. Pairing, or code reviews, allow developers to exchange the theory through conversation and reach alignment.

These exchanges work best when they don't focus on the code but on the theory of the program.

The danger is that a new developer on the team, who has yet to build the theory for the program, in conversation with other developers, correctly specifies the program without the theory. Without the theory, their programming specification is likely to be wrong, and the resulting code will be wrong.

InnerSource, OpenSource, and Theory Building

OpenSource, or InnerSource projects, encounter this need to help contributors acquire theory all the time. Often, Open-source projects identify tasks that require less theory to help new contributors get started. Once contributors establish a track record of contributions, maintainers begin to invest the time in helping them understand the theory.

LLMs and Theory Building

The LLM cannot be used in the analyst, designer, or programmer roles, only as a researcher to support, because it cannot capture the theory of the program as expressed by Naur.

• The LLM does not have the context that lives outside the code, docs, and ADRs.
• The theory cannot be reconstructed only from the artifacts in the git repository [Naur].
• The LLM struggles with large programs. They remain too large for it to hold it all in the conversation and avoid context rot.

As such, an agent struggles to know the theory of the program and fulfill the programmer role. This is why the design is a conversation with the agent. This is why the loop must be observed. Acting as the programmer, you are building the theory of the program.

This, then, is the danger of handing the programmer role to the agent, rather than using it as a researcher. You no longer have the theory of the program, which will lead to the software decaying under modification.

This is why, when working with an agent, it is important to observe the loop, because we need to build the theory of the program. We may choose to work either as a pair programmer, reviewing the test and implementation as they are developed, or as a code reviewer, looking at the PR from the agent. Again, both will be easier if we shift left and put more effort into the design of our program, building a clear theory.

Agents' speed at writing code does mean that the old conflict, in which design insights that update our theory are much more easily applied, persists. With hand-written code, we may resist the amount of work a change to the theory represents for an insight. But with an agent, we just ask the agent to update the design, change the tasks, and add tasks to modify existing code.

Of course, updating the design for a new theory necessitates having tests that confirm the behavior remains the same when we change the theory. This is why we practice TDD. (This is also why we do TDD against behaviors and not details – because we want to be able to revise our theory, not make it rigid).

A Programming Episode with Brighter

As I am writing this, I am working with an agent to pick up a backlog item for Brighter. Configuration for Brighter can be hard. Even for simple CQRS, you need to ensure that pipelines are consistently sync or async, handlers are registered, and when you use messaging middleware, message mappers and transformers, subscriptions and publications, reactor and proactor pipelines, the whole thing has plenty of opportunities to trip users (including agents) up. The “pit of success” for Brighter is a source of a lot of friction and causes developers to reject us in favor of other frameworks.

What we need is static analysis, diagnostics, and dynamic analysis (Roslyn) to help. It looks like a useful backlog item to burn some tokens on.

Working with an agent to fulfill this, once we outline the requirements, requires us to pass our ADR steps.

We use our workflow spec:design to kick this off, and the agent has a pretty good attempt at the design of a tool that would meet the requirements.

But Brighter is a mature codebase, so it gets it wrong. It can't hold all of our code in its context. Its approach isn't dumb; it just misses a lot. It fails to understand the levels at which configuration can occur: local, with producers to the external bus, and with configuration to an external bus.

It doesn't yet have a theory for how to do this.

I give feedback on it. I explain the theory of the levels of configuration. I tell it about IBrighterBuilder and how that can help.

It refines its approach. It's better, but while it recognizes that we need a model of our pipelines, it fails to associate that with using our IAmAPipelineBuilder<T> to create pipelines; instead, it describes (a dry run is what I tell it) and not to build.

I give it more feedback. I explain the theory of using IAmAPipelineBuilder<T> to populate a model that describes a pipeline we can use to validate and report.

We re-run, and now it proposes extending PipelineBuilder with describe methods to build a model. This looks better.

I notice how it is setting up its rules. We have an implementation of the Specification pattern that is already checked in for some future functionality. It is in an assembly that depends on this one, but we can move it and its tests. I discuss it with the agent as a better way to implement this.

This is iterative, a conversation with the agent as we work out the theory of how this fits together. I already hold much of the theory of how Brighter works. I can extend that theory to what might work to implement this feature. The agent can pursue this faster than I can, reading existing code, figuring out what it would take to make it real.

This is programming. We are building the theory of how this works.

Does Stack Matter?

One simplistic idea is that the stack you use does not matter. Now that you can use an agent to write the code, what does it matter what stack you write it in? The problem comes down to whether you can build the theory of the program if you don't understand the stack. In some situations, you may be able to understand the theory without knowing the language, but in other situations, the nuances of how we choose to use language features to represent program theory may be important. Typically, as complexity grows, so does the likelihood that the stack – not just the language but the frameworks and libraries we use – is important to the theory, and as such, we have to understand it.

In cases where we need to understand the stack to build the theory, this would create unmaintainable code in which the programmer does not understand the stack they are working with.

Can LLMs Build Theory?

Agents are continuously new developers who struggle to maintain the theory, even if it is presented to them in conversation. So agents, like new developers, don't have the theory and can be coders but not programmers without supervision.

When using an agent, developers experienced with the codebase may be slower, precisely because they need to explain the theory to the agent. For short tasks, where explaining the theory might take longer than just doing the work, manual efforts may be faster due to this cost.

As codebases expand, we would seem to have increasing issues in codebases where the programmer role has been delegated to the agent, which has no theory, and thus treats every new requirement as novel. This accretes multiple theories into the codebase, which eventually becomes incoherent for agents or people.

New Developers, LLMs, and Theory

This also explains why senior developers are more productive with coding agents:

• They already have the theory, and they can explain it to the agent.
• A new developer does not have the theory and will make mistakes when specifying the program for an agent. Someone who has the theory must thus review the program of a new developer when using an agent, because the new developer does not have it.

Will Agents Develop Theory?

Memory is the key problem for agents with theory, both forgetting the theory behind changes and the amount of context required to keep those decisions in mind when modifying existing code. It's possible that developments in LLMs over time will break down this problem, allowing agents to build and retain theory. For now, the programmer role does seem beyond agents. They can help as a researcher, but don't have the theory a seasoned developer has with a codebase.

For now, then, the programmer role requires a person.

A Programming Episode with Brighter

Reviewing the ADR, the agent wrote, I realize we now have two approaches to validation. One uses our Specification<T> pattern, but the other creates a bespoke validation infrastructure. This seems ugly. If we are moving to the Specification<T> pattern, why do we still have a bespoke class to check our pipeline?

After reviewing the ADR, I realize the issue is reporting failures. Our Specification<T> pattern will give you pass/fail, but won't tell you which rule failed and why. It also explains an earlier issue, where the review noted that we were throwing an error from a Specification<T> when we reached a failure case that should not occur. We need to implement the Visitor pattern in our specification to collate all the errors.

I explain this change to the agent, noting that using the Visitor pattern will allow us to accumulate error messages in the graph, which can be retrieved if the combined specification evaluates to false. I tell the agent to ask me questions so that we can have a dialogue about this design.

The agent tries to overcomplicate this at first. When it answers, it can't figure out how to make this work. At a guess, the model doesn't recognize this approach. It can't initially see how to translate the multiple rule failures from its bespoke code, so it comes up with a ForEachSpecification<T>. I have to walk the agent back to basics on this approach, explaining that each Specification<T> is a rule; a rule may result in multiple breaches, to be recorded in an IEnumerable<ValidationResult>. I then explain that if there are any results, the predicate fails. The visitor pattern is then used to retrieve the results. I suspect that I assumed the agent understood this pattern combination, but it does not.

The agent now understands and presents a summary. The summary matches my expectation, so I ask it to go ahead and change the ADR.

The code looks simpler. I spot some failures to extract methods, leaving a complex implementation. Although this is just an ADR, I will have the agent change it now.

Overall, this conversational process is faster than writing this out by hand. We are getting closer iteratively.

But I also appreciate that I had simply accepted this, without properly reviewing, I would have had something less maintainable, because there were no clear patterns flowing through the code, but different ideas lashed together. I have worked with code bases where new insights had not led to refactoring, resulting in a codebase that felt like a lesson in decision archaeology. That was what would have happened here, without effective review. Because I took on the agent's roles as a researcher and a programmer, we iterate toward a cleaner design.

I feel comfortable spending more time here than I did before. The rush to get to writing code is gone. The agent can handle that quickly. Instead, I iterate on the design, safe in the understanding that the agent can deliver it quickly.

Return of the Programmer

Armed with the understanding that we have merged two roles in our thinking for years, how does this help us think about the future for software engineers?

In the era of agents writing code, this distinction between programming and coding becomes important. With coding agents, the agent is fulfilling the role of the coder at the levels of accuracy that mean it is rapidly taking over that task. But human software engineers continue to own the task of programming. The two have been merged in recent years, but we need to recognize their differences so we can make better decisions about who owns each task.

A little less poetic writing today. Normally I write out what I feel and I sit with it for a few days and buff up the text so it's poetic and impactful.

Not today though. Today I'm just here, as is.

Heading out on a small, day trip to a cool computer parts place. Makes me miss 'Fry's Electronics' but this place is so nice as well.

I'm sitting in the car with my favorite people and I'm tired as hell. Running on 4 hours of sleep.

Traffic is ass, as usual but I'm looking forward to the day.

I do wonder what we are gonna get for lunch... I get car sick on an empty stomach, so I'm planning ahead.

For now, I've got a coffee and a scarfed down my breakfast sandwich.

Goedemorgen Beste baldur nederland klaagzang interventie medewerker

aangezien ze bij baldur naamloze of besloten gelimiteerd verantwoordelijk voor eigen gedoe handelsmaatschappij hun infomail toch niet echt gaan lezen zet ik de inhoud daarvan hier maar neer. Het vergroot de kans op actie elders zelfs met mijn minimale invloed op alles wat overal op aard koopt en verkoopt en dat aanziet voor leven.

Ik mail u over twee dingen ten eerste de mogelijk spoedige levering van de onlangs bestelde 4 plant producten, is daar sprake van? Ik heb twee bananenplantjes en 6 lelie ballen besteld, bij de wachttijd stond 3 tot 6 dagen. Dit is dag 5 al, nog 2 dagen wachten en god had al een hele bol met inhoud en al geproduceerd, u zou lijkt mij in die tijd wel 6 ballen en 2 jeugdige enthousiaste planten kunnen zetten in een kartonnen doos en dan door een transport onderneming laten afvoeren naar mijn zeer kleine perkje, de mini ruimte die ik mag innemen van het almachtige aanwezige vooral in nummers en dergelijke omgezette taal.  Zou u mij kunnen vertellen welke enorm onoverkomelijke problemen u rondom heeft waargenomen om dit vervoer te voorkomen zeg het mij in Yip en Jannuke taal zodat ik ook zie wat u heeft gezien en dan opgelucht adem kan halen, dat is mij al dagen niet meer gelukt.

Ik had wat dit schrijven betreft ook gebruik kunnen maken van het door u waarschijnlijk zeer gewaardeerde antwoord formulier maar dan zou ik daar onder moeten invullen dat ik geen robot ben, als een robot mij vraagt mij of ik er geen ben dan vind ik dat voor weinig woorden veels te erg, zeker ook omdat ik eigenlijk wel een robot oftewel slaaf ben, Ik ben een slaaf van het groot koop systeem, een van u, een dwangmatige klant, net als u lezer aan de andere kant van deze linea, net als degenen verantwoordelijk voor het installeren van die soft en hardware, de enigste niet robots heb ik vijf dagen geleden bij u gekocht. Trouwens op dat slaafse koop moment vroeg niemand daar in u software residerend aan mij of ik een robot was of een vrij alles wat vast zit los kopend mensje, een naturel personage levend in echte natuur, dingen doet gedragen door daglicht, met de hand ipv een karikatuur moeizaam overlevend in een kunstmatig pientere. Zou u deze software makers kunnen vragen om in naam van mij en zeker ook van Albert Einstein, die van de Allee, bij die ene aanklikbare robot vraag een tweede invul vakje te maken waarbij ik mag aangeven dat ik zeker wel een deugdelijke gehoorzame robot ben want dat is namelijk het enigste juiste antwoord op die domme vraag. Dan hoef ik ook niet steeds meerdere keren vier motoren of fietsen of bruggen of trappen of brandkranen of bergen of bussen of auto's of zebrapaden aan te tikken met mijn aan de muis klevende klik hand, van die dingen die alleen een robot doet.

The Short Version

Nutrient antagonism is when excess of one nutrient physically blocks another from being absorbed – your plant has enough of what it needs, it just can't get to it. Adding more of the blocked nutrient usually makes things worse. A 1953 agricultural chart called the Mulder's Chart maps all of these interference relationships; PlantLab's diagnosis now applies that same logic automatically, flagging the most likely excess nutrient in every analysis.

What this post covers: – Why “add more” is sometimes the exact wrong answer – The Mulder's Chart: what it shows and how to read it – The four antagonism traps cannabis growers hit most often – How to tell antagonism from a true deficiency – What to actually do once you've identified the likely excess

---

You're three weeks into flower. New growth is showing interveinal chlorosis – yellowing between the veins. Classic iron deficiency. You've seen it before. You adjust your pH, add some chelated iron, wait a few days. Nothing. You add more. The leaves get worse. Two weeks of this and your runoff EC looks completely normal. What is going on?!

Here's the thing: your plant probably has plenty of iron. The problem is that something else is blocking it from getting in. You're chasing a deficiency that isn't really there.

That's nutrient antagonism – and it's the reason “add more nutes” is sometimes the exact wrong answer.

---

Why Adding More Makes It Worse

Plant roots absorb nutrients as ions through specific transport proteins – essentially tiny gates in the root membrane, each specific to particular ions. The problem is that some ions are chemically similar enough to compete for the same gate.

Calcium (Ca²⁺) and magnesium (Mg²⁺) compete directly. Iron (Fe²⁺) and manganese (Mn²⁺) compete. Phosphate and zinc compete. When one is present in excess, it floods the available uptake pathways and crowds out the competition. The blocked nutrient can be sitting right there in your solution at perfectly normal levels – the plant just can't get it through.

Think of it like a packed venue with a capacity limit. Having more people waiting outside doesn't get anyone in if the wrong crowd already filled the room.

Your nutrient solution looks fine on paper. Your runoff TDS is normal. But the plant is effectively starved of the blocked nutrient. When you add more of the blocked nutrient, you're just adding more people to the outside line.

The fix is not to add more of the blocked nutrient – it's to reduce the excess that's doing the blocking.

---

The Mulder's Chart: 70+ Years of This Being a Known Problem

In 1953, agricultural researcher Cornelis Mulder published an analysis of how essential plant nutrients interfere with each other. The interactions he mapped have been confirmed and refined by plant scientists ever since. Farmers and agronomists have used the resulting chart as a standard diagnostic tool for decades.

Most cannabis growers have never heard of it.

Here's the cannabis-relevant subset, derived from the interaction patterns that show up most in real-world growing:

If you have excess of...	It blocks uptake of...
Calcium	Boron, Iron, Magnesium, Manganese, Phosphorus, Potassium, Sulfur, Zinc
Phosphorus	Copper, Iron, Manganese, Zinc
Potassium	Boron, Calcium, Magnesium, Nitrogen, Phosphate
Nitrogen (toxicity only)*	Boron, Copper, Potassium
Zinc	Copper, Iron, Manganese
Iron	Manganese
Manganese	Iron

Calcium is the overachiever – it can block uptake of nearly everything else. This is also why CalMag can backfire when calcium is already the problem.

One important distinction about nitrogen: it's the most visually distinctive excess in this table. While every other entry can only be inferred from the deficiencies it creates, nitrogen toxicity has its own unmistakable signature – dark green, shiny leaves with tips curling downward, the “claw.” You can't look at a plant and spot phosphorus excess; you see iron and zinc and manganese deficiency appearing together, and you work backwards from that.

---

The Four Traps Cannabis Growers Hit Most

The following are the scenarios you'll recognize from forum threads, grow journals, and that one grow that made you seriously question everything.

Trap 1: The Calcium-Magnesium See-Saw

Magnesium deficiency and calcium deficiency share visual overlap in early stages – interveinal chlorosis, lower leaves first. The forum answer is CalMag. CalMag works great when both calcium and magnesium are actually depleted. The problem: if calcium is already elevated (hard tap water, previous CalMag doses stacking, heavy base feed), adding more calcium deepens the antagonism against magnesium uptake. The magnesium deficiency gets worse, you add more CalMag, calcium climbs higher, and you're doing laps around the same problem.

The lesson isn't that CalMag is bad. It's that the same supplement that fixes a true Ca/Mg deficiency actively worsens a calcium-driven lockout.

Trap 2: The Phosphorus Stack

Late veg or early flower: you flush the plant, then hit it with a P-heavy bloom formula to push the transition. Phosphorus accumulates fast. Now iron, zinc, and manganese uptake are all suppressed simultaneously. Three separate deficiency symptoms appearing in the same growth period, on new leaves, none of them responding to treatment – that pattern almost always points to one excess, not three separate missing nutrients.

Trap 3: The Hard Water Baseline

Tap water at 200+ ppm calcium (common in many regions) puts you at or above the antagonism threshold before you've added a single ml of nutrients. Your nutrient line looks balanced on the label, but calcium is already dominating the root zone before the grow starts. By mid-flower, everything from magnesium to iron to zinc is struggling. Check your source water with a TDS meter before spending two weeks blaming your feeding schedule.

Trap 4: Soil Buildup

Amended soil and organic media are forgiving by design – but they accumulate phosphorus and potassium over time. By week 6 or 7 of flower, even a conservative feed is compounding on top of weeks of residual buildup. Micronutrient lockout becomes predictable. If your soil grows have historically gone sideways in late flower despite clean feeding, this is the first thing to look at.

---

Antagonism or True Deficiency: How to Tell

If the problem is antagonism, adding more of the deficient nutrient won't fix it – and may accelerate the decline. Use these signals to read the situation:

Signs you're probably dealing with antagonism: – You already added the deficient nutrient and symptoms didn't improve or got worse (i.e. stop, just stop!) – The symptom pattern matches a known antagonism pair from the table above (i.e. hey, that's it) – Multiple micronutrient deficiencies appeared at the same time, not sequentially (i.e. why does this happen to me) – Runoff EC/TDS is elevated (i.e. I knew it!) – You've been stacking the same formula for several weeks without a flush or reset (i.e. it worked before, what gives?)

Signs it's probably a true deficiency: – Fresh grow, new medium, feeding hasn't been aggressive – Runoff EC is low – Single deficiency symptom, nothing else overlapping – Deficiency appeared early in the cycle when soil is still fresh

The diagnostic question to ask yourself: “I'm seeing [symptom]. What have I been feeding heavily that might be blocking this?” If the Mulder's table shows a plausible answer, that's your starting point.

---

What to Do When You Suspect Antagonism

1. Stop adding the blocked nutrient. More iron won't fix iron lockout.
2. Identify the likely excess using the table above. What have you been stacking?
3. Reduce that input. In DWC, replace the reservoir and mix fresh at lower concentration. In coco, back off feed strength and let runoff EC drop. In soil, a water-only cycle at half strength is usually enough to start clearing it.
4. Let runoff EC normalize before resuming full feeding.
5. Reintroduce the blocked nutrient at a conservative dose once the excess has cleared.

Don't automatically reach for a full aggressive flush. Antagonism builds gradually and usually unwinds gradually too. You're correcting a balance issue, not nuking the root zone – unless the situation is severe, ease into it.

---

How PlantLab Applies Mulder's Chart

PlantLab's /diagnose endpoint detects individual nutrient deficiencies from photos. When we built the nutrient subclassifier, the hardest cases weren't single deficiencies – they were patterns where three or four micronutrients were suppressed simultaneously. Those cases almost always had a single excess driving them, not three separate missing nutrients.

So we encoded the Mulder's Chart antagonism graph directly into the analysis layer. Every diagnosis now returns a mulders_hypotheses field: a ranked list of the most likely excess-nutrient candidates, inferred from the co-occurring deficiency pattern.

Here's what that looks like in practice. If the model detects iron deficiency + zinc deficiency + manganese deficiency in the same image:

{
  "mulders_hypotheses": [
    {
      "excess": "phosphorus_excess",
      "explains": ["iron_deficiency", "zinc_deficiency", "manganese_deficiency"],
      "evidence": 2.38,
      "evidence_count": 3
    },
    {
      "excess": "calcium_excess",
      "explains": ["iron_deficiency", "zinc_deficiency", "manganese_deficiency"],
      "evidence": 2.38,
      "evidence_count": 3
    },
    {
      "excess": "zinc_excess",
      "explains": ["iron_deficiency", "manganese_deficiency"],
      "evidence": 1.61,
      "evidence_count": 2
    }
  ]
}

Example reflects multi-label nutrient detection shipping in the next release.

The evidence score is the sum of confidence scores for each condition the excess would explain. Phosphorus and calcium both explain all three deficiencies equally in this example – both rank first. Zinc excess only explains two of the three, so it ranks lower.

This is a hypothesis, not a measurement. The model doesn't have access to your water report, feeding history, or what's in your soil. What it gives you is a starting point: here's which excess is most consistent with the visual pattern. For most growers, that's the hardest part of the diagnosis loop – not knowing which direction to even look.

For growers running API-driven automation – Home Assistant, Node-RED, custom controllers – the mulders_hypotheses field maps directly to an action: phosphorus_excess → reduce P in next feed. The diagnosis points you to the problem; your setup handles the correction.

---

Limitations

This is inference, not measurement. A soil test or water analysis gives you actual numbers. mulders_hypotheses gives you ranked hypotheses based on what the plant looks like. Use it to direct your investigation, not replace it.

pH is a parallel problem. Deficiency symptoms caused by pH outside the optimal range look identical to antagonism symptoms. If your runoff pH is off, fix that first – the Mulder's table won't help you here.

Rare interactions have less training data. Copper deficiency is a newer addition to the model; detection confidence is lower than for iron or nitrogen. Treat copper-related hypotheses with more skepticism until more data accumulates.

Visual overlap is real. Late-stage symptoms, nitrogen toxicity masking other issues, and grow-stage-specific presentation can confuse any visual analysis. If a diagnosis doesn't match what you're seeing, trust your eyes and reach for a test kit.

---

Related Reading

• Yellow Leaves, Seven Suspects: How PlantLab Got Specific About Nutrient Deficiencies – how the nutrient sub-classifier powering this was built
• Nitrogen Deficiency in Cannabis – the most common deficiency, and how to tell it apart from light deficiency and senescence

---

Try PlantLab free at plantlab.ai. Create a free account and get 3 diagnoses per day — upload a photo and the diagnosis returns structured JSON: conditions detected, confidence scores, and the mulders_hypotheses field for any nutrient patterns that fit the antagonism graph.

I had something on my mind, I couldn’t sleep because I needed to get it out of my system, but I have forgotten what it was.

It has been like this all week; my mind has been wandering to useless places; when I try to focus, I forget on what and then when I remember, and say it’s something on the computer, so that requires 2FA, of course it does, so I pull out my mobile phone, but forget why so instead I watch this clip of ”The Last of the Mohicans” soundtrack, now played on an ancient Celtic instrument.

But it’s only Monday

---

I dreamt we were having something like sushi for dinner, and there was a giant scampi there, size of a tennis ball, which was jumping around, screaming with this terribly loud shrimp voice, bouncing and hiding in the blue sofa: he wanted so desperately to live, but we had our minds fixed to eat him

It felt terrible, like the way cats sometimes play with ducklings sadistically (it appears) before they eat them

---

Yes! I remember now, the forgotten thought which triggered a burst of inspiration:

there’s a children’s tooth brush in our bathroom, baby blue plastic with a soccer ball printed on it and the text ”You GOT this!”!

That’s what I was thinking about

In general such motivational texts I think fall flat as they can’t possibly know who they are targeting and to what they refer, but still

I GOT this!

To be fully honest, the only need that gets left neglected when not in a relationship is sex. Everything else through some extent I can fill through other ways. I also do think that validation is something that I will be missing, and I think maybe it’s a noble goal to pursue feeling like I don’t even need external validation.

I would also like to learn more about the abundance mindset, I’d like to focus more on believing that there are plenty of wonderful women out there that will match my energy, both the chaotic sides, and also the emotionally intelligent sides. I think the more I’ve thought about it, the more I’ve really liked the idea of having a partner that’s similar to me in terms of intelligence. I think there’s so many nice knock on effects from that, like I think humor is a good signal, I think the ability to change is really nice, the ability to do things at a higher level is also really fun, and it reminds me of something my therapist said in a way. My therapist mentioned how someone who has their life together, it is successful and financially independent, how that’s a strong signal that correlates with emotional intelligence. Mostly just because when you have those basic needs met, you have the room to focus on emotional growth, similar to Maslow‘s hierarchy of needs. And also there’s the massive benefit of dual income which would be fucking fire, because I already make a lot of money on my own. I think if my future partner is also successful, having that level of wealth would be fucking awesome. Like I think that level of wealth really enables stuff like traveling the world, or being able to get a lot of really cool luxury things, like PC stuff, nice furniture, and of course the financial freedom. I already have the house part covered, and so I think if I can find a partner that is in a similar financial situation to me, that would be absolutely financial freedom.

China International Leadership Programme Overview

The China International Leadership Programme is a blended China internship programme offering Mandarin immersion, cultural engagement, site visits, and teaching placements in China. This international internship programme combines online modules with immersive, on-the-ground experience in China, giving participants practical exposure to Chinese language, culture, education, and community life. It develops global leadership skills while enabling participants to make a meaningful difference in rural Chinese communities through teaching, service, and cross-cultural engagement.

The China Internship Programme is delivered by the Ireland Sino Institute, which is duly registered in China with both the Ministry of Education and the Ministry of Civil Affairs. It is legally authorised to facilitate Z visa applications for incoming interns. It also maintains registered offices in Ireland and the United Kingdom.

China International Leadership Programme Module 1 Overview (Online)

This module provides applicants with an introductory session and individualised guidance tailored to their specific circumstances. It also includes a formal interview, résumé preparation support, and assistance in securing required documentation, including an apostilled degree, apostilled police clearance, TEFL or TESOL certification, and a professional recommendation letter. The mode of delivery is online.

To register for or to learn more about the China Internship Programme, you can visit AllThingsChina.

Another surprisingly social day chatting with neighbors. The sun shone just long enough for me to run my long run too — what luck.

I’ve carried these words across a few landscapes now — small cabins, quiet platforms, places that felt promising but never quite became home.

For now, I’ve set my pack down here on Write.as. I’m curious about this place: its stillness, its simplicity, its promise of a slower web. I’ve brought the older entries with me, the ones written along the road, so the trail behind me is still visible.

I’m not sure yet if this will become the long-term home of Wayfarer’s Quill, but I’m hopeful. I’m here to see what this space offers, how it feels to write within its walls, and whether the quiet here is the kind that invites me to stay.

For now, I’ll linger. And write. And see what unfolds.

#NewBeginnings

Abandoned again. Well, not abandoned, but that's what it felt like. Siv brushed down the front of her long bekae, which was a long piece of sky blue cloth she pulled over her head and cinched at the sides with a wide violet sash. It allowed her a lot of movement as it didn't restrict her legs. Yes, her hips showed easily, but she didn't mind. She preferred the freedom of movement. Not only that, she had trained as a smekihanxa with the Peridot Order of House Aldinav. As a courtesan in training, it meant she was used to being around people of higher ranks than most maids and was much more familiar. Siv had learned the art of the laugh, the witty banter, and how to touch someone's arm or shoulder in just the right way to make them relax. Unfortunately, she wasn't cut out for courtesan work after causing a rather embarrassing situation between two houses. Since then it had taken practice to remember how proper she should be.

Siv shivered at that thought but focused on what she was doing now. She was an Estate Maid of the 1st Order and a Mistress Apprentice. Those were big things to focus on, but the young woman had earned Mistress Maevin Maer's trust. Siv had been left in charge as Mistress in Standing since Maevin had to handle the Council of Servants for the planet. That was not something Siv wanted to be involved with.

Smoothing her dress out once more, checking the red silk scarf around her waist and running her hands through her two-tone hair, Siv gently rapped on the wooden door of her Lord's office.

“Come in!”

Henry Patton always sounded so exuberant. His curiosity and fascination always brought a smile to Siv's face. He was even gentle with her and the servants, which endeared everyone to him even more. The young woman stepped in, placed one hand atop the other at her waist, and bowed.

“eta mleteematae Siv kive, xixihanvashav.” Siv is here to serve, my master.

“Oh! Siv!”

There was that smile. Her lord was quite excited today. He had a bunch of compu-pads all over his desk, their crystal screens catching the sunlight through the window at odd angles. The entire desk had the look of someone who had been digging through information for the better part of the morning. The window behind him was wide open and a nice breeze was blowing through.

“I have something for you to do. Maevin was going to handle it but things got moved up; she's on the other side of the planet you know.”

Yeah, she knew. The world of the Houses was always moving and it was a delicate dance due to how much the houses could mistrust each other.

“What is it that you require me to do?”

“It's about the veehanaeset.”

The Soft War. Yhe meeting that Lord Henry was putting together with the estates on the planet. The woman's heart jumped slightly at the word. Yes, of course there were other estates here. Victory was an important hub, though House Avernell was the dominant one. Unlike smaller planets that may only have one estate, this planet meant the dance was much more subtle and intense.

“And how can I help with that?”

“I have been informed that Iron Forge, Black Fall, Morning Dew, and Crystal Spring estates are going to be here later this afternoon. They're sending representatives to hammer out the details among the orders before their lords and ladies arrive.”

Siv swallowed. Now she wished she was at the Council of Servants. What Henry was telling her was that she was going to be responsible for negotiating with rival houses on how the entire event was going to go. By the gods, she wished Maevin were here. When it came to her training, Siv did not have much.

“Do you have a list of those who are coming as representatives?” Siv asked, trying to sound calm and not as nervous as she was.

“Let's see. Mistress Niva Atama of Iron Forge, Steward Vedarat of Black Fall, Lady Halesia of Morning Dew, and Estate Maid of the 1st Order Minaka of Shova.”

A lady. Siv swallowed. Not only were there two servant leaders coming but a Lady, a lady who, if memory served, was the first wife of the Duke of House Nevakev.

“Are you alright?”

Lord Henry's voice cut through the chattering voices in her head. The maid bowed more deeply to hide the embarrassed flush in her face. “I apologize, my master. I was simply caught off guard by the rankings of those coming. I am only a Mistress Apprentice.”

Henry nodded and then set down the compu-pad he had been holding. “Siv.”

The woman looked up to see her master looking right at her.

“While Maevin is gone, you are my mistress. I don't care that your title has 'apprentice' attached. You are to be respected like a mistress, and if they don't, I expect you to tell me. No one is going to be insulted here just because I'm human.”

Siv's heart trilled a bit in her chest at such a vehement defense of a servant. No wonder so many maids had crushes on him.

“As you wish, my master.”

---

The living room was not really massive, but the way the furniture had been placed gave the area a feeling of grandeur. The sofas had been placed against the walls, with another lush one close to the center. There were a few large, firm cushions for people to lounge on if they preferred to stretch out. Comfort was the spirit of House Avernell.

The hardest thing was waiting. Siv had asked Nish if she would escort the arrivals to the living room. That woman was very steady and level-headed, unlike her lover Abiva. The Mistress Apprentice wanted to be there herself but that would weaken her position. Maevin never went to meet any other servant except when it was a person of high stature. It twisted her gut trying to decide how to treat Lady Halesia, and the Emissary maids were no help. The protocol for the wife of a lord who didn't hold a title except by marriage was a very big gray area. In the end, the young woman had decided to wait here and ask Nish to show far more deference to her than to the others. Hopefully that wouldn't get her into trouble.

When she heard the patter of feet coming, Siv took a deep breath, smoothed down her dress, and turned, trying to smile warmly but in charge. The group of people who came in were jarringly different from each other.

Nish led the way. The woman with the blonde short-cut hair placed one hand on the other in front of her waist and bowed. Siv appreciated the fact that the Arch Maid bowed much further than she needed to, helping cement that Siv was in charge. Behind her came the others.

The first was someone that Siv recognized immediately. They had had enough dealings with Iron Forge Estate that only the newest people did not know Mistress Niva Atama. The woman was the opposite of how the Mistress Apprentice was dressed. A long charcoal black robe trimmed in gold wrapped around her, the rich material catching the natural light as she moved. Her silver hair was in three braids that wound down her head and faded into a dark brown, almost blending with her clothes. A rather ornate gold crown sat on her head, the gems dangling from it bouncing as she walked. A thick dark yellow sash was wrapped around her waist and she wore matching gauntlets of metal that gleamed in the light. For anyone else this would be a weapon and forbidden, but Siv knew she had earned those by fighting off a Drull attack in a different star system. They were her badges of honor, and the Mistress Apprentice had no pressing reason to ask for their removal. The way that Niva watched her, Siv was pretty sure she was waiting for a challenge.

The next to come in was a tall man wearing simple pale blue robes that fit him well and had larger, pointed shoulders, a style common among House Devenek. The silver sash around his waist denoted that he was a Steward, the male equivalent of a Mistress, and this had to be Vedarat. The man gave her a nod of acknowledgement.

The last two came in together, one all gentle smiles and the other quiet.

“xikihanma daexugee!” Lady Halesia said, reaching out with both hands, striding forward, and taking Siv's in her own. “It is so wonderful to meet you. I have heard of you and your training under Mistress Maer. It is sad that she is not here for me to compliment your skills.”

Siv did her best not to blush. A Lady of another house complimenting her?

Halesia carried herself with an effortless grace that drew the eye immediately. Long, wavy hair cascaded past her shoulders, pinned back with a delicate bow that softened the sharp elegance of her features. Her face was warm and open, lips curved into a smile that suggested she knew exactly the effect she had on people and probably enjoyed it.

Her outfit hugged her figure closely, a fitted bodice cinched at the waist, paired with sleek dark leggings that disappeared into tall boots. When Halesia spoke, her voice carried a practiced charm, her words chosen with ease. She had made no visible effort to do anything except greet them, but Siv already felt that she could easily take over the discussion. So many powerful figures here and she was on her own.

Don't screw this up, the Mistress Apprentice scolded herself.

The last person was Estate Maid of the 1st Order Minaka of House Shova, and it took everything in her not to startle. Large, jagged white scars ran down the left side of her face, marring her look. Her dark eye on one side moved while the other was a white electronic eye with electric blue veins. This woman had been through something. The sitting room felt smaller with all of them in it.

Siv gestured to the sofas and cushions, keeping her expression warm and her voice as even as she could pull off. “Please, make yourselves comfortable. Refreshments will be brought shortly.” She had already arranged for Burdak to have a few of his maids bring tea and the eflen cakes that were a specialty of House Avernell's kitchens.

Niva did not so much sit as install herself. She chose the central sofa, spreading the weight of her charcoal robes around her like a declaration of territory and placed her gauntleted hands on her knees. The gems on her crown caught the afternoon light coming through the wide window and threw small bright shapes across the ceiling.

Vedarat settled into the armchair to the left, crossing one leg over the other and folding his hands in his lap. He said nothing yet, but his eyes moved around the room with a slow, measured attention that reminded Siv of someone taking inventory. Hadn't Maevin said the quiet ones should be watched the most?

Lady Halesia settled gracefully onto one of the firm cushions near the center, tucking her legs neatly beneath her and smiling as though this were a pleasant social call rather than a negotiation. Minaka positioned herself slightly behind and to the right of Halesia, spine straight, scarred face unreadable, her mismatched eyes fixed on the middle distance. Siv took her place standing before them, hands folded at her waist.

“I want to thank each of you for coming on behalf of your houses. Lord Henry is honored by the presence of such distinguished representatives and wishes this meeting to be fruitful for all parties.” She paused just a breath. “I also want to acknowledge that Mistress Maer would normally be conducting these discussions. In her absence, Lord Henry has placed his full confidence in me, and I intend to honor that trust.”

She watched Niva's expression during that last part. The Mistress of Iron Forge did not roll her eyes exactly. She simply let her gaze drift to the window and back in a way that communicated everything without committing to anything.

“As your presence is a tentative agreement to participate in the veehaneaset, it is important for us to make sure that everyone is comfortable. This is supposed to be an informal gathering and my master has made it clear he wants comfort and safety to outweigh any ceremony.” Siv said, trying not to let the words all spill out.

“Outweigh ceremony?” Niva's voice was smooth and low and carried the particular weight of someone who had never been told no and had survived it. “That is a very generous sentiment.”

“Blue Blossom Estate extends it sincerely.”

“Then perhaps your master can explain how this can be maintained when tradition is important not only to my house but to others like House Shova?” Niva leaned forward slightly, the dangling gems of her crown swaying. “Tradition has been a part of our culture as long as we can remember and cannot be thrown aside at the whims of a Terran. This is fact.”

“If I may,” Halesia said, her voice slipping into the conversation like warm water finding a gap between stones. She smiled at Niva with what looked like genuine friendliness. “House Patton-Avernell holds a charter from the Empress herself. It stands to reason that this house's preference of minimal ceremony is their specific culture. It would not look good upon any of our estates if we simply dismissed their approach.”

Niva's jaw shifted slightly. She sat back.

Siv exhaled through her nose. The verbal fencing had already begun and it took everything not to tremble from the adrenaline running through the Mistress Apprentice's system.

“My master wants the representatives to feel as safe and welcome as possible,” Siv continued, drawing their attention back. “He wants genuine conversation without the trappings of prestige, for the betterment of all estates here on Victory.”

“I have heard Lord Patton-Avernell's own words offering support to my estate,” Vedarat's voice was calm and matter-of-fact. He had not changed his posture at all.

“Words are worth only the sound they make,” Niva responded with a curl of her lip.

Steward Vedarat slowly turned to look at the other peer, holding her gaze. “Which he has carried out. His lord has submitted official paperwork to authorize House Devenek's participation in the Starbase upgrades.”

Niva's eyes narrowed, something calculating behind them, but she did not say anything more. The room was quiet for a moment.

Siv glanced briefly at Minaka, who had not moved, had not spoken, and appeared to be semi-focused on something outside the window rather than the meeting going on. There was nothing hostile in it, almost as if this conversation was not interesting to her.

Siv straightened slightly and moved to the next point.

“The ancient tradition of veehaneaset carries an expectation of gifts to begin the event, something that our Emissary maids made clear to my master could not be dispensed with.” There were some things that simply could not be dispensed with.

Niva's chin lifted.

Here we go, Siv thought.

“Iron Forge intends to defer such discussions at the moment.”

Everyone shifted uncomfortably. It took everything for the Mistress Apprentice not to say something. Niva was really pushing the boundary of what she would be allowed to get away with.

Siv kept her voice even. “Still, such things must be planned for, as allowing the insult of any estate or house is something my master will not permit.”

“My husband has prepared a donation of currency toward the upgrades of the starbase we were speaking of earlier,” Halesia said lightly, “to help defray the pressure that would put on House Patton-Avernell.”

Niva frowned and Vedarat straightened.

“Such a substantial gift for a project that one is not part of is...interesting,” Vedarat said with narrowed eyes.

“Peace, Steward,” Halesia said with a mischievous smile. “We donate it in the spirit of the veehaneaset with no expectation except as proof of House Nevakev's trust in Lord Patton-Avernell's leadership.”

The Mistress Apprentice wasn't sure if that helped or not. The politics was choking. How did Maevin handle all of this?

For the next two hours they pressed on with discussions of lodging, how many security personnel, what was expected of any honored maids, down to the mundane of how meals would be prepared and so forth. Even so, in the back of Siv's mind, she knew Minaka had not said anything, had not engaged in a single discussion point.

As they were wrapping up, the 1st Order Maid stood, drawing everyone's attention.

“Crystal Spring Estate of House Shova will not be participating in the veehaneaset.”

Her voice was low and even and carried no apology in it whatsoever. Minaka didn't bother to look at anyone but turned on her heel and left through the door she had come in. The silence she left behind lasted exactly two seconds.

“Well,” Niva's voice cut across the room like a blade finding a seam. “That is rather expected of House Shova, isn't it. They refuse to participate in anything that could put their precious knowledge at risk, even if it means insulting the ruling estate.”

Halesia's smile had gone carefully neutral. Vedarat had gone very still in the particular way of someone who was deciding whether this was his problem. Siv's heart was hammering. She could feel it at the base of her throat. Siv did not let herself swallow visibly. She kept her hands folded at her waist and her expression warm and in charge, completely at odds with the cold spiral happening behind her eyes.

“Please forgive the interruption,” she said, and was relieved to hear her own voice come out steady. “I wonder if I might impose on your patience a little longer. I believe Nish was preparing a second round of refreshments.”

As if summoned by the words themselves, Nish appeared in the doorway with a tray of small glazed pastries and a fresh pot of something that smelled of spice. The Arch Maid moved through the room with her particular brand of unhurried competence, setting the tray down and meeting Siv's eyes for only a fraction of a second.

The nod was so small it was barely a movement at all.

She heard Halesia begin to say something gracious to Nish as the door closed behind her.

---

The corridor outside was empty and cool, and Siv allowed herself exactly four fast steps of genuine panic before she locked it back down and broke into a purposeful stride toward the estate's front approach.

Minaka had not been hurrying. Siv caught sight of her just as the woman turned the far corner of the main corridor that led toward the outer courtyard and the shuttle landing pad beyond it. Her pace was measured; she moved like someone who had already finished a task and was simply in the process of leaving it behind.

“Peer Minaka,” Siv said, referencing that she was also a 1st Order Maid when not a Mistress Apprentice.

The woman stopped but did not turn immediately. There was a pause, brief but present, and then she turned on her heel and faced Siv with that still, unreadable expression.

Siv stopped a few paces away and kept her voice level.

“I would ask a few minutes of your time.”

Another pause. Then Minaka inclined her head. Not warmly. But she inclined it.

Siv chose her words with the same care she would choose footing on uncertain ground. “May I understand why you have refused my master's invitation? Did I not convey to you his sincerity, of safety, with no design upon you or the others?”

For a moment she thought Minaka might not answer, but she spoke. “He may speak of no design, but how can a human be trusted? Let alone any of those in that room. My estate and house are of history and of secrets. Every house has tried to vie for our favor or coerce us into obedience, to use what we know for their own gain. Why would this be any different?”

She said it without heat. That was somehow the most unsettling part.

“Lord Henry is not like that,” Siv said.

Minaka's expression shifted into something like amusement. “A Terran? Really? I would not have expected you to be so naive, Peer Siv.”

Siv stood very still for a moment. Then she made a decision. It was probably reckless. Maevin would have thought carefully about it for at least ten minutes before committing. Siv gave herself three seconds and moved.

“Come with me,” she said.

---

The southern garden was not the estate's most impressive space. That distinction belonged to the formal courtyard near the entrance with its sculpted hedges and fountain that caught the light at dawn in a way that made visitors stop walking. The southern garden was where things actually grew, vegetable beds, herb rows, the stubborn sprawling tangle of something that Burdak had been cultivating and refused to explain. It smelled of turned earth and something green and faintly sweet, and the evening light came through the trees at the garden's edge in long, low bars of amber.

Siv slowed as they approached the garden wall and held out a hand, briefly, to stop Minaka beside her. She positioned them at the corner where the wall's shadow was deep and the sightline through the garden gate was clear.

Lord Henry was on his knees in the third vegetable bed.

He had what appeared to be dirt on both forearms up to the elbow and was pulling weeds from the base of a row of something leafy with the focused enthusiasm of a man who had absolutely no intention of returning to his paperwork. Two maids worked nearby, one on each side of him, and the sound of their voices drifted across the garden in the evening air.

He was laughing. Something one of the maids had said had caught him entirely off guard and he had sat back on his heels and laughed with his whole face, with no performance in it whatsoever.

The maid was grinning, far too comfortable for someone working with a lord of an estate, but that was the point Siv was trying to make.

Henry said something back. Siv couldn't catch the words but she watched the maid laugh again. Henry went back to his weeding. He did not look up toward the wall. He had no idea anyone was watching.

Siv looked at Minaka. The woman was very still. Her scarred face was turned toward the garden and her expression had changed in some way that was difficult to name. The electronic eye moved, tracking slowly across the scene. The dark eye beside it had something in it that it hadn't had before. The silence stretched out between them, easy now in a way it had not been in the corridor.

After a long moment, Minaka exhaled through her nose. It was a small sound. Almost nothing.

“He has no idea anyone is watching him,” Minaka said quietly. It was not quite a question.

“No.”

Minaka was quiet for a long time. Down in the garden, Henry said something that made the maid cover her mouth with her dirt-covered hand, though she quickly composed herself, while Henry looked very pleased with himself.

Minaka watched this. She watched all of it.

Then she said, without looking away from the garden, “This one time.”

Siv turned her head.

“House Shova,” Minaka said, “will send a representative.”

She said it the way she had said everything else today, flat and even and without decoration. The weight on Siv's shoulders lifted and she almost took in a ragged breath.

“Thank you,” Siv said. She kept her voice just as quiet.

Minaka turned from the garden and straightened her shoulders. The scarred face was composed again, the moment tucked away somewhere Siv could not follow it.

“I will see myself to the landing pad,” she said.

Siv nodded and watched her go.

---

There was definitely a look of disbelief on everyone's face, especially Niva's, when Siv returned to inform them that House Shova would be participating. She did not go into detail, as it was time for everyone to leave.

The moon was shining bright as Siv looked over the belvedere wall, noting the maids returning in from their shift. She also noticed Abiva swatting the backside of a certain yellow-haired maid who had probably screwed up something yet again.

“I am impressed.”

Siv nearly came out of her skin at the cool voice beside her. Siv turned with a start to see Mistress Maevin standing there, looking out toward the woods in the distance.

“xikihanmaav,” Siv said with a quick bow. “I did not see you there.”

Maevin raised a hand to ward off the politeness and turned to look at the other girl. “House Shova has never accepted invitations. They have always sent a representative but never followed through.”

There was a glitter of curiosity in Maevin's eyes. “I would not have been confident that even I could have gotten them to agree. What did you do?”

Siv thought about it. Yes, she had gambled and it had paid off, but she had also exposed her master's private life in a way that could have been used against him. Siv would either be rewarded or tied to the pillar. So she lowered her head.

“You once told me that we must learn how to navigate things ourselves and to find ways of getting things done,” Siv said.

“Yes?”

“I have found a way.”

“You don't plan on telling me,” Maevin said with a hint of amusement and irritation.

“What sort of mistress would I be if I gave away my secrets?”

That did get a chuckle out of the imperious woman who ruled the estate with an iron fist.

“Go to bed, Siv. You've earned it.”

Yes. She had.