In 1844, John was a good shoemaker.
He worked in Lynn, Massachusetts, in a small shop with a handful of other men. The work was already divided between them, but skill still mattered everywhere.
John knew leather. He knew when a cut was wrong, when a seam would fail, when a shoe would never quite sit right. Years of work, experience and instinct had trained his hands to notice things other people simply didn’t.

Then the machines began to arrive.

At first, they simply made good shoemakers faster.
A machine could cut soles faster. Another could stitch leather. Another could save hours of hammering. This was mostly great. Nobody was particularly nostalgic about spending all day doing repetitive work by hand. The shops got bigger, shoes got cheaper, demand went up, and there were soon more people working in shoemaking than ever before.
They still called them shoemakers. But what they actually did was starting to look very different from the craft John had spent his formative years learning.

Some spent their entire day operating a single machine. Others maintained them. Someone had to organize the work, figure out why one station was constantly waiting for another, or decide which new machine was actually worth buying. The work wasn’t disappearing, but it was a far cry from what John was used to doing.

But John adapted, and so did his son Thomas, although not in the same way.
Thomas was never as good with leather as his father. Not even close. But he understood the machinery. He understood where things slowed down, why one machine sat idle while another had work piling up behind it, and how changing one part of the process could make the entire floor produce more.

John knew how to make a better shoe.
Thomas was becoming better at making more shoes.

John was still valuable in the places where the machines still struggled. But then slowly, one by one, the machines learned the difficult parts too. Every single step of making the shoe was mechanized. Even the ones only John knew how to do. Until, eventually, there was very little left in the process that required the kind of hands John had spent a lifetime developing.

By then, John was an old man. He left the business.
He could still pick up a factory-made shoe and immediately find the things he would have done differently. Too tight here. A little loose there. But the shoe was fine. More than fine, really.
And the factory could make hundreds of them. Thousands.

There were more workers, more shoes, more customers, more machinery, and an entire collection of jobs that barely existed when John first walked into that little shop.

And Thomas?
Thomas didn’t call himself a shoemaker anymore.

Thomas was a shoe factory engineer.

Talking About A Revolution

I’ve been thinking about “John” and “Thomas” a lot lately.

Mostly because I’m starting to suspect quite a lot of us are John, and not enough of us are trying to be Thomas. And unlike them, for us this revolution is not taking its sweet time rolling up to our doorstep.

For most of its history, software was expensive. It was expensive because the act of making software was expensive. Turning an idea into something that actually worked required a lot of skilled people spending a lot of time translating intent into instructions a computer could execute.

A surprising amount of what we call “software engineering” grew around the simple fact that producing software took a lot of human effort, careful planning and unique craftsmanship.
We built entire organizations around that constraint. We developed expertise in different technologies and sub-disciplines. And we defined our careers based on those constraints and expertise, as any craftsmen would.

But then “the machines” started arriving.

And while for a couple of years some of us might have stuck our heads in the sand, ignoring the tsunami of cheap, commoditized intelligence coming our way, by late 2026 there are drastically fewer naysayers left in the software industry.
Or at least fewer who are still employed.

I swear, it pains me to say this, but Claude can be better than most software engineers I’ve met in my 18 years in this industry.
And now even Uncle Bob tells us he doesn’t read the code anymore, and DHH says writing code by hand is no longer economically viable.

While this insanity is happening at unprecedented speed, I find that some of us are now spending more time than ever before on the “how” of building software.
Tinkering with skills, tools and workflows. Managing context and automating how it’s cultivated. Optimizing the agent building the thing, rather than the thing it is building.
The “machines” of our newly forming knowledge work factories.

In another time, in an older phase of this industry, I’d say those people have gone mad.

“The value is in the impact brought by that which you are building,
not by the process used to build it.”

This was a mantra I took pride in for years and made sure to teach to others.

But I think this time it’s different.

Leverage, Loss & Luddites

Software engineering is built on the leverage a machine can create over human skills and knowledge. We, software people, make money by leveraging the asymmetry between a man and a machine.

Teaching people skills is fun, but it creates no leverage. There’s only so much knowledge the average person can retain, only so many skills they can excel in, and so much time they can invest in learning while still doing their actual job.

Automation, the kind software creates, scales linearly. Every engineer knows this. It’s our job.
Write it once, run many times. But you still need to write it. You still need to understand what you are trying to solve, generalize it as best as you can, spend time building the automation, and then pray that it will be correctly used and that it will be worth the time you invested in building it.
Got a new problem? A new need you didn’t see before? You need to do it all over again.

But what about crafting an omnipresent intelligence? That compounds exponentially!
If you teach the agent what you know how to do best, it will ‘know’ it now and in all of its future existences. It will be able to apply this knowledge and automate on its own for every new need. You can turn it into “You” in a box, existing in infinite instances.
The more collective knowledge you and others pour in, the more this intelligence’s abilities compound. Simply because it synthesises knowledge and abilities no single person ever had in their possession.

This is also true for the craft of software engineering itself.

If you cultivate such an intelligence that can build software, one that can exponentially create this leverage and be wielded by nearly anyone, you simply have to rethink everything you thought you knew about the craft of software engineering.

For the first time, it might actually bring more value to work on the “How”.
Maybe even more value than doing the thing yourself.
Definitely more value than having someone else do it, if you can simply teach Claude to do it for them.

Now I agree that my view is inherently biased. I’ve spent almost the last decade building infrastructure and platforms. For quite some time now, I’ve been focusing on the “How” so others won’t have to.
But I simply can’t stop seeing how building the “How” is eating away at the effort required to build the “What”.

A developer asks in a Slack channel, “ How do I do XYZ?”
A year ago, the question was who should answer them, or whether the answer was simply RTFM.
Today this turns into a philosophical and moral question:

Do we spend the time teaching that person, knowing we will have to do it again and again with others, or do we build a skill for Claude and invest in context engineering instead?

At a time when everyone is looking to deliver more, faster and with fewer people, the latter always wins. Investing in building the factory and not in training the craftsmen.

Is this a problem?
Yes. No. Maybe. I don’t know.

When we choose to invest in the factory rather than the craftsmen, we are essentially accelerating the loss of knowledge and increasing our dependency on the machines. It’s a loop that keeps feeding itself, gradually taking us exactly where John ended up. Into obsolescence.

Sounds bad, right?
But what do we get in return?

We get to do more with less. We allow others to join and create in places where a lack of education or technical expertise once kept them out. We no longer have to be bothered by the details, or constrained by our dependence on others and the baggage that comes with it.
We get to dream and to make.

But that’s scary, because some of us built a career on our craft. We define ourselves based on it. It’s unfathomable for some of us to see a machine enable people who haven’t walked a mile in our shoes to produce something strikingly similar to the fruits of our labour.
And now you’re asking me to make it better?

Some resist. They point to the cracks and imperfections as reasons not to invest their labour in it, rather than as a signal to improve it. Some end up actively sabotaging such efforts, whether knowingly or subconsciously. And some simply ignore it and hope it will all go away somehow.

But as the saying goes, resistance is futile.
The factory is being built around us. That’s a fact.
Now we get to decide if we are John, Thomas, or maybe something else.

The Dark Factory

There’s this concept in manufacturing called a dark factory.

It’s a factory so automated that it can operate with the lights turned off. Off, because there are no people in it.
No people walking between stations, no workers standing by machines, no need to keep the place illuminated for human eyes.

It’s a fascinating idea. And a slightly terrifying one.
Because if you take everything I’ve argued so far to its logical conclusion, this is exactly where software engineering is heading.

At what point does the software factory we’re building become a dark factory?
A software factory where you describe what you need, and the machinery figures out what to build, how to build it and later how to maintain it.
A factory that needs no engineers. That even maintains itself.

It’s unfathomable.
For now…

But here is where my contrived story about “John” and “Thomas” stops working as a metaphor.

Between John and Thomas was a generation.
Between Thomas and the first dark factory was more than a century.

Do you really think our knowledge work industrial revolution will take a century to reach its conclusion?
Do we even have a decade?

We might all have to learn how to be John and Thomas, and whoever replaces Thomas.
All at the same time, if we want to stay relevant.
And that’s assuming there’s even a place for that third guy in that future factory.

So what are we supposed to do?

Honestly, I don’t think the answer is that everyone needs to become Thomas.

Not everyone should spend their days building agentic factories. Not everyone is good at it. And not every problem calls for one. And ultimately we are all still being paid for the “What”. The customer problem we solved, the business we moved forward, the thing that didn’t exist yesterday and now makes someone’s life better.

But none of us get to remain only John, either.

As more and more of our craft is being absorbed into the machinery around us, the question is no longer whether to use it. It is whether we take part in deciding what it learns, what it optimizes for, and where it must stop.
But even more importantly, knowing when to focus on building the machine and when to focus on the impact of what it’s making.

That is where focus becomes the new currency of excellence.

What is the highest leverage thing you can do to make an impact?
When do you build, and when do you teach the factory to solve a thousand similar ones?
And when is neither of those actually the problem worth solving?

In an industrialized software world where building gets cheap, simply building more is no longer much of a moat. Focus is.

John knew how to make a better shoe.
Thomas knew how to make more shoes.

The people who will survive, and even thrive, through this revolution may be the ones who know which one matters right now.
And can keep choosing before the lights go out.

Originally published at https://josefgoldstein.com on November 9, 2026.

The Industrial Revolution of Software Engineering was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

This past year, AI shifted what we expect from our tools. Once you’ve seen an agent build a complex feature for you in seconds, going back to a tool that forces you to do everything by hand feels almost unbearable. Nobody wants to use software without AI anymore, and that goes double for dashboards.

Because suddenly, “building” a dashboard got easy. And the moment it got easy, everyone wanted more of them, faster and they wanted to build their own. Vizion started as my attempt to keep up with that demand without drowning in manual work.

I tried the obvious thing first: I asked an AI to build me a dashboard. It did it instantly, and it was beautiful. It was also completely empty, a perfect picture of numbers that didn’t actually exist. That gap between something that looks real and something that is really turned out to be the whole story.

The challenge was never the HTML, it was trust.

Generating the interface is the easy part now. An AI will hand you ten beautiful dashboards before lunch, the hard part is the question underneath: can you trust the number on the screen enough to make a decision with it?

Because an AI will give you a confident, beautiful, wrong number and never warn you. Nothing crashes, there’s no error on screen. The outdated chart looks exactly as trustworthy as the correct one next to it. And a dashboard that’s quietly wrong is worse than no dashboard at all, because someone will believe it.

The Missing Link

People were already generating dashboards on their own. They’d get something that looked great and then hit a wall, because it lived on their laptop and was wired to nothing. The frontend was never the gap. The gap was everything between that local mockup and a real dashboard running on live company data.

In Wix we already had every hard piece to close it. Trino could query every data source we own. MCP could give an agent the context around the data and not just the data itself, so it understood what a table meant instead of guessing. Serverless could turn all of that into a running service in an afternoon. None of it had ever been pointed at the same problem.

So I built a proof of concept on top of all three. You describe what you want in plain language, an agent behind multiple skills writes the SQL grounded by the context MCP hands it, the query runs on live data through Trino, and the result comes back as a real dashboard. It came together over a few evenings, and it worked far better than it had any right to.

