Eli Mydlarz

AI has changed the production function of software. Engineering execution is abundant and no longer the organising constraint. Scarcity moves upstream to decision making. Organisations built to coordinate broad human execution are now malformed.

Catching microservices brain

Engineering has been scarce for most of my career. Even great engineers could not replace whole teams. To build more software, we needed more engineers.

Adding engineers to a team or teams to a codebase had rapidly diminishing returns. Microservices gave us scalable surface area. By dividing software into independent codebases, we could add more pickaxes to the coalface.

The resulting topology was wide and sparse: many teams, services and boundaries, with enough independence to work in parallel.

I grew up in that world. I attended conferences with Sam Newman when he was presenting Building Microservices. At RealEstate.com.au, I built with the creators of Pact. I learned microservices from leaders in the field.

That is how I caught microservices brain: look at the business, find domains, draw boundaries, build squads.

Symptoms

People with microservices brain produced wide, domain-separated development organisations that depended on coordination – many people changing ostensibly independent parts of a larger system. Knowledge had to be distributed, interfaces stable and ways of working predictable.

We learned to value teamwork over genius. It was an age for structure and process, until AI changed the economics. The pickaxes became a laser beam.

We no longer need to manufacture architectural surface area to distribute engineers across it. We can go deep instead of broad. We can do with four people what once took twenty.

Software design

I have seen the benefits of curing microservices brain in the new Own Network. There are many operations across many vendors. The old instinct is to start with differences: split domains, integrations and owners. 

With a laser, we can reason horizontally. What operations recur? What is common in their lifecycles? What can be parameterised Vendors become configuration, not microservices. 

The system is radically smaller and easier to build, deploy, operate and extend. We can do better than use AI to produce vast quantities of last-generation software. We can produce next-generation software.

Staffing

When engineering was broad, we needed many people working closely on related parts of the same system. We staffed for collaboration, but as engineering narrows we must staff for brilliance. 

A great engineer finds representations that remove whole categories of complexity. They build models from which downstream decisions follow naturally. Previously, such brilliance was siloed by domain boundaries. AI amplifies it across the whole organisation instead.

Some collaboration skills we once prized are now harmful. Consensus building slows decisions. Shared ownership weakens strategic coherence. “Bringing people along” anchors the team to its weakest members. An instinct to draw domain boundaries isolates our best people and recreates the broad, slow topologies of yesterday. A desire for structure and process only pours concrete on very temporary local optima.

Making decisions

A new vendor integration takes weeks or even months to understand, negotiate and decide, then just hours to configure. The bottleneck has visibly and clearly moved from making software to deciding what software to make.

Product management is still organised around producing documents for a constrained engineering organisation that no longer exists. It must be reorganised around decisions.

Our central work is no longer coordinating broad human execution. It is making decisions.

People like to say AI doesn’t have taste, or judgment. This is tautologically true. Taste is human taste because we are social animals – we value what other humans think. Can we project humanity onto machines enough to value their taste and judgment? Not right now apparently, hence “slop”.

I’m not a dummy, so I won’t say we’ll always need humans in order to do this or that.

I’ll say we need humans to be the ones doing this or that, in order for other humans to care about it. Maybe we could do it without any humans, but it wouldn’t mean anything. Note how I didn’t have to say “it wouldn’t mean anything to other humans” because that is already implied.

AI can do anything but make us value its output. After all, capitalism is only price discovery for cultural value – for meaning.

It’s the humans at Fasset that create meaning, trust, and authenticity. Human experience, human taste, and human decisions differentiate our products from slop.

Humans are everything (but they should not write code anymore).

You can’t help people you don’t understand. No understanding + no trust = undifferentiated = slop.

“Companion” seems to be a dirty word, but if – like me – you believe AI can help people with real problems, then you need to look past the word. Many agents will rely on deep user knowledge and trust – how will you build it?

To help with code, doesn’t your coding agent need code context? It builds and leverages understanding far beyond your prompting. Without knowing about you and your life, what is AI supposed to do when you ask it why your wife is treating you like that, or how much you should worry about that mole, or how to be more present for your kids? What the heck does _it_ know?

No understanding + no trust = undifferentiated = slop. Build connections strong enough for the AI to learn from people in real time, then deepen that understanding asynchronously_. Use that understanding to help people, then stay engaged so you can learn from the result and help better next time.

I eschewed big parts of the AI hype cycle because I care more about finding ways to help _normal people_ (not weirdos like us). One important lesson: Memory is almost *always* important. You could be accumulating medical records over years and re-examining them after every quick health catchup, or giving good relationship advice because you know my girlfriend’s attachment style, or whatever, but you can’t help people you don’t understand.

I’m building for _understanding_.

“Now there’s too much code to review!” (lots of this going around in product companies)

You can increase autonomy and stop reviewing – get out of the loop with software factories. That tends towards slop – hard to sell, depends on your use case.

Alternatively, reframe: AI dev creates too much much *change* to review. It’s not only code, but behaviour, conceptual models, UX, architecture, dependencies – many things are changing and code is only one possible representation.

There are better change representations we could review to keep our mental models up to date, and quickly identify problems _and opportunities_. As an aspirational example of non-code representations of software, look at what the great ⚗️ Josh Price is doing to introspect built Ash applications with Clarity.

Why don’t we start producing change representations of this quality in our AI dev? I am using test trees and hexagonal architecture consistently at the moment, what representation could I be reviewing instead of the test-trees I use now? This is not a rhetorical question – if you know, tell me.

Developing ways to represent changes from unsupervised agentic work _is extremely high leverage and badly neglected_ – what a waste! Is anybody working on this, or wants to work on it?

Generated example below.

I still can’t believe how well this works. My research flow produces great output with a cheap model _and thinking turned off_.

It draws on my recent Git history (lots more could be pulled in), reflects on my work, and does repeated cycles of research and reflection to identify and distill new insights on how to improve my current work.

I regularly consider and apply the latest research to my AI projects, so this is really helpful for me.

https://github.com/elimydlarz/thinker-cli

“Seems like a complicated approach? You don’t need to preserve some code that maps the assistant role to the wrong label and then patch over it with more code. Solve by subtraction or modification – don’t keep adding just to avoid making changes. Change is good. Codebases evolve. Evolve this one to make the change easier.”

Sometimes I want to think deeply about something, write thoughtfully, have the other party consider my point of view, reflect on their own perspective, and write a meaningful reply.

Those conversations align our thinking and advance our work _conceptually_ and strategically so that day to day decisions fall out naturally.

But when I write deeply, most people want to jump on a call right away, resulting in shallow conversation and more calls. We might make some progress, but the deepest questions at the root of our work remain unanswered. Calls are great, but they don’t replace _thinking_.

This is a cry for deep thinkers and people who _like reading and writing_ – let’s be friends!

It doesn’t matter whether SDD is “Agile”, “agile”, or “waterfall”. It could be used in any of those ways.

Also I think the whole thing is a little funny. “Spec driven” meaning you specify what you want? Is there any other way? All prompting is specifying.

Real discussions are hiding in these topics, trapped behind stuck-in-the-past arguments about semantics.

Even though I am doing lots of AI dev, I am more interested in building next-gen software than implementing last-gen software more quickly.

Next-gen software could be more generalisable. A strong core agent + strong memory + gen UI + self-inflating internal (to the agent) deterministic software may solve many different problems with minimal or conversational customisation.

I hope the need to write similar software over and over again as quickly as possible can be mitigated instead of serviced, if we look forward a little further.