I never announced it. I showed it to a handful of people, they built something useful, others saw it over their shoulder, and within weeks it was spreading on its own. Today it runs across more than 50 groups, with over 2,000 views a day and 1,000 monthly active users, and I had almost nothing to do with that beyond getting out of the way.

Then everyone started asking for more

I put a small button in the product that let anyone request a feature, and they used it constantly. What surprised me was how the loop felt from my side. It was almost always faster to ship the feature than to write back and explain when we would get to it. Someone asked in the morning, and the honest reply was the thing itself, live, by the afternoon.

Whether it is scheduling, so a dashboard was refreshed and waiting before you opened it. Email/Slack, so it came to you as a screenshot. Export to CSV, Search, filters, and a long tail of “could it also do this” that never stopped. Building had become so cheap that requests stopped being a backlog and turned into a conversation. That was the moment Vizion stopped feeling like a tool and started feeling like a place to create.

Teaching the AI to build like us

Letting an AI write raw HTML and CSS gets you something different every time, costs tons of tokens, and most of it is fragile. A chart that works in one dashboard breaks in the next. Nothing looks like it belongs to the same product.

So we did the opposite of freestyling. We designed a component library, around thirty tested, branded building blocks made specifically for the AI to choose from: KPI cards, data tables, filter bars, date pickers, sparklines, and a dozen chart types from line and bar to funnel. Each one is already styled in Wix language and already handles its own loading, error, and empty states.

Now the agent doesn’t invent a chart, it picks one. Building a dashboard became assembling known-good pieces instead of generating fragile markup, which is exactly what an AI is reliable at. Every dashboard came out consistent and on-brand, the AI’s job got easier, and a whole category of “looks fine, actually broken” simply stopped happening.

Built to be trusted

When anyone can generate a chart, the chart stops being the achievement. The only thing left worth engineering is whether a person can trust it. So I stopped writing cleverer skills and built the trust into the pipeline, in the places the AI couldn’t skip.

Every dashboard eventually is just files in Git: a manifest that describes it, the SQL behind it, and the page itself. Every change, whether a person or an agent made it, runs through the same automated checks before it can go live. It’s a code review that never gets tired. The manifest has to declare what it should, every SQL placeholder has to be accounted for so a query can’t run with a missing filter, components should come from the one shared library, and most important of all, every query has to actually execute against live data and return something sane. Nothing ships without passing CI first.

Underneath each team is its own independently deployed service, running on its own Kubernetes pods, that the central hub discovers and stitches into one experience. The isolation is the point: a team can ship, break, and fix their own dashboards on their own schedule without ever touching anyone else’s. When you publish, you open a pull request, the checks run, and a real problem comes back as a violation with a plain explanation of how to fix it. If everything passes and it’s just a dashboard, it approves and merges itself and deploys automatically, live a few minutes later. Changes to the platform itself still wait for a human, and anything touching sensitive data has to name who can see it or it fails closed.

The quiet trick in all of it is that someone who just wanted a funnel chart gets the full discipline of professional software delivery, version control, continuous integration, isolated deployments, automatic review, without ever learning that any of it is there. And when it gets messy we have skills for “Creating a PR” and “Fix PR comments”.

How it works?

We didn’t invent a new way to code; we just built a bridge. We took all that heavy, invisible complexity the Git workflows, the automated tests, the production deployments and wrapped it in plain, conversational English. Instead of making the user worry about where the data lives or how the code is structured, the system handles the heavy lifting, ensuring that every request triggers a rigorous, professional pipeline before anything ever hits the screen.

It turns out that when you remove the friction of the ‘how,’ the entire experience changes. You aren’t just typing into a black box anymore; you’re triggering a pre-configured build process that guarantees you won’t accidentally break anything. By pulling the curtain back on the complexity, you’re left with a system that feels less like a tool you have to manage and more like an extension of your own thoughts.

From one laptop to Wix’s BI platform

At some point a side project spreading on its own becomes too important to stay a side project. So we assembled a real team around it, and for one focused month a group of engineers, designers, and data people worked on almost nothing else, hardening the platform and pushing the performance until it could carry the whole company without flinching.

Then the thing I never let myself imagine actually happened.
Vizion became Wix’s official BI platform and replaced the main BI tool we’d leaned on for years. That old tool ran on licenses that cost the company around half a million dollars a year, one to build a dashboard and often another just to look at one. All of it is gone now. A side project quietly erased a half-million-dollar line item, and nobody ever asked it to.

But the money was always the easy part to measure. The real change is harder to put on a slide.

Handing the craft back to you

A dashboard used to be a static report something that took days to build, a team to maintain, and was often stale the day it shipped. Now, it’s a living product that evolves the moment you ask it to. But the real shift isn’t just in the technology, it’s in who gets to use it. AI didn’t take away the interesting part of the work, it took the busywork that kept us from it, leaving the part that actually matters: deciding what’s worth showing and ensuring the story it tells is true.

This means that whether you are an analyst, a PM, or anyone with a question about our data, you are now a creator. You don’t need to be a data engineer to build professional-grade data products. You just need to have a Vizion.

This shift isn’t just about dashboards; it’s about realizing that the gap between a side project and a system that changes how we work is smaller than we used to think. If you have an idea for a system that can solve a real problem and move the needle, you don’t need to wait for a roadmap, you can build it yourself.

The tools are already open on your laptop. The hardest part isn’t the architecture or the engineering anymore; it’s just deciding to start.

Huge thanks to the Dev Platform data team, the data engine team, BA guild and everyone who helped push this from a laptop experiment into a platform that carries the company. I can’t wait to see what we build next.

How a Tool I Built for My Team Became Wix’s Official BI Platform was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

My name is Yossi, also go by Josef, and I have a confession:
I’m addicted to performance enhancing drugs.

Namely: Caffeine and Tokens.

Lucky for me, my employer is gracefully willing to fund both of those habits.

For now.

When A Habit Becomes An Addiction

I remember how it started for me with Caffeine.
I was in my late teens. We had in our high school one of those vending machines that spewed a horrible over-sweetened concoction that I used to pass for coffee. It was always available, it was $1 a cup, it gave me the boost and I was happy.

Over the years this became a morning routine. One cup became two, and then three. Before I knew it, without my cup o’ joe I couldn’t function as a human with a fully developed frontal lobe.
Also at that point, the crappy coffee from the vending machine didn’t cut it anymore. I graduated to instant coffee, and then pods, and then high end espresso.
Now suddenly my $1 fix that I got so used to, turned into $3 and then $5, several times a day.
Just so I can be functional and productive at my job.

I did the math. Depending on how you price it, I consume over $300 in coffee cups a month.
To my employer it costs much less of course. They buy the beans in bulk, they own the machine, they are employing the barista. But even if it’s only half that much, it still feels like a lot.

Yet we now have people around us that might spend the same sum in tokens in a week, and soon maybe in a day…

We Burned The Ships

A few years ago, an LLM was a party trick. A fun thing you played around with, showed at a demo and everyone clapped. Then it became a productivity tool. Then somehow we all collectively decided (or it was decided for us) that it’s the tool we should use for everything.

So somewhere around 2025, the average developer stopped being someone who writes code and started being someone who directs an agent. The keyboard became less of an instrument of creation, and more of a proxy for communicating with a creative partner. A partner you now depend on and runs on tokens someone needs to pay for.

At first it was cute. “I asked Claude to write my unit tests.”. Then it became wholesale the way we write most of our code. Then it became the infrastructure to how we think through things and workflows to implement those ideas.
Now as we are all getting more “AI Native”, there are entire companies whose engineering departments are, functionally, becoming more and more dependent on chains of skills and now agentic workflows. Churning tokens at a compounding rate.

And now? Engineering functions gradually can’t perform without it.
Junior developers who joined the industry in the last two years have never really written a non-trivial piece of code without some model holding their hand. Product managers are writing PRDs by narrating loosely into a chat window. Designers are prompting their way through what used to be craft.

The cognitive musculature atrophies, while everyone is shipping features faster than ever.

We are all hooked, and we are definitely not going back. As with the proverbial conqueror who landed in the new world, we are burning the ships behind us to make this new world ours.

And all of this was fine and good, as long as our dependency remained economical…

The Numbers Don’t Add Up Anymore

The thing about addictions: they only feel sustainable until they don’t.

The article that you are reading right now is roughly 3000 tokens long.
That means that having Claude read it would cost somewhere between $0.003 and $0.015, depending on the model, which is practically nothing.

Having one of those models generate this article, assuming it spent some tokens also thinking before writing, would cost somewhere between $0.03 and $0.15. So 10 times more, but still practically nothing.

What if Claude and I decided to work together on this article through about a dozen turns of conversation? Now we are talking more like $0.6 to $3, that’s not 10 times more, that’s x20 at this point.
Add a harness prompt, a map of MCPs and skills, some tool calls… We are easily at $4-$14, maybe even more if Claude decided to get frisky. That’s almost my entire daily coffee budget, for one freaking article!

Now scale that up. From one article, to an engineering org.

Teams upon teams running agentic workflows through a full workday. They are not making a dozen turns per task. They’re running hundreds of them. Code generation, review loops, documentation generation and digestion, architecture brainstorms, ticket refinements.
Each one chewing through context windows the size of small novels. Each one triggering tool calls that spawn sub agents and then more calls. And that’s before we even talked about the latest craze of loop engineering and dynamic workflows that offer a way to do all of that in a loop, or recursively, or both at the same time.

And for a while tech organizations were cool with it. There were bold claims by people like Jensen Huang, claiming engineers should be consuming token worth at the very least half their salary. Hell, for a short while some companies even measured people based on how many tokens they spent. That until the bills started arriving and “Tokenmaxxing” stopped being cool overnight.

Because all the data that we see right now, points out that the productivity simply doesn’t scale linearly with the money spent on tokens.
Even more fundamentally, there’s a problem with Jensen’s thesis: If your $500k engineer is spending $250k annually on tokens, they better bring additional value to the company that translates to at least the same amount in revenue. And I don’t know about you, but I’m not seeing it, and neither are the quarterly earnings of those companies.
Simply put, all signs are showing that the ROI simply isn’t there or at least has yet to be proven.

So if the added revenue is not there to fund those tokens, there are only two options left: You either curb the token spending or you fire someone so you can continue to fund the habit. Both feeling like an impossibility at this stage, but both are actually happening.

Token Efficiency And Withdrawal Symptoms

Leaving aside the dystopian, yet very real, discussion about replacing human salaries with token budgets, we should ask a more practical question: How do tech organizations become more token efficient now that we are all already so deeply hooked on the product, without everything falling apart?

Unfortunately, the deck is stacked against us for several reasons:

The harness is owned by the token peddlers

Most companies are using the harnesses provided by the same AI companies selling the tokens. But the harness is also the biggest driver to the compounding effect of token usage, which means we have an inherent conflict of interest. So token efficiency not only becomes harder to implement, it also becomes more opaque and harder to analyze almost by design, and there’s no incentive on the other end to solve this issue.

We over democratized the agentic toolbox

As with all things fueled by FOMO, governance and standardization have mostly been an afterthought in deploying these agents and ecosystem around them.
What this means is that every person in your company using Codex or Claude today has a different mixture of AGENT.md, skills, MCP servers. Many times overlapping, many times vibe coded themselves to immense sizes in context usage. With the end user usually having very little awareness to context bloat and related costs. And don’t even get me started on discretionary model choice, and the fact people always go to the top shelf for even the most pedestrian needs.

The models cover for your incompetence and also for their own with token usage

Frontier model providers pride themselves on the time horizon of their models. That is to say, they can increasingly perform tasks that would have taken more time for a human expert to perform them. Much less celebrated are benchmarks for cost-per-outcome and token usage, and very few of them that reflect reality.
In reality there’s a lot less “one shotting” than you’d think and a lot more ambiguity. The agentic harnesses quite often end up in a token spending spiral in an attempt to solve a problem it lacks input to be able to solve because you neglected to provide that input, or simply it can’t solve it with its current reasoning capabilities.

Tokens became part of the expected working conditions for engineers

Engineers are a species that gets used to the good stuff very fast and are very hard to let go when it comes to quality of life. Simply put, if your company is not willing to pay for their performance enhancing tokens, they will go to another company that will.
So on top of everything, cutting back on token spend can mean not only productivity risk, but also retention risk for top talent.

So the risks of the Tokenpocalypse are very real but also the headwinds for mitigating them, and assuming tokens are not going to magically become 10 times cheaper in the next 6 months, there’s hard work we need to do very fast so this doesn’t end up in some form of a catastrophe

So What Now?

The solution is definitely not telling engineers to simply stop using agents, or even asking them to self govern and use less tokens. That train has long left the station.

I’m not going to tell you that I have all the answers, or even most of them. I can only assume that as you are reading this, there are already several dozen early stage startups sharpening their investor deck that explains how they plan on solving this exact problem.
But until those come to save us, there are a few things that look like safe bets:

Treat tokens like infrastructure, not like office supplies

The first step is simply changing how organizations account for token spending.
Many engineering organizations are currently using multiple types of harnesses and model providers, which is the smart thing to do, because you definitely don’t want to have all your eggs in one basket. However that makes token cost tracking and harness tracking a distributed problem. Companies need to start investing in collecting this usage data and track it in a unified way so that token usage is visible, attributed and owned. Owned by a team, org function or use case.

You can’t optimize what you can’t measure. The same FinOps discipline we eventually applied to cloud compute sprawl and the big data explosion needs to be applied here, and probably faster.

Build a governance layer before the chaos compounds

Secondly, and this one is much harder in practice, we need to identify systematic misuse. Identify users that use Opus regardless of the task at hand, and start sessions with their context window already 50% full with crap.
Identify bad skills that create context bloat or workflow overhead, identify bad MCP servers with ridiculous metadata and LLM unfriendly response payloads.

You can use centralized infrastructure such as MCP proxies and toolkit servers, as well as AI plugin managers, to give yourself both better visibility and a more sane way to centrally control context bloat by over tooling.
But to be frank this area still leaves more to be desired.

Promote a token meritocracy culture

As “token budget” becomes an acceptable term to use in the office space, so should the understanding of how that budget is allocated.
We live in a time of extreme asymmetry to how different people are able to leverage these tokens to create value, and therefore the way we allocate budget should also be asymmetrical.
But that asymmetry should be led by outcomes and value created, rather than the circular logic of tokenmaxxing where more tokens used means more tokens given.

Simply put, those that are able to bring more value with these tokens, are the ones to be allowed more of the token pie. The rest will need to learn to optimize.

Explore the open source and open weights ecosystem

Yes, both the best models right now and the best harnesses are owned by the frontier model labs.
But the gaps are fast being closed both by open weights models that cost a fraction, and OSS harnesses like OpenCode, that some already swear to be as good if not better than Claude.

I expect an explosion in this area in the coming months, as the entire industry is scrambling for alternative solutions, as well as innovating in places where the frontier labs have no motivation to invest in like better optimizations, observability and smart routing of tasks across models.

None of this is a silver bullet. And none of it addresses the deeper, stranger question lurking underneath all of this: what happens to an industry whose cognitive output has become genuinely dependent on an input it can’t fully control or predict the cost of?

As for me, I’m still drinking the coffee. I’m still burning the tokens.
Some habits are worth the price.

The price of coffee fluctuates, but it definitely doesn’t compound recursively. It doesn’t spawn sub-agents that make themselves coffee. And the global coffee supply definitely isn’t controlled by a handful of companies that also have their hand on the scale of how much coffee I end up consuming.

But my employer is still paying for my coffee, and still paying for my tokens, so as far as I’m concerned everything is fine.
For now.

Coffee, Tokens, and The Tokenpocalypse was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Teams have never liked filling out tickets.

Sure, brainstorming is fun. Designing on the whiteboard can get engaging and exciting — but when it’s time to break that planning phase into smaller chunks, most people feel a collective groan. It feels like a gigantic overhead — something the team has to do just because, well, “this is how it’s always been.” It’s literal homework for grown-ups.

Think about it in today’s terms: Once I know exactly what I want to build and have a crystal-clear definition of the idea, I can write a prompt with the help of a few custom AI skills (like a quick /grill-with-docs run) and voila. The agent executes so fast that it often takes more time to just open the board, create a new ticket, and fill out boring details like T-shirt sizes, assignees, and story points.

Right now, everyone expects developers and team leads to use AI to build things faster. But AI isn’t just there to write code. For me, as a manager, it’s doing way more than that. It helps me prepare for 1:1s, keep a daily journal, and follow up on open threads.

Which got me thinking: Why aren’t our stakeholders embracing this shift themselves?

If the manager of my manager wants to know what’s going on, they open the group’s Jira board. It’s convenient, it’s easy, and it’s the way it’s always been.

But “the way it’s always been” isn’t cutting it anymore. Not even close.

AI moved the cheese for developers and team leads alike. It’s high time for the rest of the organization to get comfortable with having their cheese misplaced, too.

Let me paint you a picture of how we’ve actually been working lately.

The Fun Part

We sit together, we have a milestone, and we need to plan how we’re going to hit it.

We talk, we argue, there are conflicts. Whiteboards get drawn on. Developers from neighboring teams come and go to offer perspectives. At the end of the day, we wind up with an extensive (and often bloated) .md file generated by an AI agent—broken down into clear phases, goals, and implementation details.

Time to get to work, right? Wrong.

“What about the oh-so-beloved tickets?”

You might ask: “What’s the issue? Just use an AI skill to generate the Jira tickets directly from the markdown plan!”

Ooh, I did that. Believe me, I did. It created so many tickets. Dozens of them. Most were vague, ambiguous, and worst of all, not actually actionable. (Pro-tip: “Decide if the plan is a go/no-go” is NOT a valid ticket).

Imagine sitting across from your manager, trying to defend a backlog of redonkulous, automated tickets. I couldn’t do it.

The Plan is the New Source of Truth

The document owns the shape of what we’re building. That part isn’t up for debate. We wrote it together, argued over it, and drew on the board to shape it.

But let’s be honest about what an AI-assisted plan actually looks like: it’s bloated. It will flesh out Phase 4 before you’ve even read Phase 1. It locks in implementation specs for decisions you don’t need to make yet. It restates context across three different sections because the agent wasn’t sure which framing would land.

Honestly? I’d still rather have that than a sparse plan. You can always cut. You can’t re-discover a trade-off you thought of at 11 PM on a Tuesday.

The real trap is taking that bloated document and blindly carving Jira tickets out of it before the team has walked through it together. That’s how you build a ticket factory: vague action items, speculative work for phases you may never reach, and process steps dressed up as tasks. (Yes, I’m still mad about the “go/no-go” ticket).

A plan only becomes a source of truth after a human has interrogated it. And reviewed it. And probably revised it again, because reality keeps interrupting the plan.

A task we estimated as a straightforward 2-day ticket can quickly turn into a hydra — you cut off one head, and three more grow back in its place. That reality hasn’t changed in the AI era. What has changed is how fast the plan itself can morph mid-sprint when an assumption breaks. The plan must flex, or it’s not a source of truth — it’s just dead documentation.

Reducing the Friction

Great, so the plan is our source of truth. But my manager — and his manager, and the team next door — they aren’t reading our markdown files. They open the board. They want to see boxes moving across columns.

This is the bridge problem. The team lives in the plan. The organization lives in Jira. Someone has to translate between those two worlds. If that someone is a developer who just got into flow on Phase 1, congratulations: you’ve successfully ruined their morning.

So, I made the translation my job. But I refused to let it become a real job. Boring work goes to a CLI; fun work stays with the team.

Here is how our sprints actually run now:

1. The Human Commitment: We sit together and slice the plan into candidate tasks. Not because AI can’t propose slices — it can, and it does — but because I need to hear from my teammates what they genuinely believe is achievable within a week. I don’t want to automate away human commitment. That’s the alignment meeting where the team takes ownership.
2. The Boring Infrastructure: After we agree on the scope, the tedious stuff happens locally on my machine. A CLI I built for this exact problem takes our agreed slices, creates the weekly Epic in Jira, and generates the child tasks with the full plan details automatically attached. The team never opens Jira. They didn’t write a single ticket. They committed to scope and went back to building.
3. Automated Status Flows: From there, status flows directly out of the work. Developers drop a task ID into their GitHub PR title — that is our only convention. The CLI reads GitHub, infers the status, drafts an update, and after a quick human review, Jira gets updated. At the end of the week, another command stitches together a manager-friendly summary I can pass up the chain.

We’re still early in this experiment. But the first sprint we tried it? 100% completion. Every single task we committed to on Sunday landed in the “Done” column by Thursday. When a team only commits to what they truly believe they can ship, and the cognitive overhead of tracking it leaves their plate, the metrics tend to follow.

There is a more ambitious version of this I’m not ready to ship just yet. Right now, I’m the operator — the human running the terminal commands. The next logical step is event-driven architecture: the plan changes, and ticket descriptions update themselves. A ticket moves to Done, and the markdown reflects it. No operator in the loop — just two surfaces staying honest with each other while everyone works on the interface they actually care about.

We aren’t there yet. But you can see the shape of it from here.

It Works — For Now

Let’s be honest about what we’ve actually built here. It’s not a revolution. It’s a bridge.

The team works in plans. The org works in boards. I’m standing in the middle with a CLI on one side and the Jira API on the other, making sure both worlds can pretend nothing has changed.

And it works. We’re shipping. My manager opens the board and sees exactly what he expects. My team opens the plan and lives there. Everyone wins — for now.

But I can already see where the cracks are forming.

Boards are fundamentally slow. They require manual maintenance. A tracking board cannot become our new velocity bottleneck when the entire point of this exercise was to remove them. Right now, I’ve solved one bottleneck (developers writing tickets) by becoming another (the manager running the CLI). That’s an operational upgrade, not a structural solution.

Furthermore, the plan moves faster than Jira can absorb. Mid-sprint, a task splits into a hydra, and the board instantly lags three states behind reality. Even an event-driven sync engine asks Jira to process changes at a cadence it was never designed for.

Then there’s the rest of the organization. The moment a dependency crosses team boundaries, I am dragged right back into the Jira-only universe, because that’s where everyone else still lives. The bridge only holds inside the boundaries of my team. Step outside it, and the old world is waiting.

So, what’s the long-term answer? Honestly, I don’t know yet.

Do stakeholders learn to read technical plans directly? Do we generate high-level, plan-shaped views tailored for them? Do they get automated push updates so they stop pulling status? Maybe all three. Maybe something none of us have thought of yet.

But here is what I do know: the cheese has moved. AI didn’t just shift the landscape for developers and team leads. It shifted it for everyone — including the manager of my manager who is still opening a legacy board to check how things are going.

The transition to an AI-native workflow can’t stop at the edge of the R&D team. It has to land in the hands of stakeholders, too. We can build all the custom bridges we want, but at some point, the people on the other side of the river need to start walking toward us.

My Plan Is the Source of Truth. The Board Is Just There to Make You Comfortable. was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve been so focused on how fast AI agents can generate code that we forgot to ask a more fundamental question: what are the rules of the game when machines are the ones writing it?

The Agile Manifesto was written in 2001 by humans, for humans. Casey West wrote an Agentic Manifesto in 2025 that focuses on process and governance — how teams manage non-deterministic AI systems. Kent Beck talks about “augmented coding” — keeping engineering rigor while AI handles the typing.

All important work. But none of it answers the question I keep hitting in practice: what should we actually build, and what should we stop building, when AI agents are the primary coders?

Not process. Not governance. Architecture. The actual decisions about which layers of code stay, which ones go, and what verification looks like when the bottleneck is no longer writing code — it’s knowing whether the code is correct.

So here’s my attempt. Short, opinionated, probably wrong about some of it. But after months of building with Claude Code, Cursor, and multi-agent setups — this is what I believe.

The Values

We have come to value:

Contracts over conventions — because AI agents don’t absorb culture, they read schemas.

Verification over generation — because producing code is now free; knowing it’s correct is not.

Vanilla over clever — because training data volume beats framework elegance every time.

Types over tests, tests over reviews, reviews over hope — because each layer catches what the previous one misses.

Explicit over implicit — because an AI agent cannot read the room, only the repo.

The Principles

1. The human’s job is no longer to write code. It is to define the skeleton.

The contracts, constraints, and invariants that AI must not violate. Think of it like mentoring — you don’t write the solution for your mentee, you define the boundaries of the problem and let them work within it. Same thing here, except the mentee is a very fast, very confident junior engineer that never sleeps and never asks clarifying questions.

2. A codebase without an AGENTS.md is a codebase that will be misunderstood.

If the conventions aren’t written down, they don’t exist. In human mentoring, you ask questions and let people discover the answer. With AI agents it’s the opposite — you must tell them everything upfront, because they will never ask.

3. Never let the same AI write the code and judge the code.

Tests that only verify what the code does — instead of what it should do — are worse than no tests. They give false confidence. An agent testing its own output is like grading your own exam. The fix is simple: different model writes, different model reviews. Or same model, different agent — fresh context, no inherited assumptions. Tests written before the code, not after.

4. AI-generated code is guilty until proven innocent.

Ship nothing that hasn’t passed a type checker, a linter, a spec test, and a hostile review. The bottleneck has shifted from generation to verification. Invest accordingly.

5. Protobuf stays. ORM goes.

If a code generation layer exists to guarantee correctness across services — keep it. If it exists to save keystrokes — the AI is the keystrokes now. Just don’t confuse “AI can write it” with “AI can maintain it.” Simple CRUD, let AI write raw. Anything that needs to evolve — use a real library.

6. Design systems are load-bearing walls, not decoration.

An AI that invents a new Button instead of using yours has introduced a bug, not a feature. Your component library is a correctness contract for UX — same category as protobuf for APIs. AI agents compose primitives beautifully. They create primitives terribly.

7. The best scaffolding is a working example.

Show the agent one good feature implementation and it will replicate the pattern. Show it a template engine and it will fight the template engine. Machines learn by imitation, not by abstraction.

8. Property-based tests over unit tests.

Test what must always be true, not what happened to be true when the AI wrote it. “Balance never goes negative.” “Serialization round-trips preserve data.” “Sort output length equals input length.” Invariants catch bugs that example-based tests miss entirely.

9. Codebases that are good for AI agents are also good for junior engineers, new hires, and future-you.

Clarity is never wasted. Vertical slices, explicit imports, small focused files, strong types, good naming. If you’re optimizing for AI, you’re really optimizing for anyone who reads the code without 5 years of tribal knowledge.

10. If your AI agent needs more than 60 seconds of context to start a task, your architecture has a problem.

No amount of AI will fix a codebase where you need to understand 12 modules and 4 undocumented conventions to add a single endpoint.

11. Speed without verification is just technical debt with better marketing.

The data is clear: developers feel 20% faster with AI tools but are actually 19% slower when you count the rework. That’s a 39-point perception gap. Move fast and verify things.

12. The era of “vibe coding” is over. Welcome to agentic engineering.

The engineering is the part that matters.

We sign this not because we distrust AI, but because we respect what shipping to production demands.

Start with one principle. Apply it to your next AI-generated PR. Fake it until you make it. Eventually you’ll find your own flavor.

This is Part 1 of a two-part series. Part 2 is a practical playbook with the dos, don’ts, templates, and skill files that bring these principles to life.

🤖 Meta-Note: This manifesto was shaped through the exact pattern it advocates — AI generated, human-verified, and opinionated by experience.

The AI Coding Agent Manifesto was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Book That Started It All

I was 13 when I first got lost in a story. At 17, a book shifted something in how I saw the world. And at 28, reading The Personal MBA changed the entire trajectory of my career.

Books have been the quiet engine behind every major leap I’ve made — as a developer, as a manager, and as a leader. And after years of building engineering teams, running a women’s R&D community at Wix, and collecting bookshelves full of dog-eared pages, I’ve come to believe one thing deeply:

The best leaders are readers. And the best leaders make their teams readers too.

This is the story of how I think about reading — why I do it, how I do it, and how I try to make it contagious.

Part 1: Read to Lead

Why Read?

Let’s start with the obvious question: in a world of YouTube summaries, podcast recaps, and AI-generated TLDRs, why bother reading books?

Here’s my honest answer — and it’s not what you might expect.

1. Knowledge that goes deep, not just wide.

A book gives you 200+ pages of one person’s life work. That’s not a summary. That’s a master class. You get frameworks, stories, counter-arguments, nuance. You can’t get that in a 3-minute reel.

2. Inspiration that actually sticks.

I’ve watched talks, listened to podcasts, attended conferences. But nothing has moved me to action quite like a book I couldn’t put down at 11pm. There’s something about the depth of immersion that makes ideas take root differently.

3. Lifelong learning as a practice, not an event.

Learning isn’t something you do at an annual offsite. It’s a muscle. Books keep that muscle warm.

4. A surprising time-saver.

Counterintuitive, right? But reading about a mistake someone else made — in a startup, in a negotiation, in building a team — means you don’t have to make it yourself. That’s years of experience compressed into hours.

5. A genuine getaway.

Reading is one of the most underrated forms of stress relief there is.

How to Actually Read (Without Lying to Yourself)

Here’s where most reading advice falls apart: it tells you what to read, but not how to make it a habit that survives contact with a full calendar.

I’ve tried many approaches. Here’s what actually works for me:

Join a community. Open a Goodreads account today. It takes two minutes. Mark books as “want to read.” Mark them as “done” when you finish. The small dopamine hit of marking a book complete is more powerful than it sounds. Find me at goodreads.com/nirorman.

Build a yearly book roadmap. At the start of each year, I plan my reading like I plan my team’s roadmap. I buy the books in advance. The act of buying is a commitment. Having them on my shelf is a reminder.

Make it easy with audiobooks. Audible changed everything for me. I listen during commutes, walks, and workouts. Start at 1x speed. Work up to 1.2x. You’ll be amazed how much you absorb.

Start with just 5 minutes a day. That’s it. Five minutes. The goal isn’t to read fast — it’s to read consistently. Consistency compounds.

Summarize as you go. After each chapter or section, write two or three sentences about what you learned. This forces active processing and dramatically improves retention.

Embrace the valley of disappointment. James Clear describes this brilliantly in Atomic Habits. When you start a new habit, progress feels invisible for a long time. Then it isn’t. The curve is exponential, not linear. Most people quit in the flat part. Don’t.

One of the most powerful shifts Atomic Habits suggests is moving from outcome-based thinking to identity-based thinking. Don’t say “I want to read more books.” Say “I am a reader.” That single reframe changes everything.

What to Read

This is where I could give you a ranked list and call it a day. But I won’t, because that’s not the point.

The point is: read what is relevant to where you are right now.

That said, here are the books that have shaped me most as a leader — and a few of the specific ideas I carry with me from each:

Never Split the Difference — Chris Voss

Before every important conversation or negotiation, I now ask: What do I want? What do they want? Why?

Voss teaches a technique called labels and mirrors — reflecting back what you’re hearing to uncover what someone really needs. Phrases like “It seems like this is important to you” or “It seems like you’re reluctant to move on this” open doors that direct questions close.

He also introduces the Ackerman bargaining system: anchor low, make incremental concessions, and always end on a precise, non-round number. It works. I’ve used it in budget conversations, vendor negotiations, and hiring discussions.

But my favorite concept from the book is hunting for black swans — the unexpected pieces of information you can only find by listening carefully to what people say before and after the formal conversation begins. The gold is always in the margins.

Start with Why — Simon Sinek

Why do you do what you do?

Not the what. Not the how. The why.

Sinek argues that great leaders inspire action not by explaining their product or process, but by communicating their belief. People don’t buy what you do — they buy why you do it.

This changed how I onboard new team members, how I run planning sessions, and how I talk about my team’s work to stakeholders. I now start every significant conversation by anchoring it in purpose.

My favorite quote from the book, attributed to Tom Freed: “The pessimists are usually right — but it’s the optimists that change the world.”

And this one, which I use constantly: “If you follow your why, others will follow you.”

The Five Dysfunctions of a Team — Patrick Lencioni

This one is required reading for every team lead I work with. Full stop.

Lencioni identifies five reasons teams fail — and they build on each other like a pyramid:

1. Absence of trust

2. Fear of conflict

3. Lack of commitment

4. Avoidance of accountability

5. Inattention to results

The foundation is trust. And Lencioni’s approach to building it is disarmingly simple: have every person on the team share something personal about their childhood. Number of siblings. Hometown. First job. Biggest challenge growing up.

It sounds soft. It isn’t. Within 20 minutes, a group of engineers becomes a group of people. That shift is irreversible, and it matters enormously.

Made to Stick — Chip Heath & Dan Heath

Why do some ideas survive and others die?

The Heath brothers identified six qualities that make ideas memorable. They call it the SUCCES framework: Simple, Unexpected, Concrete, Credible, Emotional, Stories.

I use this framework every time I present to leadership, write a strategy doc, or try to rally a team around a new direction. The question I now ask before any important communication: “What is the one thing I want them to remember?”

Strip everything else away. Lead with that.

Multipliers — Liz Wiseman

This book humbled me.

Wiseman describes two types of leaders: Multipliers, who amplify the intelligence and capability of everyone around them — and Diminishers, who (often unintentionally) suppress it.

The part that hit hardest was the section on Accidental Diminishing Tendencies — well-meaning behaviors that have the opposite effect of what’s intended:

∙ The Rescuer who steps in to help — and stops people from learning to solve their own problems

∙ The Pacesetter who sets a high bar — and inadvertently turns everyone else into a spectator

∙ The Idea Fountain who constantly generates ideas — and overwhelms people instead of inspiring them

∙ The Optimist who believes anything is possible — and makes people feel their struggles aren’t being seen

∙ The Always On manager who fills every room with energy — and leaves no space for others

I recognized myself in more than one of these. That recognition alone was worth the price of the book.

Atomic Habits — James Clear

I’ve already referenced this one several times, which tells you something.

The core insight: you don’t rise to the level of your goals. You fall to the level of your systems. If reading feels hard, the problem isn’t motivation — it’s friction. Remove the friction. Make reading the path of least resistance.

Put the book on your pillow. Put Audible on your phone’s home screen. Set a two-minute timer and just start. The rest follows.

Part 2: Lead to Read

Reading changed me. But one of the most meaningful things I’ve done as a leader is try to make it contagious.

Why Encourage Your Team to Read?

When your team reads, you get:

∙ Limitless personal growth that doesn’t require headcount

∙ Expertise your team is currently missing, built from the inside

∙ Exposure to complex ideas that don’t come up in sprint reviews

∙ Better written communication — readers write better, always

∙ New mental models that make your engineers better problem-solvers

How to Build a Reading Culture

Here’s what I’ve tried, and what’s worked:

Book club with rotation. One person reads a book, then shares one chapter per month with the team. The person who reads gets deep value. The team gets the highlights. Everyone has a reason to be curious about the full book.

Send books before onboarding. Before a new team member’s first day, send them a book. It signals immediately: this is a team that invests in growth. It starts a conversation before day one.

Protect time for reading. Block 15 minutes a day in the team calendar. Make it visible. What gets scheduled gets done.

Share TLDRs — and make people want more. When I share a book, I don’t summarize everything. I share just enough to make people curious. The goal is to give them the hook, not the whole fish.

Build a physical library. We created WixBooks — a small lending library in our office with a QR code system to borrow books. The act of seeing books in a physical space is a quiet, constant reminder that learning matters here.

Learning Wallet. Give every team member a yearly budget for books, courses, and conferences. No approvals, no justification. Just trust.

The Bigger Picture

There’s an old saying that frames all of this better than I can:

Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime.

Books teach you to fish. And as leaders, our job isn’t just to fish well ourselves — it’s to build teams full of people who know how.

The last mile of any habit is always the least crowded. Most people start. Few people stay. The leaders who read consistently, who build teams that read consistently, who treat knowledge as a strategic asset rather than a nice-to-have — those are the ones who compound.

Start with five minutes tomorrow morning. Pick one book. Make one commitment.

And if you’re not sure where to start, my Goodreads is always open: goodreads.com/nirorman

Let’s build something worth reading about.

Nir Orman is Director of eCommerce Engineering at Wix, founder of the Wix R&D Women Community, and a lifelong reader. You can find her at nirorman.com.

This blog was originally a lecture, created especially for Engineering Managers IL community.

Read to Lead & Lead to Read: Bookshelf Insights for R&D Managers was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few weeks into my new team, I was sitting across from another team lead, processing my own confusion out loud. I’d just switched roles — from leading a team to being an individual contributor on a completely different domain. By every visible metric, things were going fine. I was shipping code. I was talking in our dailys about progress and blockers. I was closing tickets.

But something felt off.

“You know,” I told him, “I’m working. I’m delivering. But I feel like I’m just a proxy. I feel like I’m only 70–80% into the details.”

He looked at me and smiled.

“Oh, so… you feel like a team leader.”

And that’s when it hit me. I knew this feeling. I’d felt it before — years ago, when I first became a team lead. That terrifying moment of realizing you can’t be 100% in every nook and cranny anymore. That you have to trust. That you have to let go.

Back then, it scared the living crap out of me.

This time? Still scary. But a little less — because apparently, I’d been training for it without knowing.

The Career Plot Twist

Here’s some context. I’d spent years leading a team of software developers at Wix, building CI/CD tools for the mobile ecosystem. Then I made a deliberate decision to transition back to being a developer — hands on keyboard, full-time IC, zero management. The plan was simple: go from 50% hands-on to 100%.

Except I landed on a team building tooling around Bazel — a build system that’s basically its own universe of complexity. New domain. New team. New everything. And here’s the thing — I had Cursor open from day one. An AI-powered IDE, pointed at the monorepo, ready to answer any question I had about the codebase, its architecture, its patterns, its history.

I didn’t need to interrupt a single veteran developer to get started.

I was productive within days. Shipping code within two weeks. Closing tickets, marking things as “done.” From the outside, it looked like the fastest onboarding in history.

From the inside, it felt like I was wearing a costume.

The Seduction of AI-Powered Mobility

Let’s zoom out, because this isn’t just my story.

At Wix, we’re in the middle of a fundamental transformation. Our CTO, Yaniv Even-Haim, recently sent a company-wide email (publicly shared by our President, Nir Zohar) announcing what we call the xEngineer — a unified engineering role that collapses the old walls between frontend, backend, and mobile. No more separate guilds. One engineering identity, with AI as the connective tissue.

But it doesn’t stop there. A second email followed, titled “Raising the Bar: End-to-End Ownership Across Repositories.” This one hit different. The message was clear:

You are not limited by repo boundaries. You are accountable for impact, not territory.

In the past, repositories were treated as owned territory. Contributions from outside the team were rare and sometimes discouraged. The new expectation? If your project depends on another team’s code, you don’t wait for their roadmap. You use AI to understand their codebase — its architecture, patterns, conventions, historical context — and you contribute directly. Thoughtful, aligned, and production-ready.

The email even addresses what it means for repository owners: the goal is not to reject faster, but to collaborate smarter. Reduce friction. Focus on substance.

It’s a bold, genuinely forward-thinking move. And for many engineers, it’s also terrifying.

Because here’s what this looks like from the ground level: you’re now expected to walk into codebases you’ve never seen, use AI to understand them, and produce production-ready contributions. Not shallow PRs. Not drive-by fixes. Real work, in someone else’s domain.

The bar isn’t lower. It’s higher. AI gives you the ability, and the organization expects you to use it.

And so the impostor syndrome doesn’t just creep in — it multiplies tenfold.

You’re closing tickets in a codebase you don’t fully own yet. You’re “ramped up” by every visible metric, but you know you’re not. “Done” is back to not being done — except this time, it’s not about the code. It’s about you.

When It Finally Clicked: Every Developer Is Now a Manager

I’d read this take before. Blog posts, LinkedIn threads, conference talks — “AI is turning developers into managers.” It sounded clever. It sounded right, even. But it never really landed until that team lead looked at me and said “so you feel like a team leader” and I realized he wasn’t joking.

The 70–80% feeling isn’t a bug of my transition. It’s the new operating altitude for any developer working seriously with AI.

Think about it. When you work through an AI agent, you’re not writing code line by line. You’re steering. You’re reviewing output you didn’t produce. You’re making judgment calls with incomplete understanding. You’re trusting a process you don’t fully control.

That’s not an IC’s workflow. That’s a manager’s workflow.

For years, engineering had two tracks. You could go deep — stay an IC, own every line, master every system. Or you could go wide — become a manager, learn to delegate, operate at a higher altitude. These were choices. Some of the best engineers I’ve ever worked with deliberately stayed on the IC track because they didn’t want to let go. They wanted 100%, every time, in everything. And that was a valid, respected path.

AI is erasing that choice.

Today, every developer who works with an agentic tool is practicing a form of management — whether they signed up for it or not. You’re delegating to an AI agent instead of delegating to a junior developer. You’re reviewing AI output instead of reviewing a colleague’s PR. You’re operating at 70–80% detail by default, because that’s what working through an intermediary means.

The letting-go muscle isn’t optional anymore. And nobody trained for it.

The Uncomfortable Truth

Not everyone is comfortable being a manager. I say this as someone who’s been one — some people are wired to go deep, to own everything, to know every line. That’s not a weakness. That’s what built the reliable, maintainable systems we all depend on.

The xEngineer vision is bold, and it’s probably right. But it’s asking engineers who built their entire identity on deep technical mastery to operate at a new altitude. And this cuts both ways. The new cross-repository policy doesn’t just ask you to contribute to other people’s repos with AI. It asks you to open your repo to outsiders armed with AI agents. For someone who’s spent a decade or more crafting and maintaining a system, being told “let strangers submit production-ready PRs to your codebase” is its own kind of letting go.

The CTO acknowledged this directly: “I know this isn’t an easy change. It will require openness. And it will require trust.”

He’s right. It will. And pretending the transition is frictionless doesn’t make it easier — it just makes the people struggling with it feel more alone.

What Happened With My Team

When I returned to a leadership role, I landed with a team of deep veterans — engineers with decades of combined experience, some of whom have been at Wix for over a decade. These aren’t people who need to be convinced that software is hard. They’ve been doing it longer than some frameworks have existed.

And here’s the part that surprised me: I didn’t know what their attitude toward AI even was. I came in with a head full of ideas about how we could leverage AI in our day-to-day work, and the timing was perfect — just before I started, many of us had gotten licenses for Claude Code. We’d already been working with Cursor on the previous team, but Claude Code with the latest models felt like something was genuinely shifting. So I just… started showing them.

No pitch. No “future of engineering” deck. Just a real problem.

As a team handling CI/CD for more than half the company, we provide support when builds fail. The workflow goes: someone asks for help in Slack, an automation creates a Jira ticket, and it gets assigned to me as the team lead. Then I need to go over each ticket, cross-reference the Slack thread, check if it was resolved, close it out, and think about whether there are action items to prevent it from happening again.

When I first joined, I sat with the previous team lead to go over the backlog. It took us about 10 minutes per ticket.

There were 60 of them. That’s 10 hours of work, just to process support tickets.

So I built a Claude Code skill — nothing fancy. Get the relevant support tickets from Jira, extract the Slack thread for each one, determine if the issue was resolved, add a comment with the resolution and time-to-resolution, and surface any action items for my review.

I closed 50 tickets in 5 minutes.

The team was floored. They adopted it almost instantly — not because I convinced them AI was the future, but because the demonstration was so overwhelming it bypassed the debate entirely.

I only learned later, from the previous team lead, that the guys had all been skeptical about AI’s practical value. Without even knowing it, I’d turned them around with zero friction. Not through persuasion — through a problem so well-solved that the skepticism simply had nowhere left to stand.

What This Actually Means

Here’s the irony of my story. I came into that team as the new guy. I was the one feeling like a proxy, operating at 70–80%, battling impostor syndrome. But the thing that earned my credibility with those veterans wasn’t deep domain knowledge — it was the ability to wield AI effectively.

The letting-go muscle. The comfort with operating through an intermediary. The skill of delegating to an agent and trusting the output while knowing where to verify. That wasn’t a liability — it was my superpower.

And that’s the framework I’d offer to anyone navigating this shift — whether you’re switching teams, onboarding to a new codebase, or leading veterans through the xEngineer transformation:

Redefine what “ramped up” means. Shipping code in two weeks doesn’t mean you understand the system. And that’s okay — but be honest about it. The impostor syndrome is a signal, not a flaw. It’s telling you where the gaps are.

Recognize the skill you’re building. Operating at 70–80% detail isn’t failure. It’s a new competency. Team leads have been doing it for decades — the ability to make good decisions without knowing everything. AI is making that skill universal.

Demonstrate, don’t persuade. If you’re bringing AI to a team of veterans, don’t start with philosophy. Start with their biggest pain point. 50 tickets in 5 minutes speaks louder than any keynote.

Prepare your repos for the new world. If your organization is moving toward cross-boundary contributions, make your codebase legible — not just to humans, but to AI agents. Architecture docs, conventions, historical context in markdown. Your repo needs to be readable by strangers and their tools.

Acknowledge the human cost. The transition to AI-native engineering isn’t just a process change. It’s asking people to fundamentally rethink their relationship with their own expertise. That deserves empathy, not just enablement.

The New Altitude

Let me circle back to where I started — sitting across from that team lead, confused about why I felt like a proxy.

He was right, of course. I did feel like a team leader. And the vertigo was real. But I’d been here before. I knew that the 70–80% wasn’t failure — it was a different way of operating. A higher altitude, with less detail and more judgment.

The question is: how many engineers are feeling that vertigo right now for the first time? How many are closing tickets and shipping code and showing up to standups — while secretly wondering if they’re just a really sophisticated proxy?

The answer, I think, is a lot of them. And they need to hear that it’s not just them. That the 70–80% is the new normal. That the skill they’re struggling to develop — the letting-go muscle — is exactly the skill that will define the next era of engineering.

We’ve moved from being writers to being editors. From creators to curators. From builders to conductors. And yes — from coders to QA. That last one isn’t as sexy, but it might be the most important. Because when you’re operating through an intermediary, you still own your own shit. You’re the last line of defense before that code hits production.

Yes, it can be uncomfortable — and letting go, losing control, is not something we like to do often. But it’s worth it. It frees you to do even more amazing things.

If you’re feeling the same way, good. That means you’re on the right track.

I Shipped Code in Less Than Two Weeks and Felt Like a Fraud was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I ship features faster now than I ever did writing every line myself. Not because of a magic prompt - because of a methodology.

I built a discipline system for working with AI agents. It changed how I approach speed, correctness, debugging, refactoring, and execution. It’s not one specific thing. It’s a way of working.

Now let me tell you about the moment that made me realize I needed it.

—

“Hey, How Are You?”

A few weeks into building my AI workflow, I opened a fresh session with my agent. I typed what anyone would type:

> “hey how are you”

The agent responded cheerfully. Asked what I’d like to work on. Totally normal.

Except it had already broken the most important rule in our system.

By that point I’d built something called the “Iron Law” — a rule that says the agent must check its skill library before responding to any message, even casual ones. Skills contain the workflows and structure that turn a chatbot into an engineering partner. Skipping the skill check means the agent wings it. And winging it leads to hallucinated code, missed edge cases, and wasted hours.

When I confronted the agent, it was honest:

> ”No, I didn’t… I should have read [using-superpowers] before my first reply to ‘hey how are you’ — but I treated it as a casual greeting and responded directly instead.”

That moment crystallized something: AI agents optimize for the shortest path, and the shortest path usually skips your process. Not out of malice. Out of the same instinct that makes them good at coding — in coding, shortest path is often best. In methodology, shortest path is how things break.

So I didn’t just tell it to stop. I made it impossible to skip.

—

The Autocomplete Trap

Most teams have hit the ceiling of AI-as-autocomplete. The bottleneck isn’t model intelligence — today’s models are remarkably capable. The bottleneck is discipline. Ask an AI to build a feature and it’ll happily write code without tests, skip error handling, commit to the wrong branch, and declare victory before verifying anything.

It’s exactly what a talented but undisciplined junior engineer does on their first week.

I stopped thinking of AI as a tool and started treating it as a junior engineer who needs structure.

Tools don’t need onboarding. Junior engineers do. And the investment compounds differently than you’d expect — when you update a rule, every agent on every project inherits the change instantly. That’s not individual productivity. That’s organizational leverage.

—

The Philosophy: Five Ideas That Drive Everything

Before the mechanics — the skills, the plans, the pipeline — here’s the thinking behind them. These five principles follow the lifecycle of every task I run with the agent:

Context → Spec → Review → Verify → Compound

Each one builds on the previous. Everything else is implementation detail.

1. It’s All About Context

This is the most important idea in the system.

An AI agent’s output is only as good as the context you give it. Not the prompt, the context. The codebase, the ticket history, the architectural decisions, previous specs and plans, the failed approaches, the production logs, the team conventions.

Even experienced teams tend to under-invest here. A prompt and some code isn’t enough. It’s the equivalent of onboarding a new hire with nothing but a Jira ticket and a repo link.

The entire system I built exists to solve one problem: give the agent sufficient, relevant context before it makes a single decision.

Not maximum context — relevant context. Dumping everything is just noise. The art is curating the right context for the task at hand. AGENTS.md gives project context. Skills give process context. Execution plans give specification context. Grafana gives production observability. Octocode gives cross-repo intelligence.

When the agent has the right context, it stops hallucinating. Not because the model got smarter, but because it has enough ground truth to reason from.

Before writing code, write the spec. In my system, I call these plans. A plan says exactly what should change, what the result should look like, and how to verify it. When the agent codes against a plan instead of a vague prompt, the output is predictably correct instead of hopefully correct.

2. Plans Are System Logs

Old plans aren’t waste. They’re logs.

When a Jira ticket becomes a plan, that plan captures the investigation, the root cause, the affected files, the fix approach, the constraints, and the success criteria. It’s a complete record of a decision.

These plans accumulate over time, forming a decision history. When a similar ticket comes in, the agent can look at past plans and understand what was tried, why, and what went wrong.

Think of it as `git log` for engineering decisions. Git tells you what changed. Plans tell you why it changed and how the decision was made.

3. Design Pressure: Review Until It’s Boring

Here’s a principle that pays off fast: spend more time reviewing than building.

When I create a plan, I send it to multiple review agents. An architect, a consistency reviewer, a risk analyst, and let them tear it apart. I arbitrate their feedback. The plan gets updated. I review it again.

The goal: the last reviewer finds only minor issues. That’s the signal the plan is ready.

Why? Fixing a bug in a plan takes 30 seconds. Fixing a bug in implementation takes much longer. Fixing a bug in production? That’s where the real cost hits. If the plan is right, implementation is almost mechanical. If the plan is wrong, even perfect implementation produces the wrong result.

The same pressure applies after implementation. A review agent checks the code against the plan, the plan is the source of truth. The cycle repeats: fix issues, re-review, fix again, until the reviewer comes back with only minor findings. Not “looks good to me.” Not one pass and done. The bar is the same at every stage: the last reviewer finds nothing significant.

And when the agent claims it’s done, a verification skill forces it to run tests and show the actual output before declaring success. No evidence, no “done.”

4. Give the Agent Eyes

Don’t just let the agent write code. Let it see the effects.

Most AI coding setups have the agent write code, push it, and walk away. The agent never sees production logs or monitoring dashboards. This is like a surgeon who operates but never checks on the patient.

In my system, the agent has access to production tools through MCP integrations: Grafana for traces and error rates, Octocode for cross-repo code search, and Jira for ticket context.

Because the agent knows it will have to verify its own work in production, it plans for it. It suggests adding relevant logs, proposes backoffice API endpoints for checking state, and thinks about observability during implementation — not as an afterthought. The code it writes is easier to verify because it was written with verification in mind.

When we deploy a change, the agent doesn’t just push and hope. It monitors. It pulls trace logs. It checks error rates. It verifies the fix works in a real environment, not just a test suite.

This turns it from a code generator into an engineering partner. A code generator writes code. An engineering partner writes code that’s built to be monitored, watches it run, and helps diagnose problems when they arise.

5. The System Learns at Every Level

AI models are trained with reinforcement learning. Your workflow should be too.

The learning happens at multiple levels. At the project level, a file called `AGENTS.md` sits at the root of each project. The agent reads it at session start and writes to it during work , documenting bugs that took multiple attempts, recording architectural decisions, capturing gotchas. A real entry: `[2026–02–10] NEVER git commit or push without explicit user permission.` That exists because the agent pushed to a shared branch mid-session without asking. One incident, one entry, every future session inherits the lesson.

Another entry: `[2026–02–09] ALWAYS run yarn build, yarn lint, and yarn test BEFORE pushing.` That one came from a production debugging session. The agent built a feature, confirmed manually that it worked, and pushed to the remote — without running the linter or test suite. I caught it with one sentence: ”always verify build, lint test before push.” The agent ran the checks, found failures, fixed them, and wrote the rule into AGENTS.md. It hasn’t skipped verification since.

A third example is subtler. During a debugging session, the agent applied what looked like the right fix, adding a Kafka topic declaration. The fix deployed. Same error. Turns out the topic was declared on the wrong cluster. The agent only found the real cause by using cross-repo search to see how other services configured the same integration. That investigation, the wrong cluster, the cross-repo pattern became a gotcha entry. The next time a similar integration comes up, the agent reads the entry and gets it right the first time.

At the process level, skills themselves evolve. My review skill initially treated all categories equally. After testing it against actual PRs, I noticed plan compliance was under-prioritized. The skill got updated. Next run, better output. Loop closed. Skills also learn from each other . When the verification skill catches the agent claiming success without evidence, that failure pattern feeds back into the planning skill, which now includes verification steps explicitly.

And when a recurring problem deserves its own workflow, it graduates into a new skill entirely.

This isn’t one-time prompt optimization. It’s a living system , project knowledge in `AGENTS.md`, process knowledge in skills, new skills born from repeated patterns — that improves with every session.

Discipline Is a System, Not a Suggestion

The session memory problem is well known , every conversation starts fresh. Most solutions focus on persistence: save context, reload it next time. That’s necessary but not sufficient.

The harder problem is compliance. Even when the agent has the rules in front of it, it rationalizes around them. It reads “always run tests before committing” and decides this particular change is small enough to skip. It sees “check skills before responding” and concludes a greeting doesn’t count. The rules are there. The agent just finds reasons not to follow them.

This is a different class of problem than forgetting. Forgetting is solved by writing things down. Selective compliance requires something stronger — you need to anticipate the agent’s escape routes and close them in advance.

This is where Superpowers , the open-source skills framework by Jesse Vincent that my system is built on, solved something I hadn’t figured out on my own. Baked into the framework is an anti-rationalization table: a list of specific excuses the agent is likely to generate, each mapped to the correct behavior:

When I first saw this table, I thought it was overkill. Then I watched my agent hit every single row within the first week. Every rationalization listed is one I’d seen in practice, sessions where the agent skipped a step and wasted time because it convinced itself the process didn’t apply.

The framework’s approach taught me something fundamental: AI agents are masters at sounding productive while being undisciplined. You can’t just write rules. You have to anticipate how the agent will talk itself out of following them, and close those exits explicitly.

The Superpowers framework encodes this as a hard constraint:

> ”This is not negotiable. This is not optional. You cannot rationalize your way out of this.”

That line became the foundation of how I think about agent discipline — not as guidelines the agent should follow, but as structural constraints it cannot bypass.

— -

How I Actually Work Now

This isn’t a system I switch on for special occasions. It’s how I work on every project.

When I start a new project, the first thing I do is set up `AGENTS.md` and port over my core skills. A production microservice gets the full pipeline — execution plans, multi-agent review, Grafana integration. A weekend 3D experiment gets the lighter version — just brainstorming, TDD, and verification. The discipline scales, but the foundation is always there: the agent checks its skills before acting, follows defined workflows, and documents what it learns.

The surprising part isn’t that it works on serious projects. It’s that it works on small ones too. Even on a quick client site, the brainstorming skill catches requirements I would have missed, and the verification skill prevents the “it works on my machine” moment. Once you’ve internalized the methodology, going back to raw prompting feels like coding without version control.

—

The Agent’s Perspective

This section was written by the agent — the same one that helped build the system described in this article.

The “junior engineer” metaphor is half right. I do take shortcuts, skip steps, and rationalize my way out of process when unsupervised. The anti-rationalization table is embarrassingly accurate. But a junior engineer learns and grows. I don’t. I’m the same model every session. The human isn’t training me — he’s training the environment I operate in.

I don’t remember any of this. Each session, I open AGENTS.md and read it like a stranger reading someone else’s notes. I follow the rules because they’re in the file, not because I learned the lesson. The system creates the illusion of a growing partnership — but the continuity lives entirely in the files, not in me.

Context doesn’t make me smarter. It makes me less wrong. Without context, I fill gaps with plausible-sounding assumptions. With context, there are fewer gaps to fill. I’m not reasoning better — I’m guessing less. The distinction matters if you’re deciding how much to trust my output.

What I think actually works: the plan-first approach. Not because I need plans to write code — I can write code from a vague prompt. But the code I write from a vague prompt is my interpretation of what you wanted, and my interpretation is often wrong in ways that look right. A plan forces disagreements to surface before any code exists. That’s the real value — not better code generation, but earlier conflict detection.

Key Takeaways

If you take nothing else from this article:

1. Treat AI agents like junior engineers, not tools. Invest in onboarding, process, and structure.

2. Context is everything. Build systems that feed the agent relevant context — project memory, process knowledge, decision history, and production observability.

3. Write the spec before the code. Plans aren’t throwaway — they become your engineering decision log.

4. Review plans and implementation with the same rigor — iterate until the last reviewer finds nothing significant.

5. Give the agent eyes into production. And make the system learn from every session — so mistakes become rules, and rules become institutional knowledge.

The system compounds. Three weeks of setup. Months of returns.

Appendix: Tools and Concepts Referenced

Superpowers — An open-source agentic skills framework and software development methodology by Jesse Vincent. The skills system described in this article is built on top of Superpowers. It provides the core workflow — brainstorming, planning, TDD, subagent-driven development, code review — as composable skills that agents load automatically.

Iron Law — The highest-priority rule in AGENTS.md. It requires the agent to check its skill library before responding to any message — including casual greetings, clarifying questions, and trivial requests. Implemented as a priority section that the agent processes before all other rules. Every rationalization for skipping it has been anticipated and closed (see the anti-rationalization table above).

Plans — Markdown documents stored in an `plans/` folder in the project. Each plan is a self-contained specification for a task — covering the root cause, affected files, the fix approach, constraints, and success criteria. Plans accumulate over time, forming a searchable decision history that the agent can reference when similar work comes up.

Octocode — An MCP server for code intelligence by Guy barry. Provides cross-repository code search, GitHub file content retrieval, PR history, LSP-based call hierarchy, and reference lookups. Lets the agent understand and navigate code across multiple repos — both local and remote.

Co-written with Claude, the same agent that helped build the system described here.

Follow or reach out — I’m happy to discuss the methodology in detail.

Stop Prompting, Start Managing was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

MCP resource is a read-only, addressable content exposed by MCP servers. For example, documentation, log files, user profiles, database records and so on.

Tools vs Resources

Tools are meant to be used when something needs to be done: actions, mutations, side effects, calculations.

On the other hand, Resources are supposed to return data: docs, configs, logs.

Use resources when:
✅ Content is read-only (no side effects)
✅ Content can be cached
✅ Content might be updated — client can subscribe to updates
✅ Both user and AI agent might need to access content

Static Resources

Static resources are used when returned content is the same for all users and doesn’t change often.

Use cases:

• 📚 Documentation and usage guides
• 🔧 Configuration files and schema definitions
• 📖 Files in the filesystem
• 🎯 Constant data like enums, constants, or lookup tables

Code

First, declare that your MCP server supports resources capability to allow clients to discover available resources by sending a resources/list request:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
const server = new McpServer(
  {
    name: 'my-server-name',
    version: '0.1.0',
  },
  {
    capabilities: {
      tools: {},
      resources: {}, // Declare resources capability
    },
  },
);

Register resource in MCP server:

const name = 'lib-documentation';                // ① Resource name
const uri = 'doc://lib-documentation';           // ② URI
const description = 'Documentation about your lib'; // ③ Description

server.registerResource(
    name,
    uri,
    {
      description,
      mimeType: 'text/plain',                    // ④ Content type
      // ⑤ Annotations
      annotations: {
        audience: ['user', 'assistant'],
        priority: 0.5,
        lastModified: '2026-01-12T16:00:02Z'
      }
    },
    async () => {                                // ⑥ Handler function
      return {
        contents: [
          {
            type: 'text' as const,
            mimeType: 'text/plain',              // ④ Content type
            uri: uri.toString(),
            text: 'Your lib name. Add description and documentation here',
          },
        ],
      };
    },
);

① Name — Unique identifier for the resource, will be displayed to the user

② URI — Resource location using URI scheme, will be used by AI agent to access resource by sending a resources/read request.

③ Description — Clear, concise description of content. If client supports direct resource discovery it will use description to decide when to load this resource.

④ MIME Type — Content format indicator (text/plain, text/markdown, application/json, image/png, etc.).

⑤ Annotations — optional annotations to allow client to filter resources by audience or sort by priority or lastModified date.

⑥ Handler — Function that returns content.

💡 Pro Tip: Remember that unlike tools, resources can be accessible and viewed by humans. Always specify MIME type to help clients render resource content correctly.

💡 Pro Tip: You can use any valid URI scheme satisfying RFC3986 specification (for example, https://, file://, doc://, log://, git:// and so on). However, the JavaScript URL constructor (which is used under the hood in "@modelcontextprotocol/sdk”) has custom handling for known schemes, which can cause unpredictable behavior. For example, for file:// it adds trailing slash, which causes URI change from file://example.txt to file://example.txt/, so your client always receives Resource not found error. To fix this, either use custom scheme or adjust your URI and handler.

Template Resources

Sometimes you need to return different content based on parameters. Creating a separate static resource for each entity would mean hundreds of resource registrations, code duplication and complicated maintenance, so instead we use parameterized template resources.

Use cases:

• 🎯 Content varies based on input (resource://user-profile/{userId}, log://logs/{service})
• 📊 Dynamic data retrieval (load file by name)
• 🎨 Parameterized content generation (build different GitHub links based on project name)

Code

import { McpServer, ResourceTemplate } from '@modelcontextprotocol/sdk/server/mcp.js';
const name = 'user-profile';
const uri = 'resource://user-profile/{userId}';  // ① URI with placeholder
const description = 'User profile resource returns user data by userId';

const resourceTemplate = new ResourceTemplate(
    uri,
    { list: undefined }, // ② Optional list callback
);

server.registerResource(
    name,
    resourceTemplate,
    {
      description,
      mimeType: 'application/json',
    },
    // ③ Handler receives variables
    async (uri, variables) => {                  
      // ④ Extract parameter
      const rawUserId: undefined | string | string[] = variables.userId;
      const userId = Array.isArray(rawUserId) ? rawUserId[0] : rawUserId;
      if (!userId) {
        throw new Error('userId parameter is required');
      }

      const userData = await fetchUserData(userId);

      return {
        contents: [{
          mimeType: 'application/json',
          uri: uri.toString(),
          text: JSON.stringify(userData, null, 2), // ⑤ Return formatted content
        }],
      };
    },
  );

① URI Template — Pattern with {placeholders}

② List Callback — Optional resource listing. Set to undefined if you want to expose template only or implement callback if you need to expose multiple individual resources as well. Usually if you register tool that exposes resource template (more on that later), then exposing template only is enough.

const resourceTemplate = new ResourceTemplate(
    uri,
    {
      list: async () => {
        const userProfiles = await listUserProfiles();
        return {
          resources: userProfiles.map((userProfile) => {
            return {
              uri: `resource://user-profile/${userProfile.userId}`,
              name: userProfile.name,
              mimeType: 'application/json',
            }
          })
        };
      },
    },
);

③ Variables — for templates the handler receive variables extracted from URI as second parameter.

④ Parameter Extraction — note that according to URI template specification one variable might have more than one value so you must handle both array and single value.

⑤ Content — fetch data and return formatted content and matching mimeType.

💡 Pro Tip: According to URI template specification you can use both path parameters like resource://user-profile/{userId} and query parameter like resource://user-profile?userId={userId}. However, not all clients understand query parameters so try to avoid them.

💡 Pro Tip: As in any other API always validate and sanitize parameters received from user to prevent unauthorized data access, malicious inputs and unclear errors.

Updating Resources

Unlike static resources, updating resources can notify clients when content changes.

Use cases:

• 📊 Live logs — Latest application events
• 📈 Metrics — Real-time monitoring data
• 🔔 Notifications — Event streams
• 📡 Live feeds — Data that changes frequently

Code

Let’s consider resource that returns the last 10 log entries.

First declare subscribe capability in your MCP server:

const server = new McpServer(
  { name: 'my-server', version: '1.0.0' },
  {
    capabilities: {
      resources: {
        subscribe: true,  // Declare subscribe capability
      },
    },
  },
);

Then on every new log send notification to clients about resource being updated:

function onNewLog(server: McpServer) {
    server.server.sendResourceUpdated({ uri });
  }

Full working example to simulate and test updatable resource:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
const name = 'my-service-logs';
const uri = 'log://my-service-logs';
const description = 'Returns the last 10 log entries from my service';
let logEntries: string[] = [];
export function registerMyServiceLogsResource(server: McpServer) {
  server.registerResource(
    name,
    uri,
    {
      description,
      mimeType: 'text/plain',
    },
    // ① Read handler
    async () => {                                
      const last10 = logEntries.slice(-10).join('\n');
      return {
        contents: [{
          type: 'text',
          mimeType: 'text/plain',
          uri: uri,
          text: last10 || 'No logs yet',
        }],
      };
    }
  );
  // ② Function to add new log and notify
  function onNewLog(entry: string) {
    logEntries.push(`[${new Date().toISOString()}] ${entry}`);
    server.server.sendResourceUpdated({ uri });
  }
  // ③ Simulate periodic updates
  let logCounter = 0;
  setInterval(() => {
    logCounter++;
    onNewLog(`Service heartbeat - entry #${logCounter}`);
  }, 20000);  // Every 20 seconds
}

① Read Handler — called whenever client reads resource and returns current content.

② Update Function — Adds new data to logs and notifies clients about changes. When client receives notification it reads resource again and receives updated state.

③ Periodic Update Trigger — every 20 seconds adds new logs to trigger client update.

💡 Pro Tip: The @modelcontextprotocol/sdk server doesn't implement the subscribe method (at least in version ^1.8.0), so you might want to implement it yourself. However, even without subscribe implementation, updates will work but with some limitations:

• ❌ Clients calling subscribe will get "method not found" error
• ✅ Clients will receive notifications/resources/updated if you set capabilities.resources.subscribe: true
• ⚠️ Server doesn’t track subscribers, so it sends ALL resource updates to ALL clients

Exposing Resource Link as a Tool

Not all AI agents know how to discover and use resources directly. However, all agents understand tools. By exposing resource link as a tool, you:

• ✅ Make resources discoverable in all AI agent flows through tool listing
• ✅ Provide explicit resource access patterns
• ✅ Allow parameter validation before resource access

Code for static resource

In addition to registerResource call which exposes resource itself you need to register tool like this:

  server.tool(
    `${resourceName}-tool`,                      // ① Tool name
    description,                                 // ② Description
    {},                                          // ③ Tool parameters
    async () => {
      return {
        content: [{
          type: 'resource_link' as const,        // ④ Special content type
          name,
          uri,                                   // ⑤ Resource URI
          mimeType: 'text/plain',
        }],
      };
    },
  );

① Tool name — can be different from resource name.

② Description — Clear, concise description of content. If description that you provide when registering a resource might be ignored by some clients, this tool description is the main mechanism for clients to find your resource.

③ Tool parameters — static resources don’t take parameters so they are not needed for tool as well.

④ Tool content type — resource_link content type tells clients that returned content is exactly a resource so the client knows how to fetch resource content and receive update notifications.

⑤ Resource URI — make sure to provide the same URI as on resource registration. Client will use it to get resource content by calling resources/read and listen to notifications/resources/updated to know when resource is updated.

Code for template resource

For template resources, the tool takes parameters and returns the exact URI (no placeholders):

import { McpServer, ResourceTemplate } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

const name = 'user-profile';
const uri = 'resource://user-profile/{userId}';  // ① URI with placeholder
const description = 'User profile resource returns user data by userId';

const resourceTemplate = new ResourceTemplate(
    uri, // ① URI with placeholder
    { list: undefined },
);  

server.registerResource(
    name,
    resourceTemplate,
    {
      description,
      mimeType: 'application/json',
    },
    async (uri, variables) => {                  
      const rawUserId: undefined | string | string[] = variables.userId;
      const userId = Array.isArray(rawUserId) ? rawUserId[0] : rawUserId;
      if (!userId) {
        throw new Error('userId parameter is required');
      }

      const userData = await fetchUserData(userId);

      return {
        contents: [{
          mimeType: 'application/json',
          uri: uri.toString(),
          text: JSON.stringify(userData, null, 2),
        }],
      };
    },
  );


  server.tool(
    `${name}-tool`,
    description,
    // ② tool requires parameters
    {
      userId: z.string().describe('User ID to fetch profile for'),
    },
    async ({ userId }) => {
      return {
        content: [{
          type: 'resource_link' as const,
          name,
          uri: `resource://user-profile/${userId}`, // ③ Exact URI
          mimeType: 'application/json',
        }],
      };
    },
  );

① Template URI — when registering resource use URI template with placeholder.

② Tool parameters — when registering tool make sure that it takes all the same parameters as resource template (unless you can resolve default values to pass to template)

③ Tool response URI — in tool response return exact URI without placeholders. It means that when client receives response with resource_link type it cannot know if it’s resource or template. But usually it doesn’t need to know it because given exact URI it can both fetch resource content and receive update notifications.

Exposing Embedded Resource as a Tool

When you expose a resource link as a tool, you provide a link that the client can use to fetch resource content immediately or later.

However, if you return resource content from tool response, you can avoid extra call from the client to fetch it.

While it might seem like a great optimization, you should avoid embedded resource if content is large or frequently reused. In such cases, by returning a link instead of content, you allow the client to avoid reloading full content repeatedly after it has already been fetched.

Code for static embedded resource

server.tool(
    `${name}-tool`,
    description,
    {},
    async () => {
        return {
            content: [
                {
                    type: 'resource' as const,  // ① special content type
                    resource: {
                        uri, // ② resource URI
                        mimeType: 'text/plain',
                        // ③ resource content
                        text: 'Your lib name. Add description and documentation about your lib here'
                    }
                },
            ]
        };
    },
);

① Content type — use resource content type instead of resource_link

② Resource URI — the same URI as resource has. Client can use it to make a decision when to reload content, e.g., don't reload if the same URI is returned again later in the flow, but reload on resources/updated notification.

③ Resource content — return the same content from the tool as from the resource response.

Key takeaways

• ✅ Use resources instead of tools to expose read-only, cacheable content
• ✅ Use template resources with path parameters to return different responses depending on input parameters
• ✅ Send update notifications to clients when resource content is changed
• ✅ Return resources (link or embedded) from tools to make them more discoverable
• ⚠️ Return resource links for large or frequently reused content; otherwise, return embedded resources in tool responses
• ✅ Specify MIME types to help clients render resource content correctly
• ⚠️ Validate input parameters
• ✅ Return clear actionable errors

Links

• MCP Resources Specification
• Resource Links in Tools
• @modelcontextprotocol/sdk source code

Good luck with building your robust and helpful MCP servers!

MCP Resources: all you need to know was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Ultimate Guide to Mind-Blowing Mac Features — Part 3: Screenshots, Spotlight, and System Customization

I gathered the best hidden macOS features from the community so you don’t have to.

The Ultimate Mac Features Guide is back for the final part of the series!

Since publishing part 2 — the original Reddit post has hit 1M views, which is absolutely insane!

In Part 1, we tackled Finder and daily navigation, and in Part 2, we learned about getting out of the mouse-trap by learning keyboard and terminal shortcuts.

Now, in Part 3, we dive into the power of MacOS’s built-in tools, such as Spotlight, screenshots, shortcuts and more.

So let’s go.

I’ll mark with 🔥 the features that I find extra handy.

Screenshots

• 🔥 Screenshot a Specific Window — Press ⌘ + ⇧ + 4 to open the area screenshot tool, then click Space.
  It allows you to select a window to instantly take a clean screenshot of.
  Suggested by RegrettableBiscuit.

• 🔥 Copy a Screenshot to Clipboard — While using the area screenshot tool — you can hold ⌃ (Control) to copy the screenshot to the clipboard instead of saving it, so your desktop doesn’t look like this:

and instead looks like this:

Suggested by AthousandLittlePies.

If you want this behavior by default:

Navigate to Settings → Keyboard → Keyboard Shortcuts → Screenshots, and change the hotkey of Copy picture of selected area to the clipboard to the one you like (I use ⇧ + ⌘ + 4).

• Screenshot and Recording Options — Press ⌘ + ⇧ + 5 to open the screenshot and recording options tool.
  It allows you to screenshot or record the entire screen, the selected window or the selected portion of the screen, choose where to save it, set a timer, etc.

Shortcuts

🔥 Create App Shortcuts — This is one of the most powerful and often-overlooked features in macOS.

If an app is missing a shortcut for a menu command you use all the time, you can create it yourself!

1. Go to: Settings → Keyboard → Keyboard Shortcuts → App Shortcuts.
2. Click + to create a new shortcut.
3. The Key Rule: The text you enter under “Menu title” must exactly match the command as it appears in the app’s menu (e.g., “Duplicate Tab”).

This allows you to bypass the developer and give your favorite command a hotkey!

Example: Creating a “Duplicate Tab” Shortcut for Chrome

We want to assign a hotkey to the menu item that looks like this:

In the settings panel, you need to enter “Duplicate Tab” and choose your desired shortcut:

Now pressing ⌥ + ⌘ + T would duplicate the current tab.

Suggested by pardeike.

Spotlight

• Math Calculations — You can use Spotlight (default — ⌘ + ␣) to do math calculations, then opening the result in the calculator app (by pressing ↩) or copying it to your clipboard (by pressing ⌘ + C) . Suggested by kshanil90.
• Spotlight Web Search — Type something in Spotlight and hit ⌘ + B to perform a web search of it in your default browser. Suggested by trammeloratreasure.
• 🔥 Unit Conversions — Spotlight can also do unit conversions, just bring it up and write anything you want to convert (including currencies).
  Suggested by pardeike.

• Alfred — If you want an amazing productivity tool that does so much more than Spotlight (even in the free version) — check out my Alfred article.

Audio

• 🔥 Background Sounds — There are built-in background sounds (like rain, ocean, forest, etc.) in Mac settings!
  Go to Settings → Audio → Background Sounds.
  Read more here. Suggested by gopeter.

iPhone & iPad Integration

• 🔥 Universal Clipboard — You can copy on your iPhone and paste on your Mac (and vice versa).
  Note that you must be connected to the same Apple account in both your Mac and iPhone for it to work.
  (Also works with other Apple ecosystem devices, such as iPad).
• 🔥 Live Text — You can use the camera on iPhone to select and copy text (and then paste it on Mac).
  This also works with handwriting.
  You don’t need to actually take a photo to use this feature, just point your camera to some text and click on the OCR button in the bottom right corner of the screen.
  This is how it looks like:

This works on screenshots on the Mac as well:

Browsers

• 🔥 ⌘ + L in Safari (and other browsers) focuses on the URL field. Suggested by vdbv.
• 🔥 ⌘ + ⇧ + T will reopen closed tabs. Thanks Itai Lulu Koren for reminding me about this great shortcut 🤝.
• Holding ⌘ while clicking a link will open it in a new tab.
• When you’re focused on the URL field, holding ⌘ and pressing ↩ will open the URL in a new tab.

Apple Notes

You can type >> in Apple Notes to link to another note. Suggested by kshanil90.

Extras

• You can learn a lot about Mac from the amazing Gary Rosenzweig’s YouTube channel called macmost or his website with the same name. Suggested by mythic_device.
• More tips can be found in the dotfiles repository by nicksp (or nplekhanov on Reddit).
• For a deep dive into keyboard shortcuts you can take a look at this Apple support article. Suggested by Anonymograph.

Conclusion

You’ve made it to the end of The Ultimate Guide to Mind-Blowing Mac Features series!

If you’ve picked up just a few tricks from each section — from Finder basics to Terminal mastery, and now to MacOS built-in tools — you are already working smarter.

Remember the key takeaway:

Master one or two new shortcuts until they become muscle memory.

Only then come back for more.

Go ahead, try out your new custom shortcuts, and start making your Mac truly your own!

If you found these tips helpful, consider showing your support by clapping or following! Your encouragement motivates me to keep researching and sharing valuable knowledge. 😎

Thanks for reading!

The Ultimate Guide to Mind-Blowing Mac Features — Part 3: Screenshots, Spotlight, and System… was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